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

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

Кстати 2, нашего полку прибыло: Intentional Arrangement SKOS (https://github.com/jesstalisman-ia/intentional-arrangement-skos)

Кстати, миниредактор 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) способы разрешения неопределённости.

Я думаю, что есть два критерия оценки:

1. Лингвистическая согласованность. Когда мы называем одного и того же человека "мама" и "сотрудница", очевидно, мы ожидаем от него разные функции для решения разных проблем. Здесь как раз хорошо помогает SKOS спецификация.

2. Измерение Coupling & Cohesion
http://www.sdml.cs.kent.edu/library/Allen99.pdf
Когда в модели появляются нерелевантные функции, у неё подает Cohesion.

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

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

Если сухо и коротко, то модель - это системное отображение оригинала.

Если формально, то https://sebokwiki.org/wiki/What_is_a_Model%3F

Модель - это прежде всего заменитель чего-либо (какого-то оригинала). Сидит клерк в банке и считает на калькуляторе процентную ставку по кредиту. Это оригинал.

Мы хотим этот расчёт автоматизировать. Для этого мы изучаем как он её считает. Получается модель предметной области, или аналитическая модель. Модель в problem space. Чтоб эту модель получить, нам нужно переработать существенную сложность.

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

Понимание того, какую проблему должна решить модель, даёт нам возможность определить релевантность аспектов оригинала решаемой проблеме.

У клерка есть водительские права - для расчета процентной ставки эта информация релевантна?

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

У клерка есть ставка ЦБР, которую он использует для расчета ставки банка. А вот это уже релевантно.

Релевантность позволяет упростить модель, устраняя из неё все нерелевантные аспекты оригинала. Это называется абстракция. Модель есть упрощение, а значит, модель есть абстракция.

Предположим, нам нужно проложить маршрут, например, из Москвы в Мурманск. Смогли бы мы это сделать по точной копии Земли в масштабе 1:1? Ни один человек не обладает такими когнитивными способностями, чтоб переварить такое количество нерелевантных деталей. Абстрагируясь от них мы создаём навигационную модель, которая содержит исключительно релевантные аспекты оригинала.

Итак. Модель есть упрощенная интерпретация оригинала с целью его замены для решения некой проблемы. Три важных момента:
1. Заменить что?
2. Заменить для чего?
3. Какие аспекты оригинала заменитель должен отображать?

Решаемая моделью проблема является причиной её создания. Это то, что должна делать модель, воплощённая автоматизированной системой. "Делать" на английском - "business". Поэтому логика модели называется business-logic.

Понимая логику работы клерка, мы начинаем готовить модель решения (solution space), чтоб воплотить её системой. В DDD ключевая суть заключается в том, чтоб аналитическая модель в problem space совпадала с моделью решения в solution space. Это коротко о том, что такое DDD.

Я, конечно, упростил и пропустил ряд важных моментов, таких как дихотомия функции и конструкции (подпереть дверь можно камнем, а можно и книгой). Чем отличается модуль от компонента и почему они могут не пересекаться (пример: ножницы из трёх модулей (две половинки и гвоздик) и двух компонентов (рокоятка и режущая кромка)). Как абстрактность слов приводит к лингвистическим конфликтам и позволяет обнаружить модели.

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

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

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

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

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

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

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

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

Было бы интересно посетить их курс, стартующий завтра 19 октября, но, боюсь, что мой плотный график мне этого не позволит. Может быть в другой раз.
[UPDATE]: Запись https://t.me/sslpractice/1252

Собственно, статья о том, о чем я и говорил несколько месяцев назад:

Никакой BDUF/Waterfall не воскреснет. Не воскреснет по той же причине, по которой он исчез в конце 90-х: прототипирование в виде адаптивной итеративной разработки стало дешевле BDUF. AI ещё больше его удешевляет.

"AI makes Agile more alive"
https://www.thoughtworks.com/insights/blog/agile-engineering-practices/ai-makes-agile-more-alive

Спрашивали, где можно посмотреть результат этого метода.

В процессе TLA+ доказательства Claude (Fable) обнаружил, что при изменении количества workers в конфигурации сервиса Transactional Outbox и Transactional Inbox могут терять сообщения.

Предложенные им варианты были работающими, но существенно усложняли интерфейс библиотек. Тогда я и решил попробовать этот метод для расширения списка вариантов решения.

В результате он предложил решение, которое мне не встречалось ни в одной из Transactional Outbox/Inbox библиотек на пяти языках, с которыми имею дело. И, если честно, я даже не догадывался о том, что так можно было. И, видимо, Claude тоже не догадывался. По крайней мере до сего момента он мне его не предлагал ни разу. Иными словами, он это решение не из долговременной памяти вытянул, а синтезировал в соответствии с 1-м з-ном диалектики.

Посмотреть результат можно здесь для Outbox:
- https://github.com/krew-solutions/ascetic-ddd-rust/commit/803bcaf4d0d5550aaebd7045110a2cc6330760a0

