Одна идея этого урока: у сеньора есть единственный универсальный критерий любого решения – уменьшает оно сложность системы или увеличивает.
Знакомая ситуация
Ты делаешь приложение с ИИ-агентом. Первые дни – восторг: фичи появляются за минуты. Через пару недель что-то меняется: просишь поправить мелочь – ломается другое. Агент «чинит», и ломается третье. Каждая итерация всё дольше и рискованнее.
Это не агент испортился. Это в приложении накопилась сложность – и никто её не сдерживал.
Сложность (complexity) – это всё в устройстве системы, что мешает её понимать и менять. Джон Оустерхаут: главная цель проектирования – не «красивый код», а минимум сложности.
Три симптома сложности
Сеньор распознаёт болезнь по симптомам – запомни эти три, они будут в каждом следующем уроке:
1
Изменение против шерсти change amplificationМаленькое изменение требует правок в куче мест. «Поменяй цвет кнопки» превращается в правку 8 файлов.
2
Когнитивная нагрузка cognitive loadЧтобы безопасно что-то поменять, нужно держать в голове слишком много. Если ты (или агент) не можешь коротко объяснить, как работает часть системы – нагрузка уже чрезмерна.
3
Неизвестные неизвестные unknown unknownsСамое опасное: непонятно даже, ЧТО нужно учесть. Именно поэтому «почини одно – сломалось другое».
Ключевой факт: сложность приходит не одним большим куском, а тысячей мелких «да ладно, и так сойдёт». Каждое по отдельности безобидно. Сумма убивает проект.
Два режима работы
Оустерхаут делит подход к разработке на два режима – это водораздел между уровнями:
Джун · тактический режим«Главное – чтобы заработало сегодня». Каждая фича – кратчайшим путём. Структура портится незаметно, зато быстро. Так же по умолчанию работает ИИ-агент, если его не направлять.
Мидл · тактический режим с уборкойЗамечает бардак и чинит его по факту: «вот тут надо отрефакторить». Уже видит сложность, но борется с ней реактивно, когда она уже мешает.
Сеньор · стратегический режим«Рабочий код – не цель, а побочный эффект хорошей структуры». Постоянно вкладывает ~10–20% усилий в дизайн и упрощение – до того, как заболит. Медленнее сегодня, кратно быстрее через месяц.
Это и есть инвестиционное мышление: стратегический режим – не перфекционизм, а расчёт. Скорость проекта на длинной дистанции определяется не тем, как быстро добавляются фичи, а тем, как медленно растёт сложность.
Проверь себя
1. Агент предлагает: «Могу быстро добавить оплату, встроив её прямо в код страницы заказа, либо сделать отдельный модуль оплаты – это дольше». Что скажет сеньор?
Оплата – классическая точка будущих изменений (провайдеры, валюты, возвраты). Встраивание в страницу – тактический выигрыш сегодня и «изменение против шерсти» навсегда. А «сделать оба» – это удвоенная работа и удвоенная сложность.
2. Какой из симптомов говорит, что сложность уже критическая?
Первые два симптома неприятны, но видимы – с ними можно работать. «Неизвестные неизвестные» невидимы: ты узнаёшь о них, когда что-то ломается у пользователей. Это самый опасный симптом по Оустерхауту.
3. Ты просишь агента добавить мелкую фичу, он отвечает: «Готово, добавил, плюс пришлось поправить логику в четырёх других файлах». Твоя реакция как сеньора?
Это «change amplification» в чистом виде. Дело не в количестве файлов как таковом (правило «один файл» – карго-культ), а в том, что мелкое изменение расползлось. Сеньор использует это как диагностику: «почему мелочь трогает четыре места? что тут спроектировано не так?»
Что говорить агенту уже сегодня
Перед фичей: предложи вариант, который минимально увеличит сложность системы
При ревью плана: какие будущие изменения это решение сделает дорогими?
Регулярно: что в проекте сейчас главный источник сложности? предложи, как упростить
Симптом-детектор: почему мелкое изменение потребовало правок в стольких местах?