Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?
Программист: ну, представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу, как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер». Выясняется, что он в следующей главе облокачивается о столб, которого уже нет…
Источник дефектов кодирования и проектирования очень часто находится вне программного кода.
В какой-то момент усталость кода и размеры технического долга вырастают настолько, что скорость разработки нового функционала существенно падает на фоне резкого увеличения регресса системы, после внесения изменений. Наступает технический дефолт.
Кардиолог приезжает в автосервис, ему работяга машину чинит, потом говорит:
— Слышь, мужик, вот я мотор перебираю — и ты мотор перебираешь, только человеческий — почему тебе платят на порядок больше?
Кардиолог кивает, идёт к машине, включает зажигание и говорит работяге:
— А попробуй при работающем движке теперь перебери!
Честно говоря, такой человек чаще решает не технические проблемы, хотя является сильным разработчиком, а организационные и политические проблемы.
Главному архитектору мало иметь технические компетенции, он должен быть ещё и жёстким управленцем с развитым стратегическим видением.
В случае если со стороны этого самого «главного архитектора» недостаточно контроля за ситуацией либо его вообще нет, начинают происходить аварийные ситуации. Как это происходит? Например, у вас есть сервис, который предоставляет наружу какое-то API. Рядом с вами без предупреждения выскакивает какой-то очень-очень важный для бизнеса сервис, который начинает генерить на вас нагрузки столько, сколько все остальные системы вместе взятые. А о вас просто при планировании забыли. Нет, ну правда. И бюджет на расширение ваших мощностей заложить забыли. Не потому, что программисты плохие, а потому, что менеджер либо владелец системы свой KPI улучшает.Потом начинается либо эпидемия, либо война, либо просто конец света. Нагрузка на вас растёт ещё и ещё, ваша система перестаёт справляться.
Здесь тоже можно вспомнить о JSDD, особенно о приёме, когда всё роняют и героически восстанавливают. Только здесь оно будет падать само, а поднять всё либо просто не дать упасть, будет стоить команде очень больших усилий.
Опытные разработчики, наоборот, упрощают конструкции в своём коде, помня, что они не одни и не навсегда.
Почему это всё важно? Потому что существует организационный антипаттерн «Рыцарь на белом коне» (Knight in shining armor, KISA), который приходит, решает проблемы, которые никто не может решить. Но потом он уходит и больше не возвращается. В результате может получиться уникальный код, созданный божественным разумом, который никто вокруг не может поменять. А бывает надо, бизнес же не стоит на месте.