Модель принятия инженерных решений — ключ к ответам на технические вопросы (Евгений Кривошеев, AgileDays-2011) — различия между версиями

== Примечания и отзывы ==
* [http://2011.agiledays.ru/reports/view/92/ страничка доклада на сайте конференции]

<blockquote>
Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна)
[http://techmnd.blogspot.com/2011/03/agiledays.html ©]
</blockquote>

{{include-review|AgileDays-2011: Отчет Кудрявцева В.Б/Модель принятия инженерных решений}}

<references/>





{{stats|disqus_comments=0|refresh_time=2020-07-18T23:21:202021-08-25T02:52:01.912387743866|vimeo_comments=0|vimeo_plays=409|youtube_comments=0|youtube_plays=231}}

[[Категория:AgileDays-2011]]
[[Категория:Архитектура и Agile]]

Версия 23:52, 24 августа 2021

Аннотация

Докладчик

Евгений Кривошеев

• Нужен ли в дизайне моей системы паттерн Singleton?
• Почему при изменении требований затраты на внесение изменений возрастают?
• Сколько времени уделять проектированию?
• Зачем мне модель предметной области, ведь и без нее все работает?
• Чем архитектура отличается от дизайна?
• С чего начать проектирование?
• Я запутался в паттернах — они противоречат друг другу!
• Вся остальная команда — придурки, они ничего не понимают!
• Где располагать модульные тесты?
• Нужно ли документировать? Что именно документировать?
• Мучают эти вопросы? Конфликты в команде? Тогда мы идем к вам :)

Ответ есть :)

Бухтелово посвящено модели принятия инженерных решений. Ожидается, что слушатели выступления получат мощный инструмент — стройную систему, которая позволит в лучших традициях agile-подхода вырабатывать оптимальный дизайн систем и разрешать конфликты в команде.

В качестве отправной точки будут представлены типичные грабли и антипаттерны разработки, которые автор считает наиболее типовыми и массовыми. Отталкиваясь от них, мы коллективно смоделируем решения, которые помогут резко снизить затраты на разработку и приведут к качественному дизайну.

Видео

Примечания и отзывы

• страничка доклада на сайте конференции

Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна) ©

Plays:440   Comments:0