И для Inbox:
- https://github.com/krew-solutions/ascetic-ddd-rust/commit/cba3b3348464d282085200b29e312227fb5d47dc

Еще один лайфхак для поиска непростых решений:

❯ Создай себе агента-дискриминатора, чтоб применить 1-й з-н диалектики и The Rule of Three by Gerald M. Weinberg для поиска решения.

Источник идеи подсмотрел здесь.

Увидел я вчера это кликнув пуш-сообщение и подумал, а не охерел ли Яндекс в очередной раз так беспардонно заявить, что он следит за моими передвижениями и использует эти данные по любой своей прихоти?

Сегодня читаю в пабликах: какой ужас, какой ужас, всё пропало, Nebius, амстердамская контора Аркадия Воложа, основателя "Яндекса", теперь будет работать на Palantir.

Интересно, что в пабликах главную угрозу видят не в утечке достижений Яндекса в области ИИ (которые, видимо, за угрозу никто не считает), а в том, что Яндекс всё про всех знает. Кто что кушает, о чем думает, куда ездит...

Если вы хотите реально научиться разбираться во внутрикорпоративной политике, а не тратить время на всякую бульварную шелуху, то вот несколько направлений:

- теория элит, основоположниками которой являются Вильфредо Парето (а не Паредо), Гаэтано Моска и Роберт Михельс;

- классическая работа "Властвующая элита" / Чарльз Райт Миллс, которая заложила основы современной неоэлитологии;

- концепция "глубинного государства" (Deep State)

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

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

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

Открываю я правила безопасной эксплуатации и читаю, что к обслуживанию этих датчиков допускается только аттестованный персонал, подготовкой и аттестацией которого занимается служба главного механика комбината. А если такого персонала на предприятии нет, тогда служба главного механика обязана привлечь лицензированного подрядчика. От нас требовалась только заявка и к счастью, мы такую заявку в своё время подавали.

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

Вызывает нас главный инженер управления (из нашего клана). За столом сидит инспектор с дрожащим голосом и буквально трясётся. Он был уже не молод, поэтому его переживания вполне понятны (и это не смешно). Главный инженер спрашивает инспектора "ну что, пускаем в ход эту объяснительную?" В ответ инспектор просит уничтожить само предписание. Далее следует торг, негласная договорённость, и охрана труда нас больше не трогает. Так я приобрёл ценность в глазах главного инженера управления, которого, кстати, я увидел на этой встрече впервые. Позже мне стало известно, что известия о моей объяснительной докатились до высшего руководства нашего клана.

Почему именно два клана? Сперва образуется множество группировок. Победа одной группировки над другой неизбежно закладывает фундамент для следующей войны. Уничтожив сильного конкурента, победивший клан становится слишком большим и опасным для оставшихся игроков. Другие группировки, руководствуясь теорией игр, начинают объединяться в коалиции против нового гиганта, и цикл зачистки запускается заново.

Теперь о том, откуда у меня привычка пользоваться интеллектом. Всё дело в моей недисциплинированности, за что я был выставлен за дверь лекционной аудитории заведующим кафедрой. Он славился принципиальностью и неподкупностью. Его нельзя было обойти (т.е. сдать экзамен другому). У меня был только один способ сдать экзамен - выучить предмет наизусть.

Аспирант с моего этажа дал дельный совет про три прочтения конспекта:
1. Сперва просто читаешь конспект для получения кругозора и навигации. Не пытаешься заучивать и не останавливаешься.
2. Второй раз уже пытаешься вникнуть, но не зацикливаешься.
3. Третий раз читаешь уже детально и основательно. Заучиваешь и вникаешь.

Я взял конспект у одногрупника, и так выучил предмет. Пришёл на экзамен, вытянул билет, сел на первую парту и ответил без подготовки. Получил свою пятёрку.

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

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

Делюсь лайфхаком. В CLAUDE.md добавляем строку о необходимости использования принципа The Rule of Three by Gerald M.Weinberg (он знает что это). Т.е. перед принятием решения пытаемся его опровергнуть с как минимум трёх точек зрения (чем больше -- тем лучше). Противоречия синтезируют решение (1-й з-н диалектики).

Результат впечатляющий. Сикофантия купируется железно.

И второй лайфхак. Часто сперва обсуждают решение а затем по итогу делают ADR. Лучше сразу делать ADR и добавлять в него каждый возникающий аргумент обсуждения. Получается готовая матрица принятия решения. Когда решение становится очевидным, просто добавляется резолютивная часть.

В обсуждении прозвучала фраза "неизменность способности к эволюции".

Т.е. "неизменность изменяемости". Сравните с "отрицание пути".

Как сказал Kent Beck в одной из своих книг, "изменяется всё, кроме самого закона изменения".

Получается, что диалектика - это мета-программа алгоритма функционирования программы реальности.

Видимо, об этом термин "постоянство" в выражении "На Пути постоянства и отрицание Пути может быть Путем".