Czy błędy są częścią długu technicznego?

44

Nasz Scrum Master wciąż odnosi się do błędów jako długu technicznego. Czy ma rację, czy błędy w świecie Agile są uważane za zadłużenie techniczne?

użytkownik86834
źródło
Dlaczego ważne jest, aby zdecydować, czy są to dług techniczny, czy nie? Czy wpłynie to na sposób reprezentowania błędów na tablicy scrumowej, czy wpłynie na sposób ich usunięcia?
Bryan Oakley,
@BryanOakley Niektóre błędy mogą blokować Cię w taki sposób, że zmusza Cię do obejścia ich, powodując jeszcze większy techniczny dług. Te błędy mogą być zbyt drogie do naprawienia
2013
4
@BryanOkley - Zawsze uważałem, że dług techniczny to projekt lub refaktoryzacja, które były potrzebne do poprawy wdrożenia, ale obecnie nie są możliwe z powodu ograniczeń czasowych / budżetowych. Myślę, że ważne jest stosowanie właściwej terminologii. Mogę się mylić lub on może się mylić, dlatego zadałem pytanie.
user86834,
Rozumiem, że. Dlaczego tak ważne jest nazywanie ich długiem technicznym? Czy mówisz, że jeśli sklasyfikujesz je jako „dług techniczny”, potraktujesz te błędy inaczej niż inne błędy?
Bryan Oakley,
1
Możesz mieć ogromną ilość wsparcia technicznego i nie mieć ani jednego błędu. Dział techniczny jest przeciwieństwem dobrze napisanego i dobrze zaprojektowanego kodu. Dobrze napisany kod jest łatwy w utrzymaniu, testowaniu i dodawaniu do. Dział techniczny spowalnia rozwój, utrudnia śledzenie błędów i zwiększa szanse, że nowy kod wprowadzi błędy.
Luis Perez,

Odpowiedzi:

35

Myślę, że odpowiedź tutaj jest dość prosta - kluczową cechą długu technicznego jest to, że jest to coś, co ponosimy z wyboru.

Podejmujemy decyzje architektoniczne, projektowe lub wdrożeniowe, które, jak się spodziewamy, spowodują nam problemy później, aby szybciej osiągnąć określone cele.

Błąd nie jest czymś, co wybieramy w naszym kodzie - więc de facto nie jest to techniczny dług.

Oczywiście można wysunąć wiele interesujących (i być może słusznych) argumentów na temat wyborów dokonanych po odkryciu, ale zasadniczo (szczególnie w kontekście pytania) nie, błędy nie są długiem technicznym - brzmi dla mnie bardziej jak nadużywanie modnego bingo.


Jako postscriptum - nie zgadzam się z twierdzeniem, że zważywszy, że dług techniczny doprowadzi do błędów sam w sobie, ponieważ daleko posunięty jest on do wielu założeń dotyczących charakteru dokonanych wyborów. Na przykład możesz mieć dobrze napisany, dobrze ustrukturyzowany, objęty testem kod, który wciąż tworzy - powiedzmy - architektoniczne kompromisy dla wczesnej dostawy. Podobnie możesz zrezygnować z automatyzacji procesów wdrażania, co nie doprowadzi do błędów, ale prawdopodobnie doprowadzi do dużego stresu i bólu. Oczywiście, jeśli dług polega na tym, że napisałeś kod, który nie jest SOLIDNY ​​(lub cokolwiek innego), to tak ... ale nie zawsze tak jest.

