Когда я рос как программист, это было время объектно-ориентированного всего. Сначала вы должны были заниматься объектно-ориентированным анализом (где вы пытались понять ту часть системы/области, которую собирались внедрить), затем был объектно-ориентированный дизайн (где вы придумывали программные структуры, которые представлять то, что вы проанализировали, таким образом, который имеет нужные возможности и степени свободы), а затем, наконец, вы берете свою IDE и пишете код.

Эта довольно строгая последовательность — это безумие, особенно когда, как это было обычно в то время, она сочеталась с водопадным процессом; этапы анализа и проектирования могут длиться недели. Там были хорошие немецкие слова для документов, которые вы должны были написать, Lastenheft и Pflichtenheft. И процессы того времени, например, Rational Unified Process, включали в себя десятки десятков документов, которые вы должны были создать, прежде чем вы должны были начать программировать. Помню проект конца 90-х, где архитектор выражал восторг по поводу того, что РУП «настраивается» под контекст, в котором он используется, и что нам нужно было написать всего 80 этих предписанных документов (здесь без преувеличения , было 80). К счастью, так мало кто делал.

Сегодня мы живем в мире agile, где у любого документа плохая репутация. Помните, в Agile Manifesto говорится, что мы ценим «рабочее программное обеспечение больше, чем исчерпывающую документацию» и «реагирование на изменения, а не следование плану».

Это часто (неверно) интерпретируется как утверждение, что мы не должны думать о предметной области или проблеме до того, как начнем программировать; просто создайте его, напишите тесты, а затем посмотрите, будет ли он полезен. Пионеры agile не имели в виду это. Они хотели предотвратить именно эти недели и месяцы этапов производства бумаги. Это потому, что они поняли, что заинтересованные стороны часто не знают, чего они хотят, пока мы не начнем создавать ранние версии системы, что требования со временем меняются (даже в течение времени, необходимого для создания системы), что документы с требованиями не могут быть проверены или иным образом проверены на согласованность (поэтому они часто бывают неполными, непоследовательными и непостижимыми), и что даже разработчики и анализ требований не могут создавать слои и слои ментальных моделей без предварительной реализации чего-либо, а затем продолжают строить ментальные модели поверх этой исполняемой системы. .

Но вот проблема: многие люди сегодня действительно понимают Agile-«предписания» как «давайте несколько минут поговорим о том, что нужно заказчику, а потом давайте что-нибудь построим, мы всегда можем повторить и изменить». Это может хорошо работать для простых систем. Но если вы пытаетесь представить сложную область в программном обеспечении — например, в виде DSL, а также в других формах — вам нужно потратить некоторое время, чтобы попытаться понять

  • каковы основные абстракции предметной области и как они связаны
  • какие вариативность и частные случаи существуют в этих абстракциях
  • какие части того, что люди говорят вам как «требования», действительно важны для новой системы, а какие являются просто историческими случайностями и должны быть проигнорированы или заменены чем-то лучшим
  • в какой форме мы должны позволять пользователям взаимодействовать с доменом (синтаксис и т. д.)

Эти «аналитические сессии» могут длиться часами, обычно в них участвуют специалисты по программному обеспечению (языку) и эксперты в предметной области, и да, иногда мы даже выпускаем пару страниц письменного материала.

Ключом к успеху таких сессий являются три вещи:

  • На сеансе должны присутствовать люди, обладающие значительными знаниями о предметной области, для которой мы хотим определить систему, чтобы ответить на вопросы о том, как должна работать создаваемая система. Если вы создаете систему, которая заменяет существующую, они также должны уметь различать, как работает текущая система, и как должна работать новая система.
  • Все в группе должны уметь абстрагироваться. Вы будете создавать ментальные модели того, как должна работать будущая система. Если участники не могут этого сделать, это будет проблемой.
  • Люди также должны иметь возможность точно и ясно сообщать как о предметной области, так и о том, как работает разработанная в настоящее время система на основе текущего состояния ментальных моделей, которые вы создаете.

Последним очень важным компонентом этих «сессий размышлений» является то, что вы понимаете, когда вам нужно перестать думать и начать программировать. Пирамида ментальных моделей может стать такой высокой только до того, как даже лучшие абстракционисты выдохнутся или когда потребуется обратная связь от будущих пользователей. В этот момент остановите сеанс, создайте прототип и извлеките из него уроки. Вернитесь к размышлению позже, если это необходимо.