Введение
@design-defines-complexity:Архитектура определяет сложность
… именно стратегия архитектурного проектирования главным образом определяет потенциальную сложность будущего программного продукта. Когда сложность выходит из-под контроля, разработчики перестают понимать свое изделие достаточно хорошо для того, чтобы вносить в него исправления или расширять его возможности без особого труда и опасений.
Как обычно, речь идет об управлении сложностью, см.также
- Энтропия системы применительно к программным продуктам
- Эффективная работа с унаследованным кодом, избегание изменений
В экстремальном программировании признается важность принятия проектных решений, но категорически отрицается жесткое заблаговременное планирование с полной детализацией проекта (что называют upfront design). Вместо этого прилагаются большие усилия для обеспечения коммуникации и способности быстро менять направленность проекта. Имея такую способность, разработчики могут на любом этапе проекта выбирать простейшее из работоспособных решений, а затем постоянно выполнять рефакторинг, внося много мелких проектных улучшений и постепенно приходя к архитектуре, которая будет удовлетворять действительные потребности клиента.
Предварительный дизайн должен существовать, важно не перепроектировать и не упираться в полное описание всех тонкостей архитектуры. Опасность слишком подробной архитектуры
Часть 1. Модель предметной области в работе
@what-is-model:Модель
Модель - это упрощение; это такая интерпретация реальности, при которой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются. <..> Модель представляет собой специально отобранный и сознательно упрощенный запас знаний в структурированной форме. Правильная модель придает информации смысл и позволяет сконцентрироваться на проблеме.
Модели ограниченно полезны, т.к. не являются полным отражением действительности. Для использования какой-либо модели важен контекст и применимость модели в этом контексте.
@what-is-domain:Предметная область
Область знания или деятельности, в которой пользователь применяет ПО. Некоторые предметные области связаны с физической реальностью, а другие - неосязаемы. В каждой такой области существует огромный запас знаний, т.е. большой объём и значительная сложность информации.
Нечеткость, недетерминированность предметных областей ставит интересные технические задачи (с точки зрения моделирования и проектирования?)
@what-is-domain-model:Модель предметной области
Строго организованная выборка знаний специалистов по предмету. Это не схема, а идея, которую можно отразить в схемах, тексте программ или на естественном языке.
- Модель и архитектура взаимно определяют друг друга.
- Модель лежит в основе языка, на котором говорит вся команда.
- Модель - это дистиллированное знание (квинтэссенция), позволяющее снизить сложность предметной области.
Алгоритмическая часть программы (вычислительное ядро, The Heart of Software) - сосредоточение способности ПО решать задачи пользователя.
Глава 1. Переработка знаний
Составляющие эффективного моделирования:
- Связь между моделью и реализацией (действительностью?)
- Язык, основанный на модели
- Информоёмкая модель (архитектура). Это не просто схема данных, а целостная методика.
- Дистилляция модели по ходу разработки
- Эксперименты и мозговые штурмы
@knowledge-flow:Поток знаний
В каскадной разработке знания и информация текут в одном направлении, слабо накапливаясь и видоизменяясь. В итеративной разработке знания активно накапливаются и перерабатываются благодаря обратной связи. Однако это возможно только при активном абстрагировании (поиске более общего знания - см. Сжатие знаний - полезный навык), а не фича-потоке с акцентом на реализацию функциональности.
В некоторых других проектах используется итерационный процесс, но там знание тоже не накапливается, поскольку нет абстрагирования. Разработчики просят специалистов описать им требуемую функцию программы. Потом реализуют ее, показывают специалистам результат и спрашивают, что делать дальше. Если программисты практикуют рефакторинг, то они способны удержать свою программу в достаточно строгих стилистических рамках, чтобы успешно ее дорабатывать. Но если программисты не интересуются предметной областью как таковой, то узнают только то, что должна делать их программа, а не принципы, на которых основаны ее операции. Таким способом вполне можно написать полезную программу, но подобный проект никогда не достигнет такого уровня, на котором сами собой появляются новые мощные возможности как следствие уже реализованных.
@model-evolution:Эволюция модели
Программист осваивает фундаментальные принципы предметной области. Специалисты уточняют формулировки (сжатие и переформулирование - см. Эффективные конспекты - переформулирование и сжатие). Аналитики привносят четкую организацию и должный уровень абстракции. По мере улучшения модели она сама становится средством организации поступающей информации.
@continuous-learning:Непрерывное обучение
Это постепенное сознательное наращивание знание: совершенствование технических навыков, общих навыков моделирования, а также серьезное изучение предметной области.
Разработчики, склонные к самообразованию (практикующие непрерывное обучение), образуют наиболее стабильное ядро группы.
@informative-model:Информоемкая модель (архитектура?)
Для предметной области важны объекты, операции и правила, плюс, возможно, еще какие-то специфичные категории понятий. Правильная модель должна все это учитывать, более того, модель нужно активно использовать для прояснения бизнес-правил и устранения неявных противоречий в них.
Пример с правилом избыточного резервирования (overbooking), которое было
вынесено из метода резервирования в отдельную сущность OverbookingPolicy,
таким образом важное для предметной области правило получило значимое отражение
в коде программы.
Знания, относящиеся к проекту, всегда фрагментированы, разбросаны по документам и памяти разных людей, а также смешаны с посторонней информацией, из-за чего даже нельзя знать наверняка, что именно нам понадобится. Если какая-нибудь предметная область на первый взгляд и кажется не слишком сложной технически, она еще может преподнести сюрприз - заранее не известно, что именно из нее мы не знаем. А невежество заставляет делать ложные предположения.
Отсылка к неосознанному невежеству? Ложные знания опасны - Ложные знания опасны.
Переработка и усвоение знаний - это процесс творческий и исследовательский, и куда он может завести, заранее сказать нельзя.
Глава 2. Коммуникация и язык
Проект без общего языка обречён на постоянные потери при коммуникациях - смысл при передаче сообщений от одного участника к другому искажается.
Необходимость в переводе затрудняет коммуникацию и ослабляет интенсивность переработки знаний.
Ни один из диалектов задействованных сторон не может служить общим языком, поскольку ни один из них не служит всем поставленным целям.
Объем требуемого перевода плюс риск неправильного понимания - это слишком высокая цена.
В устном общении необходимо постоянно экспериментировать с языком модели, уточняя формулировки и сжимая описания. Человеческий мозг приспособлен к распознаванию и учету нюансов в сложной разговорной речи, этим нужно пользоваться. Найденные идеи и уточнения необходимо сразу же отражать в коде, возможно, проводя серьёзный рефакторинг (но как минимум - переименования классов или методов).
Если квалифицированные специалисты в своей области не понимают модель, то с этой моделью что-то не так.