Нет предела тому, насколько плохим может быть код

Существует устойчивая метафора для запущенных кодовых баз: тонущий корабль. Она подразумевает неизбежный конец — момент, когда вода достигает палубы и все покидают судно. Но это вводит в заблуждение. Как утверждает Зак Керс в своем эссе Нет предела тому, насколько плохим может быть код, в отличие от физического корабля, программная система не имеет структурного предела. Вы можете бесконечно добавлять сложность; она не рухнет. Просто станет медленнее, труднее для изменений и мучительнее для работы.

Реальный пример из Amazon

Керс описывает свой десятилетний опыт работы в команде обработки заказов в Amazon. Основная функция системы — запись в базу данных и вызов других сервисов — должна была обслуживаться двумя десятками инженеров. Однако в организации работали сотни людей. Институциональные знания разрушались по мере ухода инженеров, оставляя «обитаемые призраками кладбища» в коде. Бизнес-правила часто не документировались, а система охватывала границы команд, что делало трассировку невозможной.

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

Почему метафора не работает

Ключевое понимание автора: бизнес может утонуть — но само программное обеспечение не утонет. Код всегда может стать хуже. Всегда есть еще один уровень косвенности, еще одно ухудшение производительности. Но по иронии судьбы, бизнес часто умирает раньше, чем код достигает какого-либо «дна».

Для разработчиков, работающих с устаревшими системами, вывод заключается в том, что «тонущий корабль» дает ложное утешение. Нет точки невозврата, где все волшебным образом сбрасывается. Если вы находитесь в такой системе, вы не ждете, когда она утонет — вы ждете, когда кто-то решит, что стоимость изменений превышает стоимость сохранения статус-кво.

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