Wprowadzenie do długu technicznego

Dług techniczny to termin opisujący przyszłe koszty, które będą pochodzić z wyboru łatwego rozwiązania dzisiaj zamiast korzystać z lepszych rozwiązań, które potrwałyby dłużej.

Termin "dług techniczny" został wybrany, ponieważ jest podobny do długu finansowego. Często zdarza się, że osoby zadłużone podejmują decyzje, które wydają się słuszne lub jedyną dostępna opcją, ale w ten sposób zwiększają się odsetki.

Im większe narasta zainteresowanie, tym trudniej staje się dla nich w przyszłości i tym mniej mają opcji później. Z długiem finansowym, wkrótce odsetki rosną na odsetki, tworząc efekt kuli śnieżnej. Podobnie dług techniczny może narastać do momentu, w którym deweloperzy spędzają prawie cały czas na rozwiązywaniu problemów i przerabianiu, planowanym lub nieplanowanym, zamiast dodawać wartość.

Jak to się dzieje?

Najczęstszym pretekstem jest napięte terminy. Gdy deweloperzy są zmuszeni do szybkiego tworzenia kodu, często będą robić skróty. Na przykład zamiast refaktoryzować metodę w celu uwzględnienia nowych funkcji, mogą skopiować ją do utworzenia nowej wersji. Następnie testują tylko nowy kod i mogą uniknąć wymaganego poziomu testowania, jeśli zmienią oryginalną metodę, ponieważ używają go inne części kodu.

Teraz mają dwie kopie tego samego kodu, które należy zmodyfikować w przyszłości zamiast jednego, i ryzykują, że logika staje się inna. Istnieje wiele przyczyn. Na przykład wśród deweloperów, brakuje umiejętności technicznych i dojrzałości, lub nie ma wyraźnej własności ani kierunku produktu.

Organizacja może w ogóle nie mieć standardów kodowania, więc deweloperzy nawet nie wiedzieli, co powinni produkować. Deweloperzy mogą nie mieć jasnych wymagań do wykonania, lub mogą podlegać zmianom wymagań na ostatnią chwilę.

Konieczne prace refaktoryzacji mogą być opóźnione. Może nie być żadnych testów jakości kodu, ręcznych lub zautomatyzowanych. W końcu to tylko utrudnia i trudniejsze dostarczanie wartości klientom w rozsądnym przedziale czasu i przy rozsądnych kosztach.

Dług techniczny jest jednym z głównych powodów, dla których projekty nie spełniają swoich terminów.

Wraz z upływem czasu zwiększa się w znacznie taki sam sposób, jak w przypadku długu pieniężnego. Typowe źródła długu technicznego to:

• Brak stylu kodowania i standardów
• Brak lub słaba konstrukcja przypadków testowych jednostkowych
• Ignorowanie lub brak zrozumienia zasad projektowania zorientowanych na obiekty
• Monolityczne klasy i biblioteki kodu
• Źle planowane użycie technologii, architektury i podejścia (zapominając, że wszystkie atrybuty systemowe, wpływające na konserwację, środowisko użytkownika, skalowalność i inne, muszą być brane pod uwagę)
• Kod nadmiernej inżynierii (dodawanie lub tworzenie kodu, który nie jest wymagany, dodawanie kodu niestandardowego, gdy istniejące biblioteki są wystarczające lub tworzenie warstw lub składników, które nie są potrzebne)
• Niewystarczające komentarze i dokumentacja
• Niepisanie kodu samodokumentującego się (w tym nazw klas, metod i zmiennych, które są opisowe lub wskazują intencję)
• Wykonywanie skrótów w celu spełnienia terminów
• Pozostawienie martwego kodu w miejscu

Widzieliśmy, że dług techniczny powoduje problemy podczas opracowywania i sprawia, że znacznie trudniej jest dodać dodatkową wartość dla klienta.

Posiadanie długu technicznego w projekcie zmniejsza produktywność, frustruje zespoły programistyczne, sprawia, że kod jest trudny do zrozumienia i kruchy, zwiększa czas wprowadzania zmian i weryfikowania tych zmian. Nieplanowana praca często przeszkadza w planowanej pracy.

W dłuższej perspektywie osłabia również siłę organizacji. Dług techniczny ma tendencję do narastania w organizacji. Zaczyna się małe i rośnie z czasem. Za każdym razem, gdy wprowadzane jest szybkie tymczasowe rozwiązanie lub test jest pomijany, kiedy zmiany trzeba wprowadzić w pośpiechu, problem się pogłębia. Koszty pomocy technicznej są wyższe i wyższe, a w końcu pojawia się poważny problem.

W końcu organizacja nie może reagować na potrzeby swoich klientów w odpowiednim czasie i w sposób ekonomiczny.

Pomiar automatyczny do monitorowania

Jednym z kluczowych sposobów zminimalizowania ciągłego budowania długu technicznego jest użycie zautomatyzowanego testowania i oceny.

W kolejnych pokazach przyjrzymy się jednemu z typowych narzędzi używanych do oceny długu: SonarCloud. (Oryginalna wersja lokalna to SonarQube).

Dostępne są inne narzędzia i omówimy kilka z nich.

Później w następnym praktycznym laboratorium zobaczysz, jak skonfigurować usługę Azure Pipelines do korzystania z usługi SonarCloud, zrozumieć wyniki analizy i na koniec skonfigurować profile jakości w celu kontrolowania zestawów reguł używanych przez usługę SonarCloud podczas analizowania projektów.

Aby uzyskać więcej informacji, zobacz SonarCloud.

Do przeglądu:

Usługę Azure DevOps można zintegrować z szeroką gamą istniejących narzędzi używanych do sprawdzania jakości kodu podczas kompilacji.

Jakich narzędzi jakości kodu używasz obecnie (jeśli istnieje)?

Jak lubisz lub nie lubisz narzędzi?