Murph
źródło
1
+1. Myślę, że odpowiedź BЈовић jest całkiem słuszna, ale twoja odpowiedź naprawdę uderza w sedno. (Jestem jednak trochę zdezorientowany tym, że używasz terminu de facto . Nie sądzę, że możesz powiedzieć, że de jure , błąd jest długiem technicznym?)
ruakh
Używanie języka to świetna zabawa ... spróbuj tego: en.wikipedia.org/wiki/De_facto - czytaj go jako „do wszystkich celów i celów”, co jest wystarczająco bliskie mojej intencji
Murph
„Myślę, że odpowiedź tutaj jest dość prosta - kluczową cechą długu technicznego jest to, że jest to coś, co ponosimy z wyboru”. Skąd wziąłeś tę definicję? Nie sądzę, że to prawda. To jedna część długu technicznego, druga część jest ukryta i zwykle wynika z ignorancji i złych praktyk.
gphilip
de Jure du Jure. Jutro de facto. CO BYŁO DO OKAZANIA.
radarbob
1
zgodnie z Kwadrantem zadłużenia technicznego autorstwa Martina Fowlera można zidentyfikować błędy i zły kod jako „lekkomyślny niezamierzony” dług: martinfowler.com/bliki/TechnicalDebtQuadrant.html . Myślę, że chodzi o to, że jeśli oznaczysz jakieś wrażliwe błędy jako dług, możesz zrozumieć, ile one cię kosztują i czy musisz je wyeliminować. Na przykład, czy masz niechlujny moduł napisany, który zmienia się tylko raz w roku, a przepisanie go zajęłoby tygodnie - prawdopodobnie powinieneś go zachować, ponieważ odsetki od tego długu są bardzo małe
shershen
20

Tak.

Dług techniczny (znany również jako dług projektowy lub dług kodowy) jest neologistyczną metaforą odnoszącą się do ostatecznych konsekwencji złej lub ewoluującej architektury oprogramowania i rozwoju oprogramowania w bazie kodu.

Źródło: Wikipedia

Odczytaj dług techniczny jako coś, czego można uniknąć dzięki lepszemu przepływowi pracy (na przykład poprawne wykonanie architektury przed przejściem do kodowania, TDD itp.), Lepsze praktyki kodowania itp.

Większości błędów można było uniknąć dzięki dodatkowej weryfikacji lub zastosowaniu bardziej formalnych metod. Nie robiąc wszystkiego, co w naszej mocy, aby nie mieć błędów, a przede wszystkim obniżyć bezpośrednie / krótkoterminowe koszty projektu, ale zwiększając dług techniczny.


Po przeczytaniu odpowiedzi BЈовић widzę, że może nie być tak łatwo, jak myślałem.

  • Na przykład Czy błędy są częścią długu technicznego? artykuł twierdzi, że tylko błędy, o których wiesz, ale których nie naprawiłeś, są częścią długu technicznego.

  • Kolejny przykład : Myśli Christophera na temat długu technicznego kwalifikują błędy w wyniku zadłużenia technicznego, a nie jego części. To powiedziawszy, na wiele z wymienionych wyników, takich jak „koszt wdrożenia nowej funkcji”, wpływa liczba błędów.

  • Wreszcie, tworząc model długu technicznego ABCDE-T , uwzględniłem błędy jako jeden z sześciu czynników, ale są one rozpatrywane inaczej. Nie skupiamy się na samych błędach, ale na sposobach ich gromadzenia, ustalania priorytetów i rozwiązywania. Same błędy pojawiają się w wyniku długu technicznego (jak w poprzednim przykładzie), ale nigdy nie pojawiają się jako czynnik długu technicznego.

Biorąc to pod uwagę, nadal jestem skłonny odpowiedzieć, że błędy - wszelkie błędy - są częścią długu technicznego.

Pierwszy argument:

Czytając cytat Jeffa Atwooda, większość błędów kwalifikuje się jako:

dodatkowy wysiłek, który musimy włożyć w przyszły rozwój z powodu szybkiego i brudnego wyboru projektu

W aplikacjach biznesowych prawie każdy błąd pochodzi z szybkiego i brudnego wyboru projektu lub złych praktyk (czy byłby to brak testowania, użycie technologii, których programiści nie znają wystarczająco dużo, brak komunikacji, brak zrozumienia domeny, itp.) Oznacza to, że „poprzez przefakturowanie szybkiego i brudnego projektu na lepszy projekt” i dostosowanie lepszych praktyk, firmy mogą rozwiązać większość swoich błędów.

