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

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

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

 

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

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

• плохой код;

• применение «костылей», перерастающих в проблему;

• наличие большого количества временных решений, которые не исправлялись вовремя;

• неправильный подход к своей работе и т. д.

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

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

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

 

Почему появляется технический долг

Может сложиться впечатление, что технический долг всегда получается из-за низкой компетенции разработчиков. Конечно, большой процент «долгов» получается именно из-за этого. Но очень часты случаи, когда компании при разработке своих продуктов влазят в технический долг самостоятельно. Связано это с тем, что им нужно срочно выпустить новый продукт в рынок, чтобы оценить его потребность и успешность. И если все хорошо, то потом такой продукт дорабатывается. Почему не делать сразу хорошо? Потому что на это бы ушло больше времени, а значит компании могли бы не успеть. Но дело в том, что такой  искусственный технический долг требует эффективного управления, чтобы не появлялись серьезные проблемы или угрозы. 

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

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

 

Технический долг и его классификация

Технический долг — это метафорическое выражение, которое может включать в себя много разных «задолженностей». Для структурирования этого понятия ему была задана классификация, которая содержит 3 вида технического долга:

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

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

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

 

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

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

Для управления техническим долгом  есть несколько подходов:

1. Постоянное время на исправление долга каждый день. Почему технический долг не исправляется? Потому что этому не хотят уделять время. Но это нужно делать обязательно, поэтому многие эффективные команды разработчиков специально выделяют примерно 15-20% рабочего времени каждый день на исправление долга.

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

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

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

5. «Дорогой» долг. Суть этого подхода в том, чтобы классифицировать технический долг по важности. Тот, который имеет прямое влияние на архитектуру приложения или его работоспособность,  нужно выполнять немедленно. Остальные – устранять по мере их важности.

 

Заключение

Технический долг у программистов будет всегда — этого не избежать, хотя бы потому, что не весь долг проявляется или сразу заметен программистам. Суть работы  с ним заключается в том, чтобы постоянно контролировать его объем, выделять время на его устранение и не делать его умышленно.