git и технический долг

05.09.2019

git

Идрис Кубатаев прочитал введение в git и продемонстрировал основные сценарии не отходя от терминала.

Технический долг

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

Сформулировали вопросы, которые интересуют нас, когда речь заходит о техническом долге.

1. Что это такое? Нет общепризнанной формулировки.
2. Как оправдаться? Как объяснить менеджерам? Как продать техдолг? Большинство программистов воспринимает технический долг как то, что касается только их, и не касается бизнеса.
3. Как отдавать? Когда отдавать? Что делать? Детали отдачи долга вызвали бурное обсуждение.

Что такое технический долг?

Первое, весьма занятное определение — фичи, нужные только разработчикам.

Второе определение близко к тому, что говорит Мартин Фаулер в своей статье. Технический долг — то, что мешает быстро развивать проект. Например:

• Дублирование кода.
• Сильные связи.
• Отсутствие документации.
• Много неисправленных ошибок.
• Отсутствие тестов.
• Архитектурные проблемы.

Как рабочее определение можно брать технический долг именно так, как определяет его Фаулер. Это метафора, которая проводит параллель с финансовым долгом. Если мы заняли деньги в банке, то мы возвращаем не только сам кредит, но и проценты. Точно также, недоделанный код заставляет нас тратить дополнительное время на внесение изменений. Это время — проценты по техническому долгу. Если мы потратим время на переписывание («вернём» техдолг), мы перестанем тратить время на внесение изменений.

Если принять эту метафору, то техническим долгом не являются:

1. Появление новых версий библиотек. Переход на них не обусловлен потребностями бизнеса.
2. Сильное изменение технических требований, которое вызывает большие изменения в кодовой базе. Мы просто пишем новую программу.

Что не так с техническим долгом?

Метафора это хорошо. Но с ней есть проблемы.

1. Технический долг нельзя посчитать. Да, в статье Фаулера есть пример с экономией времени, но цифры для примера он взял с потолка. Если вы попробуете посчитать цифры реально, у вас может просто не получиться.
2. Преждевременная оптимизация зло. Брукс говорит, что первая версия системы пишется на выброс. Если взять этот подход в качестве рабочей модели, можно писать первую версию максимально быстро, собирая информацию о предметной области и подводных камнях. Технический долг в первой версии можно не отдавать, потому что систему можно переписать. Но это только в том случае, если первая версия действительно пишется на выброс, чего в реальности не бывает.
3. Не факт, что ситуация исправится кардинально. Если в системе сложная логика, много агентов, большая кодовая база, внесение изменений может оказаться длительным просто потому, что такова система. Возврат технического долга может не повлиять кардинально на эту ситуацию.