Технический долг платежом красен

В eCommerce, как и в любой другой области, тесно связанной с программированием, часто встаёт проблема добавления в систему новой возможности.

Одно решение гораздо проще реализовать в сжатые сроки и успеть к очередному очень важному релизу, связанному с новой акцией, маркетинговой программой или внутренними планами компании. Однако оно будет более затратное в сопровождении, менее расширяемое или менее надёжное.

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

C подобным выбором сталкивались и сталкиваются если не все, то практически каждый развивающийся проект и именно из этого выбора появилось понятие технического долга, впервые сформулированного Вардом Каннингемом в 1992 году.

Технический долг — очень популярный термин, и всегда находится кто-то, предсказывающий крах из-за его наличия. Зачастую технический долг в общем понимании — это что-то однозначно негативное и плохое. Но это не всегда так.

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

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

Также не стоит воспринимать неоптимальное стратегическое решение как возможность относиться к разработке «спустя рукава». При разумном подходе это означает, что такое решение должно быть локализованным и использовать как можно меньшее число модулей и технологий, чтобы можно было его изменить позднее, не затрагивая остальные части системы, что значительно снизит стоимость будущих доработок.

Если же эти принципы нарушаются, то впору говорить о квалификации команды разработки: отсутствие автотестов, низкая частота релизов, отложенный рефакторинг, жёсткая связанность компонентов инфраструктуры, отсутствие стандартов и компетенций. Всё это приводит к тому, что накапливается огромный груз крупных стратегических и тактических ошибок, вроде длинных функций с неочевидными обязанностями и сложными побочными эффектами, расплывчатых классов с нечеткими границами; отсутствие документации и т. п. И тогда уже мало у кого возникнет идея действовать в подобном ключе, а если у кого и возникает, то она быстро пропадает из-за того, что плыть против течения очень сложно. Это, в свою очередь, приведет к низкой продуктивности разработчиков и взаимной неудовлетворенности команды разработки и клиента.

Резюмируя, можно сказать, что выбирая путь компромисса, все заинтересованные участники проекта должны четко понимать последствия таких решений и бороться за уменьшение их влияния на систему. Отслеживать же последствия достаточно просто, так как все они чётко измеримы в денежных единицах на основе оценки размера технического долга. Ну а если долг растёт, а качество кода только ухудшается, впору задуматься о смене команды разработки, потому что рано или поздно возникнет технический дефолт и вот тогда действительно будет поздно меняться.