Техническая задолженность это: Технический долг — Википедия – Комментарии Кайла Брауна: Погашение технической задолженности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[4].

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

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

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

В программном обеспечении с открытым исходным кодом откладывание отправки локальных изменений в основной проект является техническим долгом^{[источник не указан 130 дней]}.

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

Комментарии Кайла Брауна: Погашение технической задолженности

Комментарии Кайла Брауна

Кайл Браун
Опубликовано 03.09.2012

Серия контента:

Этот контент является частью # из серии # статей: Комментарии Кайла Брауна

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Комментарии Кайла Брауна

Следите за выходом новых статей этой серии.

Создание технического капитала

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

Эта аналогия может показаться неожиданной, но на самом деле она хорошо известна уже давно; более 15 лет назад ее впервые представил Уорд Каннингем (Ward Cunningham), а затем в 2005 году развил Джошуа Кериевски (Joshua Kerievsky) (см. раздел Ресурсы).

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

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

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

1. Оцените свои долги

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

   Начните с просмотра проектной документации. Актуальна ли она? Охватывает ли она наиболее важные положения проекта? Затем следует расставить приоритеты по анализу кода, исследуя области, создающие наибольшее количество проблем. Какие участки кода труднее всего для изменения? Где обнаруживается наибольшее число ошибок? Какие части кода наиболее важны для бизнеса? Ответы на эти вопросы помогут вам установить очередность действий, необходимых для улучшения ситуации.

   Но ваша система состоит не только из кода и документации, и эти другие составляющие тоже могут вносить вклад в техническую задолженность. Например, рассмотрим управленческую задолженность. Не устарел ли применяемый вами уровень платформы, например IBM® WebSphere® Application Server? Тратят ли сотрудники время и средства на задачи, которые следовало бы автоматизировать? Выполняется ли динамический мониторинг для упреждающего обнаружения проблем, или вы тратите время на «посмертный» анализ после сбоев?

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

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

2. Остановите формирование новой задолженности

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

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

   • Включите действия по сокращению задолженности в пользовательские модели (user stories), применяемые в методе agile-разработки. Воздействуйте на представителей бизнеса, чтобы гарантировать включение в каждый цикл разработки некоторых из действий, идентифицированных на шаге 1. Сложность здесь состоит в совмещении действий по сокращению технической задолженности и действий по новой разработке, затрагивающих одну и ту же область кода. Предположим, например, что вы разрабатываете сайт электронной торговли и обнаруживаете, что источником большинства проблем является компонент подсчета стоимости покупок. Можно отложить новую разработку в этой области кода и сосредоточиться на устранении всей технической задолженности в данной области (рефакторинг кода, обновление документации и т.д.). В этой ситуации на время выполнения изменений в компоненте подсчета стоимости покупок новые разработки можно было бы сосредоточить в области добавления новых рекламных акций или изменения страниц о товарах.
   • Реализуйте бета-стратегию. Если ваша инфраструктура способна поддерживать два сайта (один рабочий, а второй – бета-сайт), во время рефакторинга основного кода можно продолжать новую разработку на бета-сайте. Такой подход хорош тем, что не тормозит новую разработку, однако он может привести к затратам на более сложную последующую интеграцию, когда изменения бета-сайта будут вноситься в основной сайт.
3. Выберите стратегию сокращения задолженности

   Если говорить о стратегиях сокращения задолженности, рассмотрите два различных способа расстановки приоритетов ваших «погашений»:

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

   Основная задача – сделать сокращение задолженности частью долгосрочной повседневной работы. Это не одноразовая акция; многие компании разочаровались в модных совсем недавно словечках типа рефакторинг (см. раздел Ресурсы), поскольку ожидали краткосрочных результатов от процесса, который на самом деле следует рассматривать как долгосрочное инвестирование. Неумолимая правда заключается в том, что вы всегда будете формировать новую задолженность; нужно гарантировать возможность ее погашения, а не разрешать ее накопление.

5. Отслеживайте и повторно оценивайте ход работ

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

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

Благодарности

Автор выражает благодарность Рэйчел Рейниц (Rachel Reinitz) за глубокие и полезные комментарии к данной статье.

