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?

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).

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

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

zawsze

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.

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.

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 .