Комментарии 6
Спасибо за статью. Очень важно и полезно. Много вокруг явных примеров непонимания всего о чем Вы пишете и удивленных вопросов: "Как же ж так ? Что ж такое ?"
Ещё один важный момент с техническим долгом - работать на упреждение. А именно, следить за появлением новых фич в испрльзуемом языке, фреймворке и т.д. А также следить за планами разработчиков языка или фреймворка по объявлению старых фич deprecated, чтобы отказываться от устаревших фич не в последний момент, а постепенно.
Поясню на примере. Сейчас в Symfony и её производных отказываются от doctrine annotation в пользу php атрибутов. Сейчас большинство проектов поддерживает оба способа, но это значит, что уже сейчас в новом коде надо полностью отказаться от аннотаций. Тот, кто продолжает их использовать сейчас, увеличивает технический долг, который придётся решать во время обновления мажорной версии фреймворка.
И да, кстати, простота или сложность обновления мажорной версии фреймворка - это лучший индикатор того, насколько хорошо или плохо на проекте обстоят дела с техническим долгом.
Как по мне, архитектурный, технический и прочие "долги" уже должны быть заложены в жизненный цикл продукта при его выпуске в свет. Заложить запланированную и маштабируемую неопределенность. Но это как раз одна из тех неочевидных идей, на которые решаются немногие команды.
Пожалуйста, не используйте "принцип бойскаута". Приходит на PR diff +1000 -1000. Из которых к постулируемой задаче относится +100 -100, а оставшиеся +900 -900 от "бойскаута". И ревьюер не может хорошо отревьюить ни то, ни другое. Более того, в blame потом складывается впечатление, что код менялся под продуктовую фичу, и археолог должен потом с трудом разбираться зачем менялось столько кода под неё. Самые разрушительные баги я наблюдал в коммитах с названием "minor refactoring".
Не делайте как бойскаут. Отделяете PR с бизнес логикой от решения тех долга.
Не тому адресату статья адресована.
Зачастую линейный менеджмент в ИТ загнан в такие жесткие сроковые рамки и имеет горизонт планирования "еще бы день продержаться", что никакой мотивации им вешать статью расхода на бизнес в виде "надо бы техдолг разгрести" у них не остается. И менеджмент над менеджментом так же, им надо владельцам управленцам продать "сразу и еще вчера", "забить нишу на рынке". А владельцу надо ренту собирать, а не вот это вот все.
Сама система управления порочна в этом аспекте и порождает "техдолг" и далеко не только в кодовой базе, в вообще в принципе. В товарных остатках на складах, когда попытка инвентаризации вгоняет мол-ов в седину, в состоянии основных средств когда на бумаге здание есть, а на деле там свалка уже, в тех же взаиморасчетах когда вся будущая прибыль уже съедена выплатами по долгам, в кадровой политике когда компетенции персонала уже не соответствуют, везде, где применяется принцип "давайте сначала продадим, а потом, может быть.."
И иметь нулевой техдолг в кодовой базе когда все остальные висят домокловым мечем над организацией - выглядит перекосом.
Да, с горизонтом планирования прямо беда.
И вот значит, выходит бойскаут разработчик и в свое личное время начинает рефакторинг, так его учили умные дядьки из университетов.
Получит ли он за это деньги? Нет, но люлей получить может за сломанный код.
Получит ли он за это одобрение других разработчиков? Немножко. Но он быстрее уволится, чем эффект рефакторинга сработает.
Вот и выходит, что рефакторинг это чистка кармы, не более.
Архитектурное банкротство: как технический долг убивает проект