Drugi argument:

Jeśli zrobimy paralelę między zwykłym długiem firmy, który należy wziąć pod uwagę, gdy firma jest sprzedawana innej, a długiem technicznym, który jest równie ważny, aby wziąć pod uwagę, gdy projekt zostanie sprzedany innej firmie lub do innego zespołu, możemy łatwo zobaczyć, że błędy są częścią długu technicznego, ponieważ nowy zespół:

  • Albo musisz poradzić sobie z tymi błędami przed wprowadzeniem nowych funkcji (punkt 5 testu Joela: Czy naprawiasz błędy przed napisaniem nowego kodu?)

  • Lub trzymaj błędy, zachowując / zwiększając w ten sposób dług techniczny.

Arseni Mourzenko
źródło
1
Osobiście nie uważam wad za dług techniczny, mimo że argument przedstawiony w tej odpowiedzi jest rozsądny, ale a) tak naprawdę nie ma znaczenia, jak zdefiniujemy dług techniczny IMO, i b) jest to tak dobrze napisana odpowiedź, że „ i tak to głosuję. +1!
Bryan Oakley,
13

Jeff Atwood w swoim artykule Spłacanie długu technicznego daje całkiem niezłą odpowiedź na pytanie, czym jest dług techniczny:

dług techniczny wiąże się z wypłatą odsetek, które wynikają z dodatkowego wysiłku, który musimy włożyć w dalszy rozwój z powodu szybkiego i brudnego wyboru projektu. Możemy nadal płacić odsetki lub spłacić kwotę główną, zmieniając szybki i brudny projekt na lepszy. Chociaż spłata kapitału kosztuje, to zyskujemy dzięki zmniejszeniu płatności odsetek w przyszłości.

Ściśle mówiąc, błędy nie są częścią długu technicznego, jeśli nie spowalniają dalszego rozwoju oprogramowania (zmiana rzeczy, dodawanie nowych funkcji itp.). Są to wady oprogramowania.

Jednak gdy naprawienie błędu jest zbyt drogie lub zmusza cię do obejścia go (i wprowadzenia jeszcze większego zadłużenia technicznego), wówczas staje się on częścią długu technicznego.

BЈовић
źródło
1
W rzeczywistości tak jest, ponieważ błędy mogą prowadzić do dodatkowych prac nad nowymi funkcjami, które nie byłyby konieczne bez błędów. Widziałem nawet kod ewoluujący w złym kierunku (narastający większy dług techniczny) z powodu błędu, który w jakiś sposób przekształcił się w „to nie jest błąd, to jest funkcja”, ponieważ klienci pisali skrypty lub cokolwiek, co opiera się na zachowaniu błędnym.
Marjan Venema
@MarjanVenema Dobra uwaga. Nie myślałem o tym.
BЈовић
Pamiętaj, że ten cytat nie pochodzi od Jeffa Atwooda, pochodzi z postu Martina Fowlera . Jeff cytuje to również w swoim blogu.
Uooo,
6

Błąd nie jest długiem technicznym. Dług techniczny ogranicza się do jakości, a nie jej braku. Oprogramowanie nie powinno być dostarczane z błędami. Wiesz, całe to oprogramowanie działa na rzecz kompleksowej dokumentacji.

Najwięksi sprawcy długu technicznego to „tymczasowe poprawki błędów”, znacie tych, których poddajecie testowi i akceptujecie historię. Ci, których sobie obiecałeś, dokonają refaktoryzacji później, ale nigdy tego nie zrobią. W miarę narastania tymczasowych poprawek, poprawek i innych rzeczy kod staje się niepotrzebny, niepotrzebny, trudny do aktualizacji i przetestowania i ogólnie jest koszmarem, ale nadal działa.

