Что такое технический долг и можно ли его избежать?

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

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

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

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

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

В какой-то момент этот компонент с открытым исходным кодом, возможно, потребуется заменить (или разветвить). Это будет стоить времени и денег. В далеком будущем вам нужно будет удалить весь код Backbone из своего проекта и прекратить поддержку устаревших пользователей. Опять же время и деньги. Тот патч, который вы сделали, чтобы уложиться в срок? Что ж, в конечном итоге это будет отменено и потребует более постоянного исправления. Время и деньги. И у вас появятся новые члены вашей команды, которые будут возвращаться к старому коду, чтобы сделать все это, и им нужно будет понимать код и логику предыдущих разработчиков. Время. Деньги.

Ты понял.

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

Можете ли вы избежать технического долга?

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

Давайте посмотрим на некоторые из примеров, которые мы обсуждали выше, и посмотрим, есть ли способ избежать, минимизировать или покрыть затраты.

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

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

Это когда вам нужно подумать о взятии ссуды и техническом долге.

У вас действительно есть три варианта:

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

Часто выбирают третий вариант. Это технический долг. И в этом нет ничего плохого. Потому что вы приняли решение сделать это .

Выплата целевого займа

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

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

Принимая во внимание техническую задолженность по устаревшему кодексу

Другой распространенный вид технического долга - это тот, который WordPress накапливает прямо сейчас. WordPress может работать на PHP 5.x. Однако последнее обновление сообщает пользователям, что это должен быть как минимум PHP 5.6. К концу 2019 года для WP Core потребуется PHP 7.x. Однако, повышая требования, необходимо обновить много старого кода. Потому что в плагинах, темах и самом ядре все еще есть код PHP 5.x.

Не говоря уже о новом редакторе блоков. Он написан на JavaScript. Реагируйте, в частности. Это не что иное, как PHP. Фактически, большая часть ядра WordPress постепенно переписывается на JavaScript. Но весь этот JS тоже должен дополнять и ладить с PHP. Освоение новых технологий - это здорово, и необходимо принятие новых требований к управлению версиями. Но при этом вы платите проценты по неизбежному техническому долгу, который возникает у вас из-за того, что это программное обеспечение существует уже какое-то время.

Выплата долга унаследованного кода

Это довольно сложно, потому что это не лучший способ сделать это. Вы можете выбрать ядерный вариант и полностью переписать с нуля на новом языке / фреймворке / версии (посмотрите, что мы делали между Divi 2 и Divi 3.0, переходя от Backbone.js к React). Однако это все еще не решает полностью проблему долга, поскольку у вас все еще есть люди, использующие старую библиотеку. В какой-то момент вам придется отказаться от поддержки устаревшей кодовой базы. Что-то вроде выплаты ссуды. Пока вам не придется вынимать следующий.

Если это не вариант (или лучшая идея для вас), вы можете убедиться, что не полагаетесь на особенности языка или версии. Front-end разработчикам приходится сталкиваться с этим все время, так как некоторые браузеры быстро поддерживают новые функции, в то время как другие (Microsoft Edge / IE, кашель-кашель) могут никогда не принять их. Вы можете подготовить свои проекты к будущему, придерживаясь основ, что, в свою очередь, приведет к меньшему количеству изменений, которые необходимо учитывать при обновлении или рефакторинге, чем в противном случае.

Рассмотрение нескольких разработчиков с течением времени

Это своего рода технический долг, который большие команды склонны накапливать со временем хуже, чем небольшие команды разработчиков. Хотя об этом нужно беспокоиться даже маленьким. Видите ли, каждый инженер-программист пишет код по-своему. Очень редко у вас будет два разработчика, которые решают одну и ту же проблему с одним и тем же кодом. Они могут выполнять ту же функцию, и конечный результат может быть таким же, но код будет написан голосом автора (точно так же, как вы можете сказать, кто писал здесь сообщения, например, как Джейсон, Натан, Донжете и У всех разные стили). Код ничем не отличается.

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

Выплата технического долга старых разработчиков

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

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

Кроме того, убедитесь, что каждый разработчик в вашей команде придерживается руководства по стилю или набора стандартов. В WordPress Core есть набор стандартов кодирования, которые будут поддерживать плагины, темы и основные элементы встроенными, чтобы у кого-то, кто придет позже, не возникнет проблем с ним. У Airbnb есть руководство по стилю для React, которое было принято в качестве неофициального отраслевого стандарта. Даже внутренние руководства по стилю и стандарты не дают вашим разработчикам зайти слишком далеко в одиночку, потому что такие коммиты не будут объединены, пока они не закончатся.

Заключение

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

Как вы справляетесь с технической задолженностью в своих проектах и ​​командах разработчиков?

Статья из избранного изображения Андрея Суслова / shutterstock.com