Ресурсы для скачивания

Похожие темы

Подпишите меня на уведомления к комментариям

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

Программные системы склонны к накоплению мусора — внутренних недоработок, которые затрудняют дальнейшее изменение и расширение системы по сравнению с идеальным кодом. Технический долг — это метафора, придуманная Уордом Каннингемом. Она объясняет, как воспринимать этот мусор, по аналогии с финансовым кредитом. Дополнительные усилия, необходимые для добавления новых функций, — это проценты по кредиту.

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

Что меня больше всего привлекает в метафоре долга, так это ясное понимание расходов на его обслуживание или устранение. Я могу потратить пять дней на очистку модульной структуры, устранение мусора, метафорически расплатившись с «кредитором». Если я это сделаю для данной функции, то окажусь в проигрыше, потому что потрачу девять дней вместо шести. Но если появятся ещё две такие функции, то выгоднее всё-таки удалить мусор.

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

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

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

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

Метафора долга иногда используется для оправдания низкого качества кода. Аргумент состоит в том, что качественный код требует больше времени и усилий. Если срочно нужны новые функции, лучше принять на себя долг и разбираться с ним потом

Опасность здесь в том, что зачастую этот анализ ошибочен. Мусор очень быстро начинает вредить, замедляя внедрение новых функций. В итоге разработчики превышают кредитные лимиты и выпускают продукт позже, чем если бы сразу потратили время на обеспечение более высокого качества. Здесь метафора часто вводит людей в заблуждение, поскольку динамика технического долга на самом деле не соответствует динамике финансовых кредитов. Принятие на себя долга для ускорения выпуска продукта работает только в том случае, если вы остаётесь ниже линии design payoff в гипотезе об устойчивости архитектуры, а разработчики пересекают её уже через несколько недель, а не месяцев.

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

Насколько я могу судить, Уорд впервые представил эту концепцию в отчёте для OOPSLA 1992. Она также обсуждалось в вики.

Есть видеозапись, где Уорд Каннингем обсуждает придуманную им метафору.

Дэйв Николетт расширяет взгляд Уорда на технический долг, приводя прекрасный пример того, что я называю разумным преднамеренным долгом.

Несколько читателей предложили другие годные метафоры. Дэвид Панарити назвал некачественную разработку дефицитом программирования. Судя по всему, он начал использовать этот термин несколько лет назад, когда он соответствовал политике правительства; полагаю, теперь это снова актуально.

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

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

Аарон Эриксон говорил о финансировании Enron.

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

Эрик Дитрих обсуждает человеческие потери из-за технического долга: сражения в командах, деградация навыков и выгорание.

Первоначально этот пост был опубликован 1 октября 2003 года. Я полностью переписал его в апреле 2019 года.

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

Будь вы простым программистом, матерым лидом, архитектором или даже ПМ-ом, вы наверняка в своей нелегкой работе сталкивались с проблемой выбора при добавлении в систему новой возможности. Одно решение гораздо проще реализовать в сжатые сроки и успеть к очередному очень важному релизу, однако оно будет более затратное в сопровождении, менее расширяемое или менее надежное. Другое решение может не обладать всеми этими недостатками, однако обладать другим, в некоторых случаях более важным недостатком – на его реализацию потребуется значительно больше времени.

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

Не удивительно, что многие простые программисты, матерые лиды и архитекторы, а иногда даже ПМ-ы, которые понимают, что им самим придется расхлебывать проблемы «близоруких» решений, с таким подходом не согласны. И совершенно не удивительно, что с подобной проблемой сталкивались и другие известные и не очень люди, которые придумали типовые «паттерны», описывающие подобную ситуацию. Одним из таких паттернов, является метафора технического долга, впервые описанная Вардом Каннингемом (Ward Cunningham) (*) без малого двадцать лет назад.

Технический долг в классическом понимании

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

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

