Wprowadzenie do długu technicznego
Dług techniczny to termin, który opisuje przyszłe koszty, które zostaną poniesione, wybierając łatwe rozwiązanie dzisiaj zamiast korzystać z lepszych rozwiązań, ponieważ zajęłoby to dłużej.
Termin-dług techniczny został wybrany do porównania z długiem finansowym. Często zdarza się, że ludzie w długu finansowym podejmują decyzje, które wydają się odpowiednie lub jedyną opcją w tym czasie, ale w ten sposób zwiększa się zainteresowanie.
Im większe zainteresowanie, tym trudniej jest im w przyszłości i im bardziej drobne opcje dostępne później. Z długiem finansowym, wkrótce, odsetki rosną na odsetki, tworząc efekt śnieżki. Podobnie dług techniczny może budować się do punktu, w którym deweloperzy spędzają prawie cały czas na sortowaniu problemów i przeróbce, planowane lub nieplanowane, 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, skopiujmy ją, aby utworzyć nową wersję. Następnie przetestuję tylko mój nowy kod i mogę uniknąć wymaganego poziomu testowania, jeśli zmienię oryginalną metodę, ponieważ używają go inne części kodu.
Teraz mam dwie kopie tego samego kodu, które muszę zmodyfikować w przyszłości zamiast jednego, a ja ryzykuję rozbieżność logiki. Istnieje wiele przyczyn. Na przykład może brak umiejętności technicznych i dojrzałości między deweloperami lub brak wyraźnej własności lub kierunku produktu.
Organizacja może w ogóle nie mieć standardów kodowania. Dlatego deweloperzy nawet nie wiedzieli, co powinni produkować. Deweloperzy mogą nie mieć dokładnych wymagań, które należy spełnić. Cóż, mogą one podlegać zmianom wymagań w ostatniej chwili.
Konieczne refaktoryzacja może być opóźniona. 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 testów jednostkowych.
- Ignorowanie lub niezrozumienie zasad projektowania zorientowanych na obiekty.
- Monolityczne klasy i biblioteki kodu.
- Źle wyobrażał sobie wykorzystanie 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.
- Nie można pisać kodu dokumentowania samodzielnego (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.
Uwaga
Z czasem dług techniczny musi zostać spłacony. W przeciwnym razie zdolność zespołu do rozwiązywania problemów i implementowania nowych funkcji i ulepszeń zajmie więcej czasu i ostatecznie stanie się kosztowna.
Widzieliśmy, że dług techniczny dodaje zestaw problemów podczas opracowywania i sprawia, że znacznie trudniej jest dodać dodatkową wartość klienta.
Posiadanie długu technicznego w produktywności saps projektu, 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 jest w drodze planowanej pracy.
Długoterminowe, to również saps siłę organizacji. Dług techniczny ma tendencję do pełzania w organizacji. Zaczyna się mały i rośnie wraz z upływem czasu. Za każdym razem, gdy szybkie hack jest wykonywane lub test jest pomijany, ponieważ zmiany muszą być pędzone, problem rośnie gorzej i gorzej. Koszty pomocy technicznej są wyższe i wyższe i niezmiennie pojawiają się poważne problemy.
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 pozyskiwania 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.
W skrócie:
Usługę Azure DevOps można zintegrować z szeroką gamą istniejących narzędzi używanych do sprawdzania jakości kodu podczas kompilacji.
Które narzędzia jakości kodu są obecnie używane (jeśli istnieją)?
Jak lubisz lub nie lubisz narzędzi?