Aby poprzeć tę opinię, poszedłem prosto do źródła, Warda Cunninghama. W związku z tym Ward przeprowadził dobry wywiad jakiś czas temu z Capers Jones, warto go obejrzeć.

Debata o długach technicznych z udziałem Warda Cunninghama i Capersa Jonesa

Kolejnym artykułem wartym przeczytania jest Martin Fowler

Martin Fowler o długu technicznym

W artykule Martina znajdziesz link do oryginalnej wzmianki o długu technicznym autorstwa Warda Cunninghama z OOPSLA92:

System zarządzania portfelem WyCash

Cytat z powyższego artykułu:

Chociaż niedojrzały kod może działać dobrze i być całkowicie akceptowalny przez klienta , nadmiar ilości sprawi, że program stanie się niemożliwy do opanowania, co doprowadzi do ekstremalnej specjalizacji programistów i wreszcie nieelastycznego produktu. Wysyłka kodu za pierwszym razem jest jak dług.

Ostatecznie dług techniczny mógł zawierać błędy dla niektórych ludzi i myślę, że to w porządku. Po prostu nie sądzę, że taka była pierwotna intencja.

Klasa abstrakcyjna
źródło
„Przede wszystkim nie należy dostarczać oprogramowania zawierającego błędy”. Wszystkie programy oprócz najprostszego programu zawierają błędy. Ustawiłeś ten pasek za wysoko.
bhspencer
2

Ściśle mówiąc, odpowiedź na twoje pytanie brzmi: nie.

Dług techniczny może (i prawdopodobnie będzie) prowadzić do błędów, ale stwierdzenie, że jakikolwiek błąd jest wynikiem długu technicznego, polega na interpretacji dwóch faktów: jest błąd i istnieje dług techniczny (zakładając, że można to uznać za fakt).

Jeśli twój Scrum Master twierdzi „jako teorię”, że błędy są wynikiem technicznego długu, to skraca rogi. Jeśli mówi to o konkretnych błędach, które ciągle się pojawiają, to może mieć rację - stąd nie widzimy jakości kodu ;-)

Może również mieć ciągłą skargę na to, że ludzie nie słuchają go o długu technicznym, dlatego też oznaczają każdy błąd jako dług techniczny, ale teraz spekuluję.

Jan Doggen
źródło
2

Moim zdaniem naprawdę nie ma znaczenia, czy mówisz, że błędy są częścią długu technicznego ... czy nie.

Oczywistym faktem jest, że istniejące błędy stanowią dodatkową pracę, która może wymagać wykonania w przyszłości, aby je naprawić lub obejść.

Dług techniczny (jak zwykle używa się etykiety) stanowi również dodatkową pracę, która może wymagać wykonania w przyszłości ... w ten czy inny sposób.

Tak więc, czy powiesz, że znane (lub nieznane) błędy są długiem technicznym ... czy nie ... to tak naprawdę tylko kwestia definicji. A ponieważ nie ma wiarygodnej definicji 1 „długu technicznego”, cała dyskusja jest w pewnym sensie bezcelowa.

Jak napisał Lewis Carroll:

„Kiedy używam słowa” - powiedział Humpty Dumpty, raczej pogardliwym tonem, „oznacza to, co wybrałem, to znaczy - ani więcej, ani mniej”. .

Tak właśnie działa język naturalny. Słowa oznaczają, co ludzie myślą. Definicje słownikowe i tak dalej dokumentują jedynie sposób użycia słów i niekoniecznie są dokładną dokumentacją. Jeśli Twój Scrum Master chce określać znane błędy mianem długu technicznego, to kto ma powiedzieć, że się myli?


1 - Cytowanie osób takich jak Ward Cummingham i Caper Jones też nie pomaga. W najlepszym razie mówi nam, co mają na myśli (lub mieli na myśli), kiedy używają (używają) frazy. Nie „posiadają” frazy. Chociaż są to bez wątpienia władze w tych kwestiach, to wciąż tylko ich opinia.

Stephen C.
źródło