Работа, которую вы откладываете, только накапливает технический долг
15 ноября 2022 г.Что это?
Технический долг — это отложенная работа на потом. В качестве аналогии с обычной жизнью можно привести пример обеда. Вы приготовили еду и поели, но не помыли посуду. Пока все хорошо, вы довольны и сыты, но когда-нибудь вам придется мыть посуду.
Поскольку код уже написан, эта работа может потребовать некоторых улучшений или оптимизаций. Но важно отметить, что эти улучшения либо не окажут никакого влияния, либо окажут очень незначительное влияние на конечный продукт. Все они нацелены на разработчиков как на конечных пользователей. Если бы это было не так, то это была бы стандартная задача.
Как это выглядит?
На самом деле обличий у него много и они могут зависеть как от специфики проекта, так и от условий, в которых проект существует. Ниже приведены лишь некоторые из них:
- Архитектура не соответствует требованиям приложения или полностью отсутствует. Худший пример, который вы можете себе представить, это то, что все приложение написано в одном файле длиной в сотни строк.
- Сильная согласованность кода в приложении. На уровне проектов, компонентов, классов, модулей и т. д. Изменение в одной части вызывает неожиданные последствия в, казалось бы, не связанных между собой вещах.
- Нет ничего более постоянного, чем что-то временное — специальные/одноразовые решения. «Тут и здесь я добавлю новое условие только специально для этого случая, а позже уберу».
Откуда это?
Технический долг часто можно рассматривать как список компромиссов со стороны технической команды ради команды продукта. Его еще называют компромиссом качества и скорости. Хоть это и называется техническим долгом, но ответственность за него поровну распределяется между всеми людьми на проекте. Такие компромиссы под капотом могут быть вызваны
- необоснованные требования,
- плохое общение или недопонимание,
- нереальные сроки,
- низкая квалификация членов команды
Это уже приводит нас к низкому качеству кода, длительному времени разработки, нестабильности приложения и низкому уровню ремонтопригодности.
Как бороться?
Первое и самое сложное, не ищите виноватых, нужно отдать долги. Далее нужно оценить масштаб трагедии. Бывают запущенные случаи, когда проще назвать систему наследием и относиться к ней как к наследию. Но зачастую это все же поправимо, и тогда мы используем принцип – разделяй и властвуй. Все долги должны быть зарегистрированы, приоритизированы и всегда готовы попасть в очередь на обработку.
Не следует забывать, что лоббирование идеи погашения долга полностью на стороне этих команд. Команда продукта и бизнес в целом не компетентны в этих вопросах и оценивают их и расставляют приоритеты самостоятельно.
И самое главное, профилактика. Долги должны контролироваться и управляться. Постоянно выделяйте время для работы над ними, это должно быть систематически.
Заключение
Для многих продуктов, особенно стартапов, важным фактором часто является время. Как быстро выйти на рынок, занять новую нишу или создать эту нишу, успеть привлечь как можно больше клиентов, а если по ту сторону вашего продукта бескомпромиссный техлид, который не позволит вам отправить нового киллера особенность производства до тех пор, пока она не сияет, это часто может быть фатальным для всего продукта. Обратное утверждение абсолютно точно так же верно. Когда продуктовая команда не выплачивает такие долги, существует ненулевой риск потери как уровня качества, так и надежности с возможностью поддержки этой системы.
Поэтому работа с техническим долгом — это движение от двух крайностей, и в этом движении главное найти баланс, золотую середину. Баланс, при котором долг возникнет, но не накопится до критического состояния. Думайте о техническом долге как о финансовом долге. Они не просто так называются. Если есть долг — всегда есть проценты, которые надо платить.
н-н-н
н
Оригинал