В разработке программного обеспечения существует понятие «технический долг». Это когда вы делаете что-то, что, как вы знаете, неправильно, но все еще делаете это. Как говорил какой-то мем: «Мы делаем что-то не потому, что это легко, а потому, что это казалось легким». Так что что-то казалось легким, потребовалось (надеюсь) меньше времени, чтобы реализовать это, но теперь это вызывает проблемы. Это технический долг.

Некоторые инструменты отслеживания проектов рассматривают результаты работы инструментов статического анализа (таких как pmd, findbugs) как технический долг. Метод слишком длинный, повторяющийся строковый литерал, не усложняйте сравнение и т. Д.… Такие выводы могут быть полезны, хотя при наличии достаточного опыта такие проверки больше всего раздражают. И очевидно, что до получения реального технического долга еще далеко. Может быть хороший код с множеством предупреждений от инструментов статического анализа, и может быть код на грани технического банкротства, который, согласно тому же инструменту, работает невероятно.

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

Хорошо, но тогда что такое технический долг?

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

Очевидно, что это можно измерить, хотя и относительно друг друга: у проекта «Аврора» больше технического долга, чем у «Браво», но оба их долга вместе взятые намного меньше, чем у «Чарли». В этом отношении технический долг похож на чувства и эмоции, которые могут испытывать люди: трудно сказать в абсолютных единицах, насколько вам нравится тот или иной кофе (или чай), но нетрудно дать приблизительную оценку и сравнить ее с другой кофе (или чай).

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

Это также то, что накапливается. Срезайте путь туда и сюда - хорошо. Еще несколько угловых сокращений - это не выглядит хорошо, но программа делает то, что должна делать. Выполняя следующее изменение, вы можете обнаружить, что добавляете обходной путь для обхода ярлыка, который вы использовали некоторое время назад. И чтобы заставить его работать, вам понадобится еще одна небольшая деталь, «отключенная» при развертывании службы ... Медленно, но верно, вам придется тратить все больше и больше времени на решение вопросов, которые очень мало связаны с реальным изменением, которое вы пытаетесь делать в системе.

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

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

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

Технический интерес

Продолжая финансовую метафору, если есть долг, должен быть интерес: время и усилия, которые тратятся на борьбу с осложнениями, связанными с запуском и изменением кода, полного сокращений.

Изменение за изменением, оно складывается, следуя закону сложных процентов, добавляя все больше и больше работы. Сначала больше кода. Дальше более оперативная работа: если включен флаг «enable_backoff» - отключите флаг «экспериментальный_вылет», если измените логику в сервисе отслеживания - сначала обязательно обновите функции SQL в базе данных и т. Д.…

Система становится хрупкой, требуя больше времени для устранения сбоев, оставляя еще меньше времени на регулярную разработку. Для решения неотложных проблем необходимы более быстрые исправления, которые усложняют работу. Появляется особый класс «героев» - люди, которые еженедельно отважно тушат пожары сверхурочно и спасают проект от полной катастрофы (или значительно уменьшают радиус взрыва)…

В долгах нет ничего плохого

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

Нет (надеюсь) технического агентства по сбору платежей, которое бы постоянно звонило и просило перейти и провести рефакторинг сервисов, чтобы не иметь общей базы данных. Или отказаться от протокола REST и использовать подходящий инструмент для RPC, чтобы перестать писать клиентов снова и снова. Или перенесите какую-нибудь логику в общее место (хотя будьте осторожны с этим). Фактически, в большинстве случаев менеджмент был бы счастлив, если бы технический долг не затрагивался. Обидно, что на нажатие кнопки уходит две недели, но где гарантии, что было бы лучше, если бы мы потратили эти две недели на погашение технического долга? Конечно, мы должны выплатить проценты сегодня, но, может быть, нам больше не придется прикасаться к этим частям приложения или мы будем переписывать весь модуль?

В некоторых случаях это не так безумно, как кажется. Если процентная ставка составляет 10%, но вы можете получить доход в размере 30%, имеет смысл иметь как можно больше долга. Хорошим примером этого является прототип, который отбрасывают, когда основные рабочие процессы пользователя и дизайн системы более или менее установлены. Или, когда успех продукта превосходит запланированную мощность системы, может иметь смысл держать систему на плаву с помощью быстрых исправлений, пока новая система для работы в более крупном масштабе находится в разработке.

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

Ключ в балансе.

Но как узнать, правильный ли баланс? Нет, это невозможно. Итак, две стратегии: либо попытаться угадать, когда пришло время выплатить часть долга (по сути, азартные игры), либо сделать это методично.

Представьте, что помимо технического долга на сумму долга будет взиматься технический налог. Каждый год инженерная группа должна подготовить форму, в которой перечислены все налогооблагаемые события: сколько сокращений было сделано, сколько часов операционных накладных расходов возникло из-за этих сокращений и т. Д. Будет ли это работать по-другому в разработке программного обеспечения?