Четыре типа сложности

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

Сложность ПО — не одна вещь. Брукс сорок лет назад разделил её надвое: существенная и случайная. После двадцати лет в банках, корпоративных системах и AI-инфраструктуре двух категорий стало не хватать. Вот четыре.

Сложность бизнеса

Неустранимый вес самой задачи. У банковских систем действительно есть регуляторные ограничения. У страховых продуктов действительно есть краевые случаи. Логистическая система правда обязана моделировать склады, маршруты и сроки. Реальность нельзя упростить.

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

Стратегия: принять то, что принадлежит реальности, распределить равномерно по системе и время от времени проверять, осталось ли ограничение ограничением.

Сложность инструмента

Сложность, которую инструмент приносит с собой. Spring Boot — не ваша бизнес- задача. Kubernetes — не ваша бизнес-задача. Unity — не ваша бизнес-задача. Но однажды выбранный инструмент становится несущим: его допущения формируют всё, что построено сверху.

Эта сложность не несёт бизнес-ценности и после выбора не убирается. Она — реальность, данная в ощущениях. Её обходят, с ней не воюют. Больше всего боли здесь у команд, которые выбрали инструмент и отказались работать так, как он ожидает: за фреймворк платят дважды — один раз выбором, второй раз сопротивлением.

Стратегия: выбирать осознанно, а выбрав — дойти до той степени принятия, на которой начинают доставаться сильные стороны инструмента, а не спор с его устройством.

Случайная сложность

Сложность, возникшая потому, что кто-то не увидел более простого пути. Бизнес-ценности ноль, а доля в общем объёме обычно наибольшая.

У неё есть опасное свойство, определяющее всё остальное: тот, кто её создал, её не видит. Не «не хочет» — не может. Изнутри каждая абстракция в момент добавления выглядела разумной. Команда добавляет временный слой, чтобы не закрывать себе варианты, потом второй — чтобы компенсировать первый, и в конце систему уже никто не держит в голове целиком. Каждый шаг был локально осмысленным. Сумма — нет.

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

Стратегия: привести человека, у которого нет эмоционального вложения в нынешнюю архитектуру. Свежий взгляд находит случайную сложность гораздо надёжнее, чем свои, а аргументированное несогласие стоит дороже согласия: десять слов «почему нет» весомее двух страниц «почему да», потому что несогласие вскрывает допущения, а согласие их закрепляет.

Сложность от нехватки инструмента

Сложность, вызванная отсутствием инструмента, который должен был бы существовать, — и не существует. Самая недооценённая из четырёх и единственная, у которой недавно изменилась экономика.

До AI внутренние инструменты стоили достаточно дорого, чтобы организации привыкали к боли вместо того, чтобы её решать. Повторяющаяся ручная работа, неудобные передачи, операционное трение — всё это принималось как погода. Цену никто не оспаривал, потому что альтернативой был квартал инженерного времени.

Это допущение больше не держится. Unity Bridge занял вечер и превратил «AI не умеет работать в редакторе Unity» в пятнадцатиминутный маршрут. Та же картина была внутри банковской среды: недостающий внутренний инструмент, сделанный быстро, заменил то, что раньше требовало месяцев процесса. И эффект накапливается — каждый следующий инструмент дешевле предыдущего, потому что предыдущий стал частью того, чем вы строите.

Сложность была не в работе. Она была в отсутствии нужного инструмента.

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

Четыре рядом

Категории заведены не ради классификации. Они различаются ровно по тем двум осям, которые решают, что делать дальше.

Из таблицы следуют два чтения.

Удалить начисто можно только одну из четырёх. Случайная сложность — единственная категория, где удаление почти чистый выигрыш, и оно, как правило, приносит положительные побочные эффекты, которых никто не планировал. Сложность бизнеса и инструмента не удаляется вовсе. Но её можно размазать: тонким слоем по системе вместо плотного комка в одном месте. В этом и состоит бóльшая часть ремесла. Архитектуру судят не по количеству сложности, а по равномерности её распределения.

