Чи є помилки частиною технічної заборгованості?

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

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

Ми вирішили приймати рішення архітектури, проектування чи реалізації, які, як ми очікуємо, викличуть у нас проблеми пізніше, щоб швидше досягти конкретних цілей.

Помилка - це не те, що ми обираємо у своєму коді - тому фактично це не технічна заборгованість.

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

Як постскрипт - я не згоден із твердженням, що його врахування того, що технічна заборгованість призведе до помилок і сама по собі, тому що дозволяє зробити багато припущень щодо природи зробленого вибору. Наприклад, ви можете мати добре написаний, добре структурований тестовий код, який все ще робить, скажімо, архітектурні компроміси для ранньої доставки. Так само ви можете обрати не автоматизувати процеси розгортання, що не призведе до помилок, але, ймовірно, призведе до великого стресу та болю. Звичайно, якщо заборгованість полягає в тому, що ви написали код, який не є ТВОРОДИМ (або будь-яким іншим), то так ... але це далеко не завжди так.

Так.

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

Джерело: Вікіпедія

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

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

Прочитавши відповідь Бйовича , я бачу, що це може бути не так просто, як я думав.

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

• Інший приклад, «Думки Крістофера про технічний борг» кваліфікують помилки як результат технічної заборгованості, а не її частини. Як було сказано, на багато перерахованих результатів, як-от "вартість впровадження нової функції", впливає кількість помилок.

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

На цю тему я все ще схильний відповідати, що помилки - усі помилки - є частиною технічної заборгованості.

Перший аргумент:

Читаючи цитату Джеффа Етвуда, більшість помилок кваліфікуються як:

додаткові зусилля, які ми маємо докласти в майбутньому розвитку через швидкий і брудний вибір дизайну

У бізнес-програмах майже кожен помилку виходить із-за швидкого та брудного вибору дизайну чи поганих практик (це буде відсутність тестування, використання технологій, які розробники не знають достатньо, відсутність спілкування, нерозуміння домену, і т. д.) Це означає, що "переробляючи швидкий та брудний дизайн на кращий дизайн" та адаптуючи кращі практики, бізнес міг би вирішити більшість своїх помилок.

Другий аргумент:

Якщо ми проводимо паралель між звичайною заборгованістю компанії, яку важливо враховувати, коли компанія продається іншій, і технічною заборгованістю, що не менш важливо враховувати, коли проект продається іншій компанії або дається іншій команді ми можемо легко побачити, що помилки є частиною технічної заборгованості, оскільки нова команда:

• Чи потрібно мати справу з цими помилками, перш ніж створювати нові функції (пункт 5 тесту Джоеля: чи виправляєте помилки перед тим, як писати новий код?)

• Або зберігайте помилки, зберігаючи / збільшуючи таким чином технічну заборгованість.

Джефф Етвуд у своїй статті " Сплата свого технічного боргу" дає дуже гарну відповідь щодо того, що таке технічний борг:

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

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

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

Помилка - це не технічна заборгованість. Технічна заборгованість скорочується на якість, а не на її відсутність. Програмне забезпечення в першу чергу не повинно надходити з помилками. Ви знаєте, це все робоче програмне забезпечення над всеосяжною документацією.

Найбільшими правопорушниками технічної заборгованості є "тимчасові виправлення помилок", ви знаєте тих, кого ви ввели, щоб пройти тест і отримати історію прийнято. Ті, які ви пообіцяли собі, пізніше відремонтуєте, але потім цього не зробите. У міру накопичення цих тимчасових виправлень, виправлень та інших речей код стає непотрібним захаращеним, його важко оновити та перевірити, і взагалі це кошмар, але він все одно робить свою роботу.

Для підтримки цієї думки я пішов прямо до джерела, Уорд Каннінгем. Зважаючи на це, Уорд зробив хороше співбесіду ще раз з Каперсом Джонсом, його варто подивитися.

Дебати щодо технічної заборгованості, з Уордом Каннінгем та Каперсом Джонсом

Ще одна стаття, яку варто прочитати, - Мартін Фаулер

Мартін Фаулер з технічного боргу

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

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

Цитата з наведеної статті:

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

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

Строго кажучи, відповідь на ваше запитання - Ні.

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

Якщо ваш майстер Scrum заявляє «як теорію», що помилки є результатом технічної заборгованості, він вирізає кути. Якщо він говорить це про конкретні помилки, які повторно з’являються, він цілком може бути правильним - тут ми не можемо побачити якість коду ;-)

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

На мою думку, це насправді не має значення, ти кажеш, що помилки є частиною технічної заборгованості ... чи ні.

Очевидний факт полягає в тому, що наявні помилки представляють додаткову роботу, яку, можливо, потрібно буде виконати в майбутньому, або виправити їх, або обійти їх.

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

Тож, чи говорите ви, що відомі (чи невідомі) помилки - це технічна заборгованість ... чи ні ... насправді лише питання визначення. А оскільки немає авторитетного визначення ¹ "технічного боргу", вся дискусія є безглуздою.

Як писав Льюїс Керролл:

"Коли я вживаю слово, - сказав Христим Дампті, досить зневажливим тоном, - це означає саме те, що я обираю, щоб означати - ні більше, ні менше". .

Саме так працює природна мова. Слова означають те, що люди думають, що означають. Визначення словника і так далі просто документує спосіб використання слів, і вони не обов'язково є точною документацією. Якщо ваш майстер Scrum хоче згадати відомі помилки як технічну заборгованість, хто скаже, що він "помиляється"?

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