Jakie korzyści widziałeś w zadłużeniu technicznym?

29

Ten artykuł na temat długu technicznego ma kilka dobrych zalet, w tym:

Praca nad „sprawami technicznymi” działa najlepiej, gdy opiera się na opowieściach. Baza kodu prawdopodobnie potrzebuje pracy wszędzie, ale wypłata zostanie uzyskana tylko tam, gdzie kod będzie przetwarzany z powodów związanych z użytkownikiem. Jeśli żadne wątki nie przejdą przez jakiś chrupiący obszar, praca nad nim jest w dużej mierze zmarnowana.

Dlatego wolę podejście jak zwykle opowiadać historie (ale prawdopodobnie mniej) i postępować zgodnie z zasadą „harcerstwa”, polegającą na opuszczaniu obozowiska lepiej niż go znalazłeś. Innymi słowy, dokądkolwiek prowadzą nas historie, napiszmy więcej testów, zróbmy bardziej agresywnie.

Takie podejście ma co najmniej następujące zalety:

  • utrzymuje „najbardziej rozsądny” przepływ historii;
  • zapewnia pomoc wszystkim talentom zespołu;
  • zapewnia całemu zespołowi nauczenie się, jak utrzymywać kod w czystości;
  • skupia się na doskonaleniu dokładnie tam, gdzie jest potrzebne;
  • nie marnuje ulepszeń, które mogą być potrzebne;

Widziałem, że jakość kodu ma bardzo duży wpływ na produktywność w długim okresie, dlatego wierzę, że należy rozwiązać problem długu technicznego. Myślę, że powyższy post ma sens, ale nie jestem pewien co do dwóch ostatnich punktów. Chcę dowiedzieć się, jakie są prawdziwe korzyści z czyszczenia długu technicznego, nawet jeśli nie było to związane z historiami użytkowników.

Jakie pozytywne korzyści widziałeś po oczyszczeniu bazy kodu i uwolnieniu się od długu technicznego? Jakich metod użyłeś do wykonania pracy?

Nicole
źródło
1
Dlaczego kod miałby w ogóle istnieć, jeśli nie wpływa na historię użytkownika? (administratorzy systemu są nadal użytkownikami - dlatego nadal obowiązuje rejestrowanie i „pod przykryciem”)
Steven Evers
2
@ Sn0rfus To dobra uwaga. Współpracowałem jednak z zespołami, które odmówiły ponownego rozważenia, czy wszystko, co zostało uznane za „działające”, zostało wykonane poprawnie. Nigdy nie zostaną one wyczyszczone, ponieważ funkcje zostały uznane za „wykonane”. Często miałyby one ogromny pośredni wpływ na przyszły rozwój, ponieważ zostały wykonane źle, ale zarówno programiści, jak i nasz menedżer po prostu przymknęli oczy.
Nicole,
(Twój komentarz na temat usuwania) +1. Wiem dokładnie o czym mówisz.
talonx

Odpowiedzi:

31

Mogę podać jeden przykład z mojego doświadczenia.

Około 10 lub 12 lat temu odziedziczyłem aplikację od zespołu programistów, który ostatecznie odszedł z firmy (zbyt długo, aby się tutaj dostać ...). System był dużym rodzimym systemem generowania raportów oprogramowania pośredniego. Działał on co tydzień w nocy i generował około 2 tuzinów raportów Excela dla kadry kierowniczej firmy z listy Fortune 500. Kiedy go odziedziczyłem, bieganie trwało około 5-6 godzin, a w danym tygodniu zawiodło co najmniej 2 noce.

Nie byłem szczęśliwym obozowiczem, gdy dostałem ten bałagan.

Początkowo moim planem było po prostu zatrzymać krwawienie i naprawić główną przyczynę awarii. Po tym, jak poczułem się bardziej komfortowo z bazą kodu, zacząłem szukać miejsc, w których mógłbym dokonać refaktoryzacji oraz dodać stabilność i wydajność. W ciągu około 2 lat wprowadziłem wiele, wiele zmian w systemie. Zrezygnowaliśmy z tego systemu kilka lat temu i wtedy cały proces trwał 45 minut i od lat nie powodował żadnych problemów.

Dużo pracy poświęcono na spłatę długu technicznego, ale było warto, było warto. Fajnie było nie odbierać żadnych telefonów w środku nocy, gdy system zawiódł. Miło było wejść do biura na monringu i zobaczyć w dziennikach tylko dobre wieści.

(Na bok ... Po kilku latach spotkałem jednego z głównych programistów tego systemu. Zapytał mnie, jak się miewa, i powiedziałem mu, jak zły jest system. Właściwie przeprosił i powiedział, że wie, że będzie garstka do wsparcia po tym, jak odszedł i żałował, że nie wykonał lepszej pracy).

Walter
źródło
8
To brzmi jak bolesne doświadczenie, ale z pozytywnym skutkiem. Dzięki za udostępnienie.
Ali
11

Z mojego doświadczenia wynika, że ​​korzyści płynące z czyszczenia kodu są najbardziej zauważalne, gdy muszę zachować kod tam, gdzie czyszczenie nie zostało wykonane. Po zakończeniu czyszczenia moje zmiany polegają na przeczytaniu kodu, wykryciu jednego lub dwóch miejsc, które należy zmienić, i przejściu od tego miejsca. Jeśli czyszczenie nie zostało zrobione, dodaj pierwszy krok, aby przeczytać kod kilka razy i spróbować dowiedzieć się, co autor (czasem ja) myślał, kiedy go napisał.

