emacsway-log: Technical Leadership, Management, Software Architecture, DDD, Microservices, Distributed Systems, XP, Agile, etc.

"Психология конструкторского труда формирует у человека очень важное качество: обязательно найти положительное решение. Вот потому-то хороший конструктор, как правило, и хороший организатор производства, хороший испытатель. Способность брать на себя ответственность и добиваться положительного решения проблемы, конечно, присуща не только конструктору, но воспитывает ее в человеке, по-моему, прежде всего — конструкторский труд."
-- Сергей Викторович Михеев, генеральный конструктор ОАО «Камов»

Настоящий титан. Не какой-то там "эффективный менеджер", утешающий себя тем, что где разработка, а где менеджмент.

В последнее время часто слышу сетование на то, что LLM сделал не то и не так.

Давайте посмотрим что такое архитектурное решение на примере покупки курительной трубки. Решение должно содержать ответ на вопросы:

1. Какая модель трубки?
1.1. Форма чаши (бильярд, бренди, яйцо, яблоко, бульдог/родезиум...)
1.2. Изгиб (прямая, 1/4 бент, 1/2 бент...)
1.3. Способ осушения (естественное осушение (канадка, ловат), системная конструкция на эффекте Джоуля-Томсона, фильтр 9 мм, фильтр 6 мм, конденсатор, без осушения...)
1.4. Загубник (обычный, P-Lip...)
1.5. Материал трубки (бриар, морта, пенка, фруктовое дерево...)
1.6. Материал мундштука (эбонит, акрил...)
1.7. Финишная обработка (бласт (пескоструй), рустирование, гладкая, лаковая, восковая...)
1.8. Размеры и форма камеры.
1.9. Размеры и пропорции трубки.
1.10. Масса трубки.
1.11. Конструктивные особенности (шпигот, sitter...)
1.12. Цвет (чаши и мундштука)

2. Производитель трубки.

3. Конкретная реализация трубки:
3.1. Точность центровки дымового канала в центр дна камеры.
3.2. Соосность дымового канала мортиза и мундштука (критично для безфильтровых).
3.3. Наличие шпаклевки, питов, каверн.
3.4. Натяг цапфы мундштука.
3.4. Дефекты (сколы, царапины).

Естественно, если просто сказать LLM "предложи мне трубку", то он может выбрать какой-нибудь калабаш просто потому, что поиск этого варианта оказался наименее энергозатратным.

Архитектурное решение - это многокритериальная задача. Если не задать критерии, то никакое решение не будет верным.

Архитектурное решение состоит из дивергентной фазы (расширение списка вариантов) и конвергентной фазы (сокращение вариантов решения до одного). Самое важное - это критерии для сокращения вариантов, т.е. наличие ясных причин, почему тот или иной вариант нам не подходит. Без критериев решение будет случайным и чаще всего продиктовано когнитивными искажениями (например, "мы всегда так делали"...). Упущенный критерий вылезет уже в процессе эксплуатации решения. Как сказал Роберт Мартин, архитектура - это о том как не надо делать.

Требования к трубке могут находиться в противоречиях (обратно коррелировать). Например, трубка бульдог бент имеет красивые геометрически правильные грани, т.е. удовлетворяет требованию эстетики. Но это достигается в ущерб требованию практичности, т.к. острые грани имеют маленький запас прочности и при малейшем усилии заминаются или скалываются. На гранях всегда возникает повышенное удельное давление (от руки или стенок футляра) и они быстро "лысеют".

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

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

Для яхты хорош легкий Lovat, который "не болтается под подбородком" и всегда в поле зрения. Конструкция естественного осушения позволяет длительное время обходиться без фильтров.

Может случиться так, что на рынке нет подходящей реализации. Например, трубка выбранной модели и производителя имеет дефекты. Такое случается даже с дорогими трубками, например, Ashton нередко ругают за центровку. И тогда нужно посмотреть, можно ли изменить баланс требований. Это Twin Peak - конструктивные ограничения изменяют требования.

LLM эти критерии прекрасно знает, но вот незадача, промпт может быть составлен таким образом, что эти нейроны просто не будут активированы. Поэтому их нужно активировать явно: выпиши в ADR draft все критерии принятия/оценки решения.

Следующий этап - составление матрицы принятия решения. Никакой критерий не плох сам по себе - он может просто соответствовать или не соответствовать цели. Что хорошо для презентабельной клубной встречи - плохо для охоты. Поэтому матрица конекстно-зависима.

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

Ну а чтобы не водить LLM за руку, можно эту функцию возложить на LLM.

И Джессика пишет книгу! https://technicspub.com/ontology-pipeline/