Опасны обе невидимые. Случайная прячется потому, что её автор уверен: это и есть простейшее решение. Нехватка инструмента прячется потому, что боль уже принята как факт жизни. Ни одна не объявится сама на ретроспективе. Обеим нужен человек снаружи или заранее заданный вопрос, чтобы стать видимыми.

Один механизм превращает управляемые типы в удаляемый: смешивание слоёв порождает случайную сложность. Бизнес-правила, переплетённые с транспортом, транспорт — с хранением: каждая такая смесь есть новая сложность, не принадлежащая ничьей предметной области. Слоёную архитектуру обычно подают как лучшую практику. Точнее считать её следствием: разделите слои — и доля случайного упадёт сама.

И правило, которое держится на разных проектах: фокус на инструментах сложность растит, фокус на бизнесе — снижает. Команда, говорящая в основном о своём стеке, наращивает вторую и третью категории. Команда, говорящая в основном о задаче клиента, их сокращает.

У каждого инженера есть термостат

Вот чего четыре категории сами по себе не объясняют: почему два грамотных инженера, глядя на одну систему, расходятся в том, слишком ли она сложна.

У каждого инженера есть комфортный уровень сложности, и он трансформирует задачу, пока она этого уровня не достигнет. Низкий термостат упрощает: его суперсила — найти простейшую модель под задачей, его отказ — потерять то, что было нужно. Высокий наращивает: он держит тяжёлую нагрузку без напряжения и растит случайную сложность, не замечая этого.

Последнее и есть полезная часть. У высокого термостата есть зона нечувствительности: малые добавления лежат ниже его порога восприятия. Как весы, начинающие с килограмма, он не регистрирует граммы — а они накапливаются. Отсюда системы тяжелеют без единого решения, которое кто-нибудь назвал бы ошибкой.

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

Лучшая архитектура рождается, когда два термостата тянут друг против друга: один вверх («ты выбрасываешь то, что понадобится»), другой вниз («ты добавляешь то, о чём никто не просил»). Не как этап ревью, приделанный в конце, а как живой спор во время проектирования. Команда, укомплектованная под согласие, лишается этого прибора целиком.

Стоит заметить, как сложность ощущается до того, как её удаётся измерить. Она приходит как нарушение гармонии: веер возможных следующих действий сужается, ландшафт закрывается. Упрощение ощущается наоборот — варианты открываются, движение снова становится дешёвым. Это не мистика, а быстрое считывание того, сколько ходов система ещё допускает. Оно приходит задолго до любой метрики, и доверять ему стоит хотя бы настолько, чтобы пойти и проверить.

К AI-ассистентам это относится в полной мере и довольно резко. Их обучающие данные — корпоративные паттерны, слои абстракций и design patterns, поэтому термостат у них по умолчанию высокий. Попросите архитектуру — получите грамотный ответ, который тяжелее, чем требовала задача. Знание об этом и есть бóльшая часть поправки.

Пятый кандидат: язык

Есть ещё один, и он недооценён почти до невидимости: сложность самого естественного языка.

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

Лечения у этого нет, есть компенсация: нести смысл носителями разной природы. Диаграмма, рисунок, метафора, разобранный пример рядом с прозой. Мультимодальность не делает язык точным — она уменьшает потери при передаче, а это ровно та часть, которой вы управляете.

Отсюда две рабочие привычки. Контролировать понимание, а не исполнение: следить за тем, как человек реализует, смысла мало, а попросить его описать задачу, которую он собирается решать, — много, потому что ответ вскрывает расхождение, пока оно дёшево. И останавливать проработку на восьмидесяти процентах: техзадание невозможно довести до ста, не нужно доводить дальше восьмидесяти, а оставшуюся пятую часть дешевле выяснить на ходу, чем предугадать заранее.

Зачем это

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

Поэтому когда кто-то говорит система слишком сложная, полезный вопрос больше не «как её упростить?».

Полезный вопрос: с какой именно сложностью мы имеем дело?

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