Техническая задолженность: Как научиться не накапливать технический долг — отвечают эксперты – Почему технический долг — это хорошо / Voximplant corporate blog / Habr

Содержание

Технический долг — Википедия

Материал из Википедии — свободной энциклопедии

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


Сам по себе плохой код не всегда является техническим долгом, так как ущерб («проценты по долгу») появляются из-за необходимости изменения кода со временем[1].

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

Иногда термин используется неправильно, обозначая более не поддерживаемый код (англ. legacy code), который является некачественным и написанный кем-то другим[1].

Причины

Общие причины технического долга (может быть несколько)[источник не указан 74 дня]:

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

  • Сильное зацепление компонентов, когда декомпозиция системы выполнена неправильно или недостаточно гибко, чтобы адаптироваться к изменениям бизнес-потребностей.
  • Отсутствие тестов — ускоренная разработка и применение быстрых рискованных исправлений («костылей») для исправления ошибок.
  • Отсутствие документации, когда код создаётся без необходимой сопроводительной документации. Работа, необходимая для создания вспомогательной документации, — это также долг, который должен быть оплачен.
  • Отсутствие взаимодействия между командами, неэффективное управление знаниями в организации. Например, отсутствие наставничества в команде разработчиков.
  • Отложенный рефакторинг — чем дольше задерживается рефакторинг, и чем больше написано кода, использующего текущее состояние проекта, тем больше накапливается технический долг, который нужно «оплатить» при следующем рефакторинге.
  • Отсутствие опыта, когда разработчики просто не умеют проектировать программные системы или писать качественный код.


Последствия

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

Накопление технического долга является основной причиной для превышения сроков выполнения проектов. Трудно оценить, сколько именно работы необходимо выполнить для погашения долга. Неопределённое количество незавершённой работы добавляется в проект с каждым изменением. Сроки «горят», когда в проекте приходит понимание того, что есть ещё гораздо больше незавершённой работы (долга), чем времени для её завершения. Чтобы иметь предсказуемые графики выпуска, команда разработчиков должна ограничить количество выполняемой работы до такого, которое позволило бы минимизировать объёмы незавершённой ранее работы (долга).

Пока развивающаяся программа постоянно меняется, её сложность, отражая ухудшение структуры, увеличивается, пока не будет выполняться работа по поддержке оной[2].

— Меир Мэнни Леман, 1980

В то время как закон увеличения сложности Мэнни Лемана уже доказывал, что постоянное развитие программ увеличивает их сложность и ухудшает структуру, пока ведётся работа над ними, Уорд Каннингем впервые провёл сравнение между технической сложностью и долгом в отчёте за 1992 год:

Создание первого временного кода, — это как влезание в долги. Небольшой долг ускоряет разработку до тех пор, пока не будет своевременно оплачиваться в виде переписывания… Опасность возникает, когда долг не погашен. Каждая минута, потраченная на не-совсем-правильный код, учитывается в качестве процента по этому долгу. Целые инженерные организации могут быть привлечены к простою из-за долговой нагрузки неконсолидированной реализации, объектно-ориентированной или иной


[3].

— Каннингем, Уорд, 1992

В своей статье от 2004 года «Рефакторинг с использованием шаблонов» Джошуа Кериевски представляет в качестве аргумента сравнение расходов, потраченных на решение вопросов, связанных с архитектурной халатностью, которую он описывает как «долг структуры»[4].

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

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

См. также

Примечания

Ссылки

Литература

  • Adam Tornhill.

    Software Design X-Rays. — Pragmatic Bookshelf, 2018. — ISBN 9781680502725.

Технический долг разорит вас. Если вы позволите, конечно / Alconost corporate blog / Habr

Переведено компанией-локализатором Alconost.

Недавно проект, над которым я работал, наконец запустился. Ладно, перезапустился. Речь о небольшом простеньком приложении для айфона Postography, которое позволяет рассылать бумажные открытки с картинками и текстом с вашего айфона. Отличный и, вроде бы, несложный проект, правда? Приложение, на создание которого не должно было уйти много времени.

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




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

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

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

Это случается даже с передовыми технологическими компаниями. Возьмите хотя бы RIM. Помните, они выпустили планшет без почтового клиента? Помните, как они тихо топтались на месте целую вечность, пока iOS и Android ушли вперед, оставив BlackBerry в кильватере? Их неудачи не были обусловлены выбором дизайна или сознательными решениями руководства. Они случились из-за огромного технического долга, на избавление от которого у компании ушли годы.

Как и денежный, технический долг — вполне нормальное явление до тех пор, пока а) он не становится слишком большим, и б) вы знаете о нем все. Конечно, часто приходится прибегать к компромиссам между, скажем, масштабируемостью и скоростью разработки. Когда приближается дедлайн и/или заканчивается финансирование, а задача представляется огромной, бывает, что и быстрый хак оказывается правильным выбором. Можно понять и то, что все разработчики предпочитают использовать знакомые или интересные для изучения инструменты, а вовсе не идеальные для выполнения работы.


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

Так как же стартапам избежать этой незавидной судьбы?

Конечно же, критично важно нанимать правильных людей. Помогает также парное программирование c использованием модели «главный/ проверяющий», которую я особенно люблю. И мне всегда казалось, что технические оценки — хорошая идея: пускай несколько опытных специалистов потратят неделю на аудит вашего кода и архитектуры, один раз в самом начале разработки и еще раз где-то в середине процесса. Компания, на которую я работаю, проводила такое один или два раза, но, к сожалению, технические оценки пока не стали обычной практикой для отрасли.

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


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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

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

Все люди изначально стараются писать чистый код. Вряд ли найдётся программист, который намеренно плодит грязный код во вред проекту. Но тогда почему чистый код становится грязным?

Впервые метафору «технического долга», относительно грязного кода, предложил Говард Каннингэм.

Взяв кредит в банке, вы сможете ускорить какое-то приобретение. Однако вернуть вам предстоит не только основную сумму кредита, но и дополнительные проценты, которые набегут за то время, пока вы не погасите заём.

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

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

Причины появления технического долга