Аннотация
- Докладчик
- Евгений Кривошеев
- Нужен ли в дизайне моей системы паттерн Singleton?
- Почему при изменении требований затраты на внесение изменений возрастают?
- Сколько времени уделять проектированию?
- Зачем мне модель предметной области, ведь и без нее все работает?
- Чем архитектура отличается от дизайна?
- С чего начать проектирование?
- Я запутался в паттернах — они противоречат друг другу!
- Вся остальная команда — придурки, они ничего не понимают!
- Где располагать модульные тесты?
- Нужно ли документировать? Что именно документировать?
- Мучают эти вопросы? Конфликты в команде? Тогда мы идем к вам :)
Ответ есть :)
Бухтелово посвящено модели принятия инженерных решений. Ожидается, что слушатели выступления получат мощный инструмент — стройную систему, которая позволит в лучших традициях agile-подхода вырабатывать оптимальный дизайн систем и разрешать конфликты в команде.
В качестве отправной точки будут представлены типичные грабли и антипаттерны разработки, которые автор считает наиболее типовыми и массовыми. Отталкиваясь от них, мы коллективно смоделируем решения, которые помогут резко снизить затраты на разработку и приведут к качественному дизайну.
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна)
©
Евгений Кривошеев, ScrumTrek
Достаточно интересный и познавательный, но малополезный на практике (ИМХО) доклад.
Что можно попробовать:
- оформить Architecture Guideline — руководство по принятию архитектурных решений
- сформулировать хотя бы устно требования по надежности, производительности и другим нефункциональным требованиям.
Антипаттерны:
- «Категорическое мышление»
- Неспособность обосновать инженерное решение — хотя бы на словах оттрасировать к (нефункциональным требованиям)
- Неверный акцент усилий (слишком много дизайна/аналитики перед разработкой и т. п. — аналогично потерям в Lean)
- Overengeneering (тоже потери)
Модель компетентности
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