Larry Coleman
źródło
2
Zgadzam się - najlepsza wypłata zwykle nie jest widoczna, a zwiększa wydajność.
Michael K,
5

wyeliminowanie zadłużenia technicznego daje mniejsze wsparcie techniczne i lepszą podstawę do ulepszeń

zawsze

Steven A. Lowe
źródło
4
To niekoniecznie jest prawdą. Ostatnie dwa punkty w komentarzu PO oznaczają, że nie powinieneś pracować nad refaktoryzacją nie chcąc. Jeśli okaże się, że rzadko używany fragment kodu jest bardzo źle napisany i zdecydujesz się wyeliminować ten dług techniczny, oznacza to, że nie możesz dodać nowej funkcjonalności lub usunąć długu technicznego gdzie indziej, powiedz gdzieś, że JEST dużo używany. W rzeczywistości mamy ograniczony czas i absolutnie musimy ustalić, gdzie i kiedy zdecydujemy się usunąć dług techniczny.
Nemi
@Nemi: cały dług techniczny nie jest równy; prosimy o właściwy osąd.
Steven A. Lowe,
1
Właśnie komentowałem, z powodu dużej, odważnej ZAWSZE w twoim poście. Chyba źle zrozumiałem twoją odpowiedź.
Nemi
4

Jednym z moich doświadczeń było zarządzanie zespołem Site Performance u mojego poprzedniego pracodawcy. Każdej nocy, od godziny do dwóch godzin, witryna monitorowana przez mój zespół spadała poniżej dopuszczalnych progów wydajności z powodu szybkiego wyskakiwania informacji z witryny przez bota. Zespół, który podjął ten problem, polegał na zalogowaniu się do ręcznego systemu administracyjnego i zablokowaniu adresów IP, które były przyczyną problemów. Nie trzeba dodawać, że kosztowało to jednego członka zespołu godzin snu prawie każdej nocy. Zauważyłem, co się dzieje, i sam wziąłem na telefon BlackBerry na kilka dni, aby zobaczyć, jak źle było i dać zespołowi trochę odpoczynku.

Po kilku dniach po prostu poszedłem do właściciela firmy zespołu i poinformowałem ich, że gdybyśmy nie wdrożyli automatycznego systemu blokowania takiego, że boty miałyby znacznie trudniejszy czas wpływający na wydajność witryny, prawdopodobnie stracilibyśmy niektórzy, jeśli nie wszyscy członkowie zespołu z powodu zmęczenia i wypalenia zawodowego. Zgodzili się i wdrożyliśmy system, który pozwalał nam spać w nocy. Właściciel firmy zrozumiał, że koszt kilku dni lub tygodnia rozwoju był minimalny w porównaniu z kosztem zatrudnienia / szkolenia nowych inżynierów.

Macy Abbey
źródło
+1 za omówienie problemu z PO / BO. Tak to powinno działać (najlepiej :-)).
śleske,
A BTW, nie nazwałbym tego przykładem długu technicznego. Jest to wyraźnie brakująca funkcja, którą Twój zespół musiał zrekompensować pracą ręczną. Moja definicja brzmiałaby następująco: Jeśli wpływa to na użytkownika końcowego (bezpośrednio lub pośrednio), nie jest to dług techniczny, ale po prostu błąd / brakująca funkcja
sleske
2

W odniesieniu do dwóch ostatnich punktów: Rozumiem, skąd pochodzi, jak wyjaśniono w jego oryginalnym poście :

Czy też możliwe jest ponowne przypisanie niektórych programistów, aby załatwić te kwestie techniczne, podczas gdy reszta zespołu nadal zajmuje się sprawami zorientowanymi na użytkownika? Może to wpłynąć na szybkość zespołu, ale co z tego?

„Więc co” równa się: właściciel produktu i inni ludzie biznesu stają się niezadowoleni. A kiedy mama jest nieszczęśliwa, wszyscy są nieszczęśliwi.

Jednak granica między tym, co należy zrobić, a tym, co można zrobić, jest dość niejasna. Obsługa użytkownika jest bardzo szeroka i obejmuje wydajność oraz występowanie błędów. Ale w niektórych przypadkach podstawowy problem niskiej wydajności i częstego występowania błędów leży głębiej w kodzie. Powiedzieć to w swoich słowach: historia może nie przejść przez kruchą strefę, ale ta krucha strefa może ukryć paskudne rzeczy, które atakują historię na oczyszczonej ścieżce obok.

Rzeczy, które nie wpływają na ogólną wydajność, są mniej interesujące do czyszczenia, ale należy bardzo dokładnie ocenić wpływ tych punktów. Najczęściej mają one pośredni wpływ, który może być dość znaczny.

Joris Meys
źródło
2

Największą korzyścią, jaką organizacja otrzyma w wyniku spłaty zadłużenia technicznego, jest unikanie składanych odsetek. W poniższym wpisie na blogu znajduje się przykład, który pokazuje, jak główna kwota należna z tytułu długu technicznego wzrosła z 160 tys. Do 430 tys. USD w ciągu zaledwie pięciu lat. Zajmie to pełnoetatowego programisty zajmującego się wyłącznie obsługą długu. Pomoże to spojrzeć na to z perspektywy decydentów!

Z blog.acrowire.com .

Josh K.
źródło