Являются ли ошибки частью технического долга?

Наш Scrum Master продолжает называть ошибки техническим долгом. Прав ли он, ошибки считаются техническим долгом в мире Agile?

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

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

Ошибка - это не то, что мы выбираем в нашем коде, так что де-факто это не технический долг.

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

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

Да.

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

Источник: Википедия

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

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

Прочитав ответ BЈовић , я вижу, что это может быть не так просто, как я думал.

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

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

• Наконец, при создании модели технического долга ABCDE-T я включил ошибки в качестве одного из шести факторов, но они рассматриваются по-разному. Основное внимание уделяется не самим ошибкам, а способам их сбора, определения приоритетов и устранения. Сами ошибки появляются как результат технического долга (как в предыдущем примере), но никогда не появляются как фактор технического долга.

При этом, я все еще склонен отвечать, что ошибки - многие ошибки - являются частью технического долга.

Первый аргумент:

Читая цитату Джеффа Этвуда, большинство ошибок можно квалифицировать как:

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

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

Второй аргумент:

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

• Либо приходится иметь дело с этими ошибками, прежде чем создавать новые функции (пункт 5 Joel Test: исправляете ли вы ошибки перед написанием нового кода?)

• Или оставляйте ошибки, сохраняя / увеличивая таким образом технический долг.

Джефф Этвуд в своей статье « Погасить свой технический долг» дает довольно хороший ответ о том, что такое технический долг:

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

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

Однако, когда исправление ошибки обходится слишком дорого или заставляет вас обходить ее (и вводить еще больше технического долга), тогда это становится частью технического долга.

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

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

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

Дебаты по техническим долгам с Уордом Каннингемом и Каперс Джонс

Еще одна статья, которую стоит прочитать - Мартина Фаулера

Мартин Фаулер о техническом долге

В статье Мартина вы найдете ссылку на оригинальное упоминание технического долга Уорда Каннингема из OOPSLA92:

Система управления портфелем WyCash

Цитата из вышеприведенной статьи:

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

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

Строго говоря, ответ на ваш вопрос - нет.

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

Если ваш Scrum Master заявляет «как теория», что ошибки являются результатом технического долга, он срезает углы. Если он говорит об определенных ошибках, которые продолжают появляться, он вполне может быть прав - мы не можем видеть качество кода отсюда ;-)

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

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

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

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

То есть, вы говорите, что известные (или неизвестные) ошибки - технический долг ... или нет ... на самом деле это просто вопрос определений. И поскольку нет авторитетного определения ¹ «технического долга», вся дискуссия бессмысленна.

Как писал Льюис Кэрролл:

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

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

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