Что такое технический дефолт и как его избежать

Довольно популярным понятием в программировании является технический долг, он характеризует степень неудобности работы с неким кодом, которая заложена в него в процессе написания этого кода и пропорционально тормозит разработку (и не только, но об этом далее). Технический дефолт таким образом высшая степень разрастания технического долга.

Чтобы понять эту зависимость, нужно рассмотреть, как происходит сам процесс "займа" и как действует взятый кредит. Для начала предположим, какой срок будем считать успешным, на протяжении которого наблюдаемое уменьшение технического долга будет считаться "погашением" кредита. Допустим это 15-20 лет. Некоторые веб-ресурсы и даже программы такой давности всё ещё существуют. В единичных случаях сохранились даже ещё более древние, но работающие, системы на перфокартах. Но в неограниченной перспективе технического развития устаревает всё и довольно быстрыми темпами.

Ситуацию можно показать на примере того, как если бы вам провели электричество в доме со значительным техническим долгом, на скорую руку. С виду все работает, розетки, переключатели, осветители в порядке. Но проблема возникает, если вы решили добавить еще одну розетку, например. Приходит электрик и вдруг оказывается - надо три дня и соответственный ценник для такой, казалось бы, пустяковой работы. Оказывается, в прошлый раз выбрали эконом установку и теперь нужно тянуть отдельный провод через весь дом. К тому же можно случайно повредить еще пару электрокоммуникаций, которые также сделаны с нарушением правил. А отключить их вообще не выйдет, так как часть идёт мимо основного выключателя в щитке, потому как так было быстрее. Это умозрительный пример, но всё же в некотором роде характеризует проявление технического долга. К счастью, есть жесткие правила построения таких коммуникаций, чего не скажешь о разработке программного обеспечения.

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

Каждый раз, когда программисту не хватает времени на задачу - он задумывается, как бы схитрить, и как только он об этом задумывается, то неизбежно придумывает костыль, временную подпорку для конструкции. Потом он собирается к ней вернуться, когда будет время, но времени не появляется (при такой то профессии!) и останется так. На основе работающего, но сомнительного кода, накладывается потом ещё заплатка на заплатку, так как без переписывания основы нельзя. Таким образом накапливаются дополнительные "проценты", а программист уже хочет сделать хорошо (допустим), времени чуть больше, но и объем предстоящих исправлений тоже вырос. Возможно, единственным неправильным решением будет всё переписать с нуля. Это не опечатка, нужно не переписывать проект, а заниматься его постепенным рефакторингом.

Объяснить руководству, что такое "рефакторинг" намного сложнее, когда польза от него проявится, пройдут годы, да и после тоже, сравнивать то будет не с чем. По поводу переписывания, ну вот, предположим, проект пятилетней давности, его все это время наполняли кодом пять программистов, и они торопились при этом. Вопрос, сколько месяцев нужно, чтобы не торопясь, вдумчиво и основательно, теми же силами, написать его заново? Боюсь, ответ не будет принят всерьез. Более того, к тому времени всё это начнёт устаревать.

Мне известен случай, когда проект был переписан полностью в течении года, также довелось работать на этом проекте через некоторое время и ничего сверхестественного там не увидел, так как после переписывания не были приняты меры для предотвращения создания новой задолженности. Но это обычный технический долг, с которым сожительствуют многие компании. Кстати, здесь везде имеются ввиду IT-компании, зависящие от отдела разработки, а не просто веб-отдел предприятия. Иначе - какой может быть риск?

При этом всём нет разницы, как код организован, то есть какой принцип был заложен - DDD или по Роберту Мартину разбитие не по образцу реальной модели, а от изменяемости компонентов, любой другой способ упорядочивания архитектуры, даже если там нет OOП, но есть строгость, стандарты и порядок. Технический долг есть как раз не следствие выбранной архитектуры, а в противовес - не следование стандартам и беспорядок.

Технический дефолт же, по крайней мере очень близкое к нему приближение, наблюдал в довольно крупной компании (B2B), при этом если бы вы увидели публичный чат технической поддержки, куда пишут менеджеры и внутренний чат, где они же переписываются с разработчиками и девопсами, то увидели бы такую картину:

Публичный чат:

Наша компания - в списке лучших за год!!

Представляем вам новый функционал.

Для наших любимых клиентов мы постоянно улучшаем платформу!

В новой статье мы рассказываем, как правильно настроить рабочие процессы в компании.

Три года стабильной работы на рынке!

Внутренний чат:

! ! ! Второй раз за неделю наблюдаем недоступность сервера такого-то.

Ребят, с утра не работает авторизация, клиенты в ярости :(

Все разработчики брошены на проблему такую-то, пока некогда.

Заведите задачу. Потом посмотрим...

И так ежедневно... Хотя может и выглядеть узнаваемо.

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

Как избежать технического дефолта? Угроза его возникает из-за перетягивания хотелок в сторону бизнеса. Понятное дело, бизнесу нужны новые изменения продукта для улучшения притока денежных средств и напоминания всем о своём существовании, а программисты продвигают улучшения условий собственного труда. Иногда последним нужно вернуться немного назад, чтобы навести порядок. Если на это времени нет, то будет накапливаться беспорядок. А от беспорядка у программистов ухудшается настроение и они пишут код более неряшливо. Замкнутый круг.

Есть еще аргумент в пользу рефакторинга кода, это что-то вроде "эффекта разбитого окна", ведь всегда есть искушение писать код таким же, в каком он окружении находится. Ежедневное чтение и разбор костылей не приведут к личному прогрессу в области создания первоклассной архитектуры.

Но не стоит отчаиваться! Те программисты, которые привыкли обитать среди технического долга, вытащат из падения в пропасть любую компанию, хотя слово "вытащат" не совсем уместно, они же не будут знать, что дальше делать. Поэтому компания останется на плаву в удовлетворительном состоянии (на три с минусом) и техническое банкротство не может ей грозить в любом случае. Ведь технический долг замедляет создание новвоведений, и, если перестать их требовать как можно быстрее, смириться, что нужно два работника там, где раньше нужен был один, и неделя вместо одного дня, то с проектом ничего плохого не произойдет с технической стороны. Особенно, если вообще ничего не трогать. Есть даже поговорка: работает - не трогай. Хороший продажник бы уже задумался, как это премущество выгодно преподнести клиентам!