Вчера: "Domain-driven design" by Eric Evans

[singalen]

1. Мне подумалось: Не миф ли CMM Level.

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

С другой стороны, у Сергея был такой опыт: людям неудобно было вводить требования в систему [много-денег-RT], они попросили чего-то другого. Им разрешили вводить их в виде Word-овских документов, и тут-то всё и встало: они не знали, в какой форме, по какому шаблону вводить требования.

Вывод из этой истории сделали такой, что даже самым грамотным работникам нужно давать процедуру. И грамотные аналитики (те, которые ставят требования), не растут на деревьях, их нужно учить.
А начинать обучение хорошо именно с процедуры.

В технологии SSADM — той, которую я знаю лучше всего, — для каждой методики есть список документов, которые она создаёт, и для каждого документа подробно описаны:

• а) формат и содержание;
• б) критерии и методы проверки качества, как-то:
• чеклисты с проверочными вопросами;
• методы формальной проверки полноты и непротиворечивости. Например, специальная матрица проверяет, для каждого ли объекта БД есть задача, которая делает ему C,R,U,D.

Методиками в SSADM называются, к примеру, такие элементы технологии: "логическое моделирование данных", "моделирование информационных потоков", "управление требованиями".

2. "Domain-driven design" by Eric Evans

Я немного покритиковал Эванса, как оказалдось - потому что недочитал до второй половины.
Показалось, что много воды, что одна и та же мысль повторяется на разные лады. Не, мысль очень правильная:

• выделяйте модель предметной области (domain model);
• ведите общий словарь в терминах домена;
• говорите на языке этого словаря друг с другом и заказчиками, пишите код на нём; (два замечания: для заказчика эти слова всё равно будут значить не то, что для вас. Для него пациент - это человек, у которого взяли анализ, плюс личная карточка. А для нас - запись в БД и кусок памяти, определённым образом заполненный байтами).
• создавайте business layer в виде модели домена, и изолируйте его от прочих слоёв.

Но мне объяснили, что дальше идёт несколько очень интересных глав.

Сергей получил от этой книги индульгенцию на классы с именем "*Service". До тех пор он подозревал, что это слово не означает ничего, примерно как "Common", "General", "Object", "Data" или вот более дискуссоинный пример - "Manager". ("Manager" - это м.б. паттерн "utility class"). Ну а теперь мы знаем, что "сервис" бывает не только внутрисистемный, тот, что в словосочетании "Service layer", но и как понятие слоя бизнес-логики ("utility class").

Диме Бочоришвили книга ответила на некие ещё несформулированные вопросы и этим очень понравилась.
Далее о модели предметной области и паттернах, характерных только для модели домена, но не для реализации.
Эванс выделяет такие полезые паттерны для моделей анализа:

• Entity (объект, имеющий identity)
• Value object;
• Composite. Это не GoF-овский Aggregate, он "жёстче". На его элементы нельзя ссылаться извне, их нельзя "вынимать" и без корневого объекта они не бывают. Связь с чёрным даймондом у него внутри навигабельна в обе стороны;
• 1-directional association;
• и что-то ещё;

Меня эта идея натолкнула на мысль, что бывают паттерны модели предметной области ("модели-задачи"), а бывают паттерны модели-решения. Например, такой вот "strong composite" (термин мой) - это паттерн анализа, а Observer - паттерн реализации.
Эту мысль надо развить.
Пообещал себе прочесть фаулеровские "Analysis patterns".

Об отличиях постановки задачи от модели-"постановки задачи" от модели-решения и от собственно решения.

Как вы сами понимаете, даже если мы говорим с заказчиком на одном языке, слово "пациент" значит для нас разные вещи.
Так вот, задача заказчика не эквивалентна модели этой задачи.
Модель-постановка задачи не эквивалентна модели решения; а та не эквивалентна самому решению — программе на языке, скажем, Java.
Потому что:
1) Ассоциация между классами на диаграмме UML, даже именованная, несет не такую семантическую нагрузку, как связь между накладной и товаром, или ссылка между классами в коде на Java. По ней не видно:

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

2) Кто-то в словах "ввод данных о пациенте" слышит "MVC, где модель — объект-пациент", кто-то "Grid с RecordSet-ом из таблицы пациентов", а кто-то вообще "Монада GUI, параметризованная типом данных пациента".

3) Ну и в SSADM выделяются "модель существующей системы" и "модель проектируемой системы". В терминах этой статьи, они равны понятиям "модель задачи" и "модель решения" соотв.
4) И чтобы модель точно соответствовала предметной области, вместо конструкторов и оператора new для пациента пришлось бы заводить объект-папу и объект-маму. Что есть нонсенс.

Из приколов:
(речь об отображении требований на языки со статической и динамической типизацией): "Сегодня я пассажир, а завтра пациент".

Comments

[nponeccop.livejournal.com]

1. Гарантируется ли? Что реально гарантируется? Как можно гарантировать обобщенное качество - удовлетворенность заказчика отдачей от продукта?
   
2. Дают ли формальные метрики существенно более качественный и правдоподобный результат чем звонок менеджеру с вопросом "Эй, как там у вас, все в порядке? Сколько там примерно еще осталось?"
   
3. Нарушения процесса сами по себе не являются признаком завала проекта. Может, как раз процесс неадекватен проекту.
   

Я не являюсь противником формальных процессов, как может показаться. Просто на мой взгляд формальный процесс нельзя "внедрить", его можно только вырастить из менее формального или неформального. Растет уровень зрелости очень медленно. Это в свою очередь требует стабильной во времени политики улучшения процесса, малой текучки кадров и большого времени жизни компании на рынке без смены владельца, высшего техничского руководства и курса.

Подумайте, сколько человеку надо сделать проектов, прежде чем человек сможет назвать себя специалистом по управлению требованиями? Сколько это времени? Сколько понадобится специалисту времени, чтобы внедрить привычные ему практики на новом месте работы? Сколько времени вы согласны работать на одном месте? Сколько вам будет лет тогда когда вы это все внедрите? Какие у вас тогда будут интересы?

Все это обуславливает текущую ситуацию с CMM здесь. О СММ говорят ньюбы, а престарелым гуру уже вообще ничего не надо. Видимо, пора мне срываться с насиженного места и эмигрировать в "серьёзную контору" без бюрократии и людей сидящих не на своем месте и вставляющих палки в колеса. Такие бывают?

[singalen]

"серьёзную контору" без бюрократии и людей сидящих не на своем месте и вставляющих палки в колеса
Так ведь - не бывает разработки ради разработки. Бывает проект, о котором одно "лицо" договорилось с другим, и люди, которых эти двое считают авторитетными, и люди, которым нужны подряды в этом проекте, и те де и те пе.
Давайте искать рынок, где ценят в первую очередь качество, а не умение продать. И желательно, где не нужно работать на военных...

[nponeccop.livejournal.com]

Зачем искать? Получится разработка ради качества. Она ничем не лучше разработки ради разработки. Главное - приносить пользу заказчику.