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

44

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

agile technical-debt

— user86834
источник

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

— Брайан Оукли

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

— BЈовић

4

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

— user86834

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

— Брайан Оукли

1

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

— Луис Перес

35

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

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

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

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

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

— Murph
источник

1

+1. Я думаю, что ответ BЈови is в значительной степени правильный, но ваш ответ действительно бьет по голове. (Я немного смущен тем, что вы используете термин де-факто . Я не думаю, что вы можете сказать, что де-юре ошибка - это технический долг?)

— ruakh

Использование языка - это очень весело ... попробуйте это: en.wikipedia.org/wiki/De_facto - прочитайте его как «для всех намерений и целей», что достаточно близко к моим намерениям

— Murph

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

— gphilip

де юре дю юре. Завтра де факто. QED.

— Радар Боб

1

в соответствии с Техническим квадрантом долга Мартином Фаулером вы можете идентифицировать ошибки и плохой код как «безрассудный непреднамеренный» долг: martinfowler.com/bliki/TechnicalDebtQuadrant.html . Я думаю, дело в том, что если вы отметите некоторые чувствительные ошибки как долги, то вы сможете понять, сколько они вам стоят и нужно ли вам их устранять. Например, если у вас есть неаккуратный письменный модуль, который меняется только один раз в год, и для его переписывания потребуются недели - вы, вероятно, должны оставить его как есть, потому что процентные платежи по этому долгу очень и очень малы

— shershen

20

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Арсений Мурзенко
источник

1

Лично я не считаю дефекты техническим долгом, хотя аргумент, представленный в этом ответе, является обоснованным, но а) на самом деле не имеет значения, как мы определяем технический долг ИМО, и б) это такой хорошо написанный ответ: Я все равно голосую за это. +1!

— Брайан Оукли

13

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

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

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

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

— BЈовић
источник

1

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

— Марьян Венема

@MarjanVenema Хороший вопрос. Я не думал об этом.

— BЈовић

Обратите внимание, что эта цитата не от Джеффа Этвуда, она взята из поста Мартина Фаулера . Джефф цитирует это также в своем блоге.

— Уууу

6

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

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

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

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

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

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

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

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

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

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

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

— Абстрактный класс
источник

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

— bhspencer

2

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

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

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

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

— Ян Догген
источник

2

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

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

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

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

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

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

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

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

— Стивен С
источник