У этой метафоры есть одна очень важная особенность: когда речь идет о неоптимальном решении, речь идет об использовании .NET Remoting вместо WCF, использовании Sybase, вместо SQL Server, использовании DataSet-ов вместо Entity Framework (**), однако никто не говорит о «забивании костылей», грязных хаках, плохом коде, связной архитектуре и тому подобном. Как раз наоборот, неоптимальность стратегического решения не означает, что к нему нужно относится спустя рукава, распространить влияние этого решения на всю систему или просто напросто г#$нокодить. Как раз, наоборот, в большинстве случаев это означает, что это решение должно быть спрятано в виде детали реализации, одного или по крайней мере, как можно меньшего числа модулей, чтобы его можно было изменить позднее.

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

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

Грязный код, как источник технического долга

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

Во время кодирования, как и во время принятия любых других решений, разработчик должен рассматривать краткосрочные и долгосрочные выгоды. Давайте рассмотрим юнит-тесты. Если спросить адепта TDD о необходимости юнит-тестов, то он скажет: «г@#но-вопрос, юнит-тесты должны быть для каждого класса, модуля или функции, и, конечно же, они должны писаться до написания кода». Однако если послушать Кента Бека (****), автора TDD, то его отношение к юнит-тестам более прагматичное. Принимая решение об использовании TDD или серьезном покрытии кода юнит-тестами точно так же нужно принимать во внимание краткосрочные и долгосрочные выгоды. Безусловно, юнит-тесты очень полезны, но они полезны, прежде всего, в долгосрочной перспективе, а что если вы осознаете, что существует высокая вероятность того, что этих долгосрочных перспектив не будет вовсе? Вы можете разрабатывать прототип или что-то типа proof of concepts, и пытаетесь выяснить, будет ли вообще это решение работать или нет. С аналогичной ситуацией неэкономичности юнит тестов можно столкнуться во многих реальных приложениях, когда при добавлении новой возможности стоимость написания юнит-теста может в несколько раз превышать стоимость самой реализации.

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

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

Выводы

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

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

——————————————-

(*) Вард Каннингем – это известный дядька, оказавший невероятный вклад в развитие компьютерного сообщества; он «папа» wiki, а также один из авторов «паттернов» и «экстремального программирования». Информацию по поводу первого вклада можно найти в Википедии, а по поводу второго – в статье «Шаблоны проектирования. История успеха».

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

(***) Некоторые авторы, включая Боба Мартина не считают, грязный код (messy code) техническим долгом, однако подобный код увеличивает стоимость добавления новой возможности, так что мне кажется, что его тоже можно рассматривать, как один из видов технического долга.

(****) Здесь речь идет о подкасте Software Engineering Radio Episode 167: The History of JUnit and the Future of Testing with Kent Beck, в котором Кент Бек как раз и высказал эту заветную мысль.

Технический долг? О чем вы вообще говорите?

Часто можно услышать, что в проекте большой технический долг. А что это? Насколько он большой? В чем измеряется? Разобрались в статье.

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

Если вы попытаетесь поискать ответ на этот вопрос в интернетах, то обнаружите чушь вроде этой: «Технический долг – это долг, который накапливается из-за принятия неидеальных технических решений, и должен погашаться через рефакторинг.» Неидеальных?! Кто видел идеальные решения хоть где-либо? И как оценить расхождение с идеальным решением? Нет! Это все словоблудие, беспредметный треп ни о чем!

В ТРИЗ (теории решения изобретательских задач) существует понятие идеального объекта: Идеальный объект – это объект, которого нет, но функция которого выполняется. Если взять это определение идеального, то весь код, что мы пишем – сплошной технический долг. Но в чем его измерять? В строках? В выражениях? В сложности синтаксического дерева или в количестве вершин и граней графа вычислений? Это сложный и запутанный путь в никуда!

Так что же такое технический долг? (дубль два)

Технический долг – это осознанное и задокументированное решение не делать что-то сейчас. Допустим, есть компания, и у нее есть множество аккаунтов сотрудников. Пока все хорошо и просто. Но! Сотрудник ведь может быть в нескольких компаниях! Как ему между ними переключаться? Или стоит объединить данные из нескольких компаний на одном единственном рабочем экране?

