Модель принятия инженерных решений — ключ к ответам на технические вопросы (Евгений Кривошеев, AgileDays-2011) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
<blockquote> Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна) [http://techmnd.blogspot.com/2011/03/agiledays.html ©] </blockquote> {{include-review|AgileDays-2011: Отчет Кудрявцева В.Б/Модель принятия инженерных решений}} <references/> [[Категория:AgileDays-2011]] [[Категория:Программная архитектура]] {{stats|disqus_comments=0|refresh_time=2020-07-07T22:50:1618T23:21:20.508302912387|vimeo_comments=0|vimeo_plays=409|youtube_comments=0|youtube_plays=21}} |
Версия 20:21, 18 июля 2020
Аннотация
- Докладчик
- Евгений Кривошеев
- Нужен ли в дизайне моей системы паттерн Singleton?
- Почему при изменении требований затраты на внесение изменений возрастают?
- Сколько времени уделять проектированию?
- Зачем мне модель предметной области, ведь и без нее все работает?
- Чем архитектура отличается от дизайна?
- С чего начать проектирование?
- Я запутался в паттернах — они противоречат друг другу!
- Вся остальная команда — придурки, они ничего не понимают!
- Где располагать модульные тесты?
- Нужно ли документировать? Что именно документировать?
- Мучают эти вопросы? Конфликты в команде? Тогда мы идем к вам :)
Ответ есть :)
Бухтелово посвящено модели принятия инженерных решений. Ожидается, что слушатели выступления получат мощный инструмент — стройную систему, которая позволит в лучших традициях agile-подхода вырабатывать оптимальный дизайн систем и разрешать конфликты в команде.
В качестве отправной точки будут представлены типичные грабли и антипаттерны разработки, которые автор считает наиболее типовыми и массовыми. Отталкиваясь от них, мы коллективно смоделируем решения, которые помогут резко снизить затраты на разработку и приведут к качественному дизайну.
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Примечания и отзывы
Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна) ©
Plays:430
Comments:0