Долг платежом красен

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

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

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

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

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

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