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

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?

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.

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.

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łą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.

Ś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ę.

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 ¹ „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.}