Отвлечемся немного от этой задачи. Действительно ли мы сейчас должны принимать какое-либо решение о реализации? Или мы можем инвестировать время и другие ресурсы во что-то более важное? Каким вообще образом все эти переключения или агрегация данных из нескольких компаний могут принести нашей собственной компании прибыль? Это ли то, что мы продаем? Интересно ли нам этим заниматься? Ответ: Нет! Это не создает ценности, но лишь улучшает опыт сотрудников в достаточно редких случаях. При этом, наш клиент — компания, а не сотрудник. Нам важно, чтобы был счастлив тот, кто платит деньги, а не какой-то случайный человек. В противном случае мы ничего не добьемся в попытках всем угодить. Так и запишем:

Только одна компания на аккаунт!
Tags: account, auth. Аккаунты находятся под одной конкретной компанией и не шарятся между компаниями. Если пользователь желает работать в нескольких компаниях, ему понадобится завести по аккаунту для каждой из них. Мы понимаем неудобства некоторых пользователей и принимаем их, поскольку данный элемент пользовательского опыта является вторичным и значительно выходит за пределы нашего ценностного предложения.

Этому все еще нельзя присвоить численную оценку, да и не нужно. Быть может, мы никогда не дойдем до необходимости погашать этот технический долг. Мы задокументировали это решение и время от времени вспоминаем о нем, мы даже можем дописывать к нему пожелания клиентов о реализации такой возможности, однако это вовсе не обязывает нас его «погашать». Мы просто помним о принятом нами решении, помним его аргументацию и дописываем в него пожелания пользователей или связанные с ним НЕ-технические проблемы, вроде: “Компания X отказалась от подписки на наш сервис по причине отсутствия данной функциональности. Контракт мог бы приносить нам ~$20000 в год”. Вот здесь и появляются какие-то внятные числа. А $20000 – это много или мало? Вам решать! Принимать такие решения стоит исходя из текущего вектора развития компании и предполагаемого ROI (который легко может оказаться ошибкой).

Итог

Теперь многим, кто ошибался насчет технического долга, должны стать понятны следующие моменты:

1. В большинстве случаев “технический долг” подразумевает не технический долг, а низкое качество кода и отсутствие культуры у разработчиков.

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

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

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

P.S. Больше моих публикаций об ИТ, разработке и программировании вы сможете найти в моем телеграм-канале IT Rampage.

Два вида технического долга и их погашение

Перевод статьи Кайла Галбрайта «Two Kinds of Tech Debt and How to Pay It Down».

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

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

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

Краткий пример технического долга

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

С техническим долгом то же самое, только вместо денег речь идет о кодовой базе.

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

Кредиторская задолженность — анализ, способы погашения.

Экономическая деятельность организации — сложный процесс. Расчёты организации по своим обязательствам не производятся мгновенно. Так возникает кредиторская задолженность.

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

Что включает кредиторская задолженность

Долговые обязательства организации неоднородны. Это могут быть:

1. Долг по расчётам с контрагентами. Его ещё называют коммерческим кредитом. Сюда входят как обязательства за полученный товар, произведённые работы и оказанные услуги, так и авансирование по сделкам.
2. Долги по заработной плате. Предприятие обязано регулярно платить своим работникам за проделанную теми работу.
3. Обязательства перед внебюджетными фондами. На организации возложены обязанности по уплате взносов в различные фонды, например в ФСЗН.
4. Налоговые обязательства. Деятельность любой организации облагается государственными налогами.
5. Иная задолженность. Сюда относятся, например, обязательства, наступившие вследствие причинения вреда.

Словом, совокупность всех долгов коммерческой организации — это и есть кредиторская задолженность.

Виды кредиторской задолженности

Для лучшего понимания этого экономического явления задолженность классифицируют по различным основаниям.

По срокам возврата ее разделяют на такие категории:

• Текущая. Срок исполнения такого типа обязательств составляет до 90 дней. Такие долги относятся к техническим и погашаются в рабочем порядке.
• Краткосрочная. Срок погашения такой задолженности — не более 12 месяцев. Такие обязательства должны тщательно контролироваться со стороны руководства организации, так как есть риск, что кредиторы перейдут к активным действиям.
• Долгосрочная — до трех лет. Возникает, если у организации появляются серьёзные проблемы с платёжным балансом. Её рост может привести к банкротству компании в среднесрочной перспективе.
• Задолженность к списанию. Она не была исполнена в течение трех лет с момента возникновения, и кредитор не обратился за её принудительным взысканием. В таком случае бухгалтерия списывает её с баланса в рабочем порядке.

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