Кстати, миниредактор SKOS-тезаурусов Atramhasis обновился (https://github.com/OnroerendErfgoed/atramhasis).

На всякий случай про JSON-LD: https://w3c.github.io/json-ld-syntax/

SKOS и был придуман для (онтологически) контролируемых тезаурусов.
Сейчас он есть на базе JSON-LD, но удобнее https://gbv.github.io/jskos/

Этот вариант работает лучше:
Создай себе двух агентов (слепой решатель и дискриминатор), чтоб применить 1-й закон диалектики и The Rule of Three by Gerald M. Weinberg (The Secrets of Consulting) для поиска наилучшего решения

По поводу Agile добавлю ясности. В программой инженерии принято различать SDLC-модель, методологию (реализующую модель), framework (образующий методологию) и toolkit.

Когда говорят про церемонии, то говорят про конкретную методологию, реализующую Agile-модель. XP, FDD, Crystal Clear, методология на основе Scrum-framework и т.п.

Agile - это модель, такая же, как и каскадная, спиральная, итеративная, инкрементальная, эволюционная, V-model и гибридная. Ни одна из моделей не умерла и не умрёт, включая Agile, тем более из-за AI. При этом, видимо, появятся новые методологии или адаптируются существующие.

Превалирующая на массовом рынке SDLC-модель постоянно меняется, как маятник. Ключевое отличие в SDLC-моделях - это соотношение prediction активности к adaptation активности. Т.е. соотношение того, какая часть неопределённости требований разрешается заблаговременно, путём логического вывода, а какая часть - экспериментально, путём адаптации реализованных гипотез (принцип "не попробуешь - не узнаешь", т.н. wicked problem, символом которой стало разрушение моста Таacoma Narrows).

Поэтому SDLC-модель выбирается для каждого конкретного проекта исходя из уровня неопределённости требований и стоимости адаптации.

Каскадная модель подразумевает 100% prediction. Работает отлично для небольших типовых проектов, где всё ясно-понятно.

Спиральная и гибридная модель балансирует prediction и adaptation. Гибридная модель так называется потому, что она сочетает в себе практики продуктового и проектного подходов. Сегодня это самая распространённая модель в крупных продуктах (Disciplined Agile, SAFe...) А в спиральных моделях соотношение prediction/adaptation ещё и постоянно меняется на протяжении жизненного цикла.

В итеративных и Agile моделях соотношение prediction/adaptation максимально отклонено в пользу adaptation.

Почему исторический маятник всё время колеблется?

Стоимость адаптации была слишком дорогой - превалировала каскадная модель.

Появилось автоматизированное тестирование, браузер рефакторинга, высокоуровневые языки, паттерны проектирования - упала стоимость адаптации, произошел переход от каскадной модели к Agile.

Системы стали расти, появились микросервисы, обострилась проблема Брукса, выросла стоимость adaptation - произошел переход от Agile к гибридным моделям. Появление легковесных практик проектирования (Event Storming и др.), удешевляющих prediction, ещё больше закрепили гибридные модели.

Появился AI, который на порядок удешевил адаптацию, - появились SPDD, SDD. SDD - это, кстати, ни капли не про Waterfall - это чистой воды итеративная модель, почитайте мануал к OpenSpec - он весь построен вокруг инкремента итерации. Это инструмент управления изменениями, т.е. адаптацией. В результате упала численность команд разработки, маятник откатился назад в сторону итеративных моделей и Agile.

При этом нужно отличать SDLC-модель от эффекта Boiled Carrot (говоря по русски, отличать очки от эффекта "мартышка и очки").

Когда говорят, что "Agile не работает", то это означает, что это у них он не работает. Это поднимает два вопроса:
1. Соответствует ли выбранная SDLC-модель условиям проекта? Если не соответствует, то что мешает её сменить?
2. А если соответствует, то с чего они решили, что умеют "готовить морковку"?

Но в любом случае, "работает" не SDLC-модель, а конкретная её реализация (методология). SDLC-модель просто отвечает на вопрос о том, каким образом и в каком соотношении сочетать заблаговременный (prediction) и экспериментальный (adaptation) способы разрешения неопределённости.

Если говорить не про организационные мероприятия (обучение, управление процессами, топология команд), то лично мне хорошо помогает SKOS-спецификация (или OWL, но она часто избыточна и дублирует другие артефакты). Это если речь идёт о моделировании какого-то реального сектора.

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

Микросервисы добавляют сложность, но эта сложность техническая. Самое главное - это управление существенной сложностью.

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

Достигается это качественным выделением моделей (границей которых является Bounded Context). Когда модель сфокусирована на одной решаемой проблеме, она дистиллируется от паразитной сложности. И изменения системы, касающиеся этой решаемой проблемы, становится возможным изолировать в границах самой модели (не всегда, конечно, но эти исключения становятся редкими). Отсюда и пошло правило, что единицей обязанности команды разработки является модель.

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

С другой стороны, при качественных моделях микросервисы делают более дорогим сам процесс расползания границ моделей. Невозможность в сделать join во write (domain) model микросервиса защищает модель от расползания.

Независимо от того, как деплоятся компоненты системы, монолитно или независимо (микросервисы), всё упирается в качество моделей.