СЕРИЯ · decision-cycle
Цикл одного решения
Цикл одного решения · 8 постов о дисциплине принятия архитектурных решений
-
Кладбище решений: почему через полгода никто не помнит, почему вы выбрали один способ авторизации, а не другой
Команды накапливают невидимый долг не в коде, а в забытых архитектурных решениях. Notion и Confluence эту проблему не решают - нужен другой формат записи. Разбираю, как выглядит этот долг на конкретных кейсах и что в формате решения должно быть, чтобы оно через год оставалось полезным.
-
Перед тем как чинить - выпишите три версии причины: приём следователя, который превращает 30 минут случайного фикса в 5 минут точной диагностики
Хороший следователь не фиксируется на первой версии. Он выдвигает три-четыре, описывает проверяемые следы, идёт проверять. Тот же приём - ADI - превращает торопливый фикс не туда в десять минут честной диагностики. Разбираю на двух кейсах: падение конверсии и медленный поиск.
-
Среднее обманывает: почему доверие к решению ограничено самым слабым доказательством, а не их средним
Whitepaper вендора и скриншот Slack-замера могут иметь одинаковое 'среднее качество', но опираться на них для решения - это разные ставки. Разбираю формулу R_eff: три оси доказательства, правило слабого звена, контекстное соответствие - и почему один свой замер сильнее десяти статей из чужих блогов.
-
Мотивировочная часть для архитектурного решения: как сделать запись, которая через год сама себя откроет на пересмотр
Судья пишет, какие доказательства рассмотрены, какие отвергнуты и почему. Через год дело можно пересмотреть. Тот же приём нужен архитектурному решению - иначе через два квартала оно становится памятником. Разбираю шесть секций DDR, особенно последнюю - условия пересмотра.
-
Архитектор не начинает с чертежей: четыре фазы, через которые проходит любая нетривиальная задача - осознанно или нет
Между одной строкой в чате и работающей функцией - четыре фазы: расширение пространства решений, разбор на части и крайние случаи, выбор варианта, документ-контракт. Вопрос только в том, пройдёт ли их команда в документе за день - или в коде за две недели разгребания последствий.
-
Спецификация - это не PRD, это контрольный вкус: чем намерение отличается от поведения и почему разница огромна на практике
Рецепт может звучать вкусно и быть невыполнимым. Финальный вкус блюда проверяется только едой. PRD - это рецепт. Спецификация - это контрольный вкус: проверяемое поведение системы, дельта-формат изменений как у сообщений коммитов, граф зависимостей между смежными спецификациями.
-
POS-терминал для методологий: что такое Forgeplan и зачем держать четыре способа работы в одной плоскости
Официант не держит в голове прайс, состав блюд, налоги и бонусы. Он нажимает кнопки в терминале, а терминал помнит всё. Forgeplan - это POS-терминал для методологий: четыре способа работы в одной плоскости, чтобы человек выбирал содержание, а механика была снаружи.
-
Полный цикл на одной функции: от строки в чате до записи, которая через год сама себя откроет на пересмотр
Шесть месяцев назад в чате была одна строка: 'нужен streaming для ответов модели'. Сегодня в репозитории - связанный набор из шести файлов, помеченных как активные, с измеренной надёжностью и явными условиями пересмотра. Капстон серии: путь от строки до решения через семь шагов на одной задаче.