На данный момент концепция технического долга была широко распространена среди разработчиков. Напомню, что технический долг - это то, что происходит, когда разработчики, обычно находящиеся под давлением необходимости быстро закончить, срезают некоторые углы, делают несколько сокращений, взламывают что-то, чтобы заставить это работать. Другими словами, сокращайте время разработки за счет качества кода. Но лучший способ проиллюстрировать эту концепцию - это (слишком распространенный) пример.
Все мы были в этом: вы пытаетесь вовремя завершить проект. Но тут возникает острая деловая необходимость. Вы должны создать в своем приложении функцию, чтобы удовлетворить эту бизнес-потребность. Проблема, однако, в том, что рассматриваемая функция не совсем соответствует архитектуре, которую вы придумали. Правильнее было бы изменить архитектуру так, чтобы все подходило правильно и у вас был чистый код.
Увы, когда вы говорите это различным заинтересованным сторонам, у этих заинтересованных сторон есть подтекст. На это просто нет времени: обещания даны, конкурент дышит тебе в шею, нужно выпускать приложение. Итак, как делали многие разработчики с незапамятных времен, вы что-то собираете вместе, чтобы необходимая функция каким-то образом вписывалась в текущую архитектуру. Это не выглядит красиво, QA нужно потратить некоторое время на тестирование, чтобы убедиться, что все работает нормально, но вы выпускаете приложение. У вас вечеринка на корабле, и все счастливы.
То есть до тех пор, пока вам снова не придется иметь дело с этим фрагментом кода.
Конечно, вы думали, что после выпуска вашего приложения у вас будет время вернуться, избавиться от сделанного взлома, переделать архитектуру, реализовать ее и снова улучшить внешний вид вашего кода. Другими словами, избавьтесь от своего технического долга. Однако так уж случилось, что ваш конкурент раньше, чем вы предполагали, представил новую, действительно заманчивую функцию. Те же заинтересованные стороны приходят к вам и говорят, что приложение должно получить эту новую функцию как можно скорее.
Вы говорите им, что просто пытаетесь снова привести код в порядок. И вы слышите в ответ, что сейчас для этого просто нет времени, вы можете позаботиться об этом позже. Ввиду отставки, вы приступаете к реализации запрошенной функции. Часть этой новой функции частично совпадает с взломом, который вы сделали раньше. Не имея подходящего времени для переделки вашей архитектуры, вам придется писать код поверх упомянутого хака, код, который сам по себе тоже не так хорош. Фактически, он должен пройти через несколько петель и обручей, чтобы заставить его работать.
Что еще хуже, если бы у вас было время избавиться от технического долга раньше и вернуть свой код в надлежащую форму, время для реализации этой новой функции было бы короче. Новая функция будет реализована с меньшими усилиями, с меньшей вероятностью ошибок, QA не нужно будет проверять так много разных угловых случаев, весь процесс будет более эффективным. Но без этого рефакторинга вы просто соглашаетесь с тем, что вы должны написать патч поверх патча, и продолжаете это делать.
Вы получаете эту новую функцию прямо за дверь. На данный момент в организации есть соблазн сказать: «Эй, мы смогли выпустить вещи, не тратя так много времени на рефакторинг, поэтому очевидно, что это не является приоритетом». И поэтому ваш код начинает собирать все больше и больше исправлений, пока ситуация не станет по-настоящему неустойчивой и ваше программное обеспечение не станет неуправляемым.
Вот где возникает концепция технического интереса. Долг в реальной жизни не остается статичным: с течением времени он собирает проценты и растет. Точно так же технический интерес описывает концепцию, согласно которой технический долг тоже не остается прежним: чем дольше с ним не работают, тем больше он становится.
Технический интерес дает понять, что технический долг - это проблема, которая со временем будет только усугубляться.
Опять же, взяв страницу из реального долга, мы все знаем, что если ваши проценты слишком высоки, по прошествии достаточного времени ваш долг станет неуправляемым, и вам придется объявить о банкротстве. В разработке программного обеспечения накопление технического интереса приведет к все большему и большему техническому долгу, который в конечном итоге также станет неуправляемым.
Возвращаясь к нашему первоначальному примеру, эта организация время от времени пыталась найти время, чтобы избавиться от взломов и плохих дизайнов, накопившихся в приложении. Однако на тот момент накопленный технический интерес сделал технический долг слишком большим, поэтому были возможны только пунктуальные улучшения. Код состоял из патчей поверх патчей, с которыми мог работать только первоначальный разработчик.
Но, сказал разработчик, нашел лучшую возможность в другом месте. Новый разработчик берет на себя ответственность и проводит долгие дни (и ночи), пытаясь понять кодовую базу, но безуспешно. Итак, после нескольких жарких встреч делается неизбежный вывод: необходима всеобъемлющая перезапись, и много времени и ресурсов будет потрачено на написание совершенно нового кода. Не только это: мы говорим о новом коде, который должен точно имитировать поведение предыдущего кода, что само по себе является довольно сложной задачей. Таким образом, компании приходится тратить гораздо больше ресурсов, чем если бы она решала проблему раньше.
В этом и заключается идея технического интереса: добавить измерение времени к проблеме технического долга. Понятно, что компаниям, занимающимся разработкой программного обеспечения, иногда приходится делать трудный выбор и, возможно, не заниматься своим техническим долгом. Однако, принимая во внимание технический интерес, организация-разработчик может добавить фактор времени к вычислениям, которые она делает, чтобы определить, над чем работать дальше, какой рабочий элемент имеет наивысший приоритет, а что можно отложить.
Технический интерес может ясно показать всем заинтересованным сторонам, что в их интересах иметь дело с техническим долгом раньше, чем позже.
Я надеюсь, что эта концепция может привести к более разумным решениям в разработке программного обеспечения и, что еще лучше, к уменьшению технического долга. Иногда самая сложная часть решения проблемы - это сообщить о ней, и, возможно, идея технического интереса поможет лучше сообщить о проблеме технического долга и его накоплении. И, к счастью, более удачное кодирование!
