Technical-Debt

Позвольте мне быть откровенным: я присутствовал на множестве совещаний, где инженеры с энтузиазмом объясняли, почему нам нужно провести рефакторинг модуля аутентификации, но при этом видел, как у бизнес-стейкхолдеров стекленеют глаза, словно они наблюдают, как сохнет краска в плохо освещённом складе. Ответ всегда один и тот же: «А нельзя ли сначала просто выпустить функцию?» Болезненная правда заключается в том, что большинство из нас подходят к этому разговору, пытаясь убедить кого-то, что брюссельская капуста вкусная....

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

В вашем экземпляре Jira прямо сейчас существует метафорическое кладбище. Где-то между столбцом «В процессе» и глубинами вашего бэклога, вероятно, есть тикет, созданный три года назад с пометкой «Исследовать потенциальные улучшения производительности», на который никто не обращал внимания со времён Великой Рефакторинга 2023 года. Может быть, таких пятьдесят. А может, пятьсот. Я собираюсь сделать спорное заявление и готов к гневным комментариям: вероятно, вам стоит удалить большинство из них. Это не обычная статья с советами по повышению продуктивности, в которой вам говорят использовать более качественные метки и внедрять больше автоматизации (хотя это тоже важно)....

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

Мы любим говорить о техническом долге. Это монстр под нашей кроватью, виновник медленных спринтов и разочарованных разработчиков. «Нам нужно провести рефакторинг», — кричим мы. «Базовое кодовое хранилище — беспорядок!» — протестуем мы на ретроспективах. Но вот неудобная правда, которую никто на вашем последнем совещании по архитектуре не хотел услышать: иногда настоящий виновник — это не быстрые исправления и короткие пути. Иногда всё наоборот — мы создали нечто слишком хорошее для того, что на самом деле нужно было сделать....