• оплата труда наёмных работников;
• расчёты с государственным бюджетом и внебюджетными фондами.

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

Также такие обязательства делятся на текущие и просроченные.

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

На второй разновидности следует остановиться подробнее.

Просроченная кредиторская задолженность

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

Среди причин возникновения просроченной кредиторской задолженности можно выделить следующие:

1. Отсутствие финансов. Простая нехватка оборотных средств может привести к плачевным последствиям. Кратковременная задолженность постепенно перерастает в просроченную.
2. Непрофессионализм бухгалтеров. Если ведением баланса предприятия занимаются специалисты с низкой квалификацией, то может быть неверно подсчитана налоговая база. Такая ошибка приведёт к недоплате в государственный бюджет.
3. Низкая исполнительная дисциплина работников. Не каждый специалист старается разобраться в сути положений договоров, находящихся у него в работе. В итоге работники забывают о необходимости рассчитаться по долгам, что ведёт к появлению просрочек и штрафным санкциям.
4. Нежелание платить по долгам. Недобросовестные руководители организаций нередко перестают исполнять обязательства, мотивируя это тяжёлым экономическим положением. В реальности же они стараются извлечь максимальную выгоду, используя оборотные средства в других проектах.

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

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

Обратить внимание следует на долги перед бюджетом и внебюджетными фондами. Контрагенты не будут обращаться в суд, если есть реальная возможность получить долг добровольно.

Постоянное наличие просроченной задолженности сигнализирует о том, что предприятие находится на пути к банкротству.

Анализ кредиторской задолженности

Основную работу по систематизации обязательств предприятия проводят бухгалтеры. Они тщательно учитывают все активы и пассивы, чтобы иметь объективную информацию о деятельности юридического лица.

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

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

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

Способы погашения кредиторской задолженности

Эффективная борьба с данным экономическим явлением осуществляется несколькими способами:

1. Исполнение обязательства. Юридическое лицо выполняет то, что от него требуется законодательством или условиями договора. Это может быть поставка товара, в счёт которой был получен аванс, выполнение работы и так далее.
2. Перечисление денежных средств. Любая вещь в системе рыночных отношений имеет свою стоимость. Поэтому погашение задолженности в форме платежа является распространённой формой. Другое дело, что такое исполнение не всегда возможно из-за недостатка средств.
3. Новация. Возможно, контрагент согласится изменить условия договора, чтобы должник мог исполнить обязательство доступным ему способом. Например, через выполнение какой-либо работы или поставку продукции. Новация оформляется в форме отдельного договора.
4. Отступное. Если организация находится в сложном финансовом положении, то стоит задуматься о передаче должнику части основного фонда: какого-либо здания, части производственного оборудования, транспорта и так далее. Контрагенты соглашаются на такие формы исполнения обязательств, когда других вариантов не остаётся.
5. Списание. Обязательство списывается с баланса предприятия. Это происходит по следующим основаниям:
   • Истечение срока исковой давности. Например, за оказанные услуги организация должна выставить счёт и представить акт, подписанный обеими сторонами договора. В ходе подписания этого документа возникли разногласия, которые урегулировались путём переговоров. В итоге факт оказания услуг так и не был оформлен должным образом. Через три года истекает срок исковой давности, и кредитор уже не сможет предъявить свои требования.
   • Невозможность исполнения обязательства. Это означает, что существует физическое препятствие (например, результат стихийного бедствия) или юридический запрет на выполнение какого-либо действия.
   • Ликвидация организации. Предприятие завершает свою деятельность, требуется подвести итоговый баланс. Очевидно, что количество активов не увеличится. Поэтому организация либо рассчитывается по обязательствам, либо списывает их.

Кредиторская задолженность — важная экономическая характеристика. Размеры долговых обязательств должны соответствовать активам организации. Достигнуть этого можно только качественной работой всех сотрудников компании.