Jak mogę oszacować kwotę długu technicznego istniejącego w projekcie?

67

Czy ktoś wie, czy istnieje jakiś rodzaj narzędzia do obliczania długu technicznego bazy kodu, jako rodzaju miernika kodu? Jeśli nie, to czy ktoś wie o algorytmie lub zestawie heurystyk?

Jeśli żadna z tych rzeczy nie istnieje do tej pory, byłbym zainteresowany pomysłami, jak zacząć od takiej rzeczy. To znaczy, w jaki sposób mogę oszacować dług techniczny powstały przy użyciu metody, klasy, przestrzeni nazw, zestawu itp.

Najbardziej interesuje mnie analiza i ocena bazy kodu w języku C #, ale nie krępuj się również wejść w inne języki, szczególnie jeśli pojęcia są transcendentne.

Erik Dietrich
źródło
12
Dług techniczny wynika z decyzji, a nie z kodu. Nalicza się z powodu złych wyborów zarządzania. Nie jest jasne, że „metoda, klasa, przestrzeń nazw, zestaw” same w sobie zawierają dług techniczny. Stanowią one odpowiedzialność, gdy istnieje lepszy wybór.
S.Lott,
7
Argumentowałbym (w kontekście metafory długu), że menedżerowie mogą być posiadaczami długów, ale artefakty kodu reprezentują wycenę długu i można je skwantyfikować. Oznacza to, że zgadzam się, że menedżerowie mogą podjąć decyzję typu „zapomnij o testowaniu jednostkowym, ponieważ nie mamy czasu”, a tym samym zaciągnąć dług techniczny. Ale z pewnością uważam, że można przypisać liczbę do poszczególnych elementów kodu jako heurystykę. Pomyśl o tym w ten sposób - jeśli kierownictwo podejmie serię okropnych decyzji na przyszłość, ale nie napisano żadnego kodu, czy w tej chwili jest jakiś dług?
Erik Dietrich,
3
„czy w tej chwili jest jakiś dług?” Dług musi się kumulować, masz rację. Ale to nie jest kod; należy cofnąć ilość wykonanej „pracy”. Specyfikacje, projekty, kod, praca DBA, wszystko to musi zostać przerobione. Pomiar zadłużenia na podstawie artefaktów oprogramowania (takich jak wiersze kodu źródłowego) jest podobny do przewidywania kosztów rozwoju.
S.Lott,
7
Mierzenie długu technicznego jest trudne, a ponadto dezorientuje menedżerów. Mogę jednak powiedzieć ci dobry sposób na walkę z długiem technicznym: tanie, ładne i działające prototypy, szczególnie jeśli baza kodu obraca się wokół GUI. Jak sugeruje Joel tutaj: joelonsoftware.com/articles/fog0000000332.html , spędzić trochę czasu każdego dnia czyszczenia rzeczy. Zmiana musi być pozytywną poprawą, a nie „OMG, nasz dług techniczny = pentablobs i rośnie wykładniczo w tempie ... niebo spada”. Po prostu spędzaj trochę czasu każdego dnia na kaizen w sposób, który nie psuje rzeczy, które działają. Zaprzyjaźnić się.
Job
6
@ZoranPavlovic W twoim dziwacznym i niezamówionym fałszywym dylemacie brakuje trzeciej opcji: Chciałem wiedzieć, czy istnieją narzędzia, które próbują oszacować dług techniczny.
Erik Dietrich,

Odpowiedzi:

38

Dług techniczny to po prostu abstrakcyjny pomysł, że gdzieś na linii projektowania, budowy, testowania i utrzymania systemu podjęto pewne decyzje, tak że produkt stał się trudniejszy do przetestowania i utrzymania. Posiadanie większego zadłużenia technicznego oznacza, że ​​trudniej będzie nadal rozwijać system - albo musisz poradzić sobie z długiem technicznym i przeznaczać coraz więcej czasu na coś, co w przeciwnym razie byłoby prostymi zadaniami, albo musisz inwestować zasoby (czas i pieniądze) w celu zmniejszenia zadłużenia technicznego poprzez refaktoryzację kodu, udoskonalenie testów itd.

Istnieje wiele wskaźników, które mogą dać ci wskazówki co do jakości kodu:

  • Pokrycie kodu. Istnieją różne narzędzia, które informują, jaki procent twoich funkcji, instrukcji i linii jest objęty testami jednostkowymi. Można również odwzorować testy systemowe i testy akceptacyjne z powrotem na wymagania, aby określić procent wymagań objętych testem na poziomie systemu. Odpowiedni zasięg zależy od charakteru aplikacji.
  • Sprzężenie i spójność . Kod, który wykazuje niskie sprzężenie i wysoką spójność jest zazwyczaj łatwiejszy do odczytania, zrozumienia i przetestowania. Istnieją narzędzia do analizy kodu, które mogą raportować stopień sprzężenia i spójności w danym systemie.
  • Cyklomatyczna złożoność to liczba unikalnych ścieżek w aplikacji. Zwykle jest liczony na poziomie metody / funkcji. Złożoność cykliczna jest związana ze zrozumiałością i testowalnością modułu. Wyższe wartości złożoności cyklicznej wskazują nie tylko, że ktoś będzie miał więcej problemów z przestrzeganiem kodu, ale złożoność cykliczna wskazuje również liczbę przypadków testowych wymaganych do uzyskania zasięgu.
  • Różne miary złożoności Halsteada zapewniają wgląd w czytelność kodu. Liczą one operatory i operandy, aby określić głośność, trudność i wysiłek. Często mogą one wskazywać, jak trudno będzie komuś odebrać kod i go zrozumieć, często w przypadkach takich jak przegląd kodu lub nowy programista w bazie kodu.
  • Ilość duplikatów kodu. Duplikat kodu może wskazywać na możliwość refaktoryzacji do metod. Posiadanie duplikatu kodu oznacza, że ​​jest więcej linii do wprowadzenia błędu, i większe prawdopodobieństwo, że te same defekty występują w wielu miejscach. Jeśli ta sama logika biznesowa istnieje w wielu miejscach, trudniej jest zaktualizować system, aby uwzględnić zmiany.

Często narzędzia analizy statycznej będą w stanie ostrzec Cię o potencjalnych problemach. Oczywiście to, że narzędzie wskazuje na problem, nie oznacza, że ​​jest problem - ludzka ocena wymaga ustalenia, czy coś może być problematyczne na drodze. Te wskaźniki tylko ostrzegają, że nadszedł czas, aby przyjrzeć się bliżej systemowi lub modułowi.

Jednak te atrybuty skupiają się na kodzie. Nie wskazują one łatwo na zadłużenie techniczne w architekturze lub projekcie systemu, które może odnosić się do różnych atrybutów jakości.

Thomas Owens
źródło
1
Obecnie używam wskaźników NDepend ( ndepend.com ), CodeRush i VS, aby mieć oko na wskaźniki, o których wspominasz (z wyjątkiem miar Halstead, które omówię dalej). Pomyślałem, że mógłbym użyć pewnej kombinacji tych wskaźników, aby spróbować umieścić jakąś liczbę na danym elemencie kodu, który z grubsza wskazywałby, na pierwszy rzut oka, jak kosztowny byłby ciągły rozwój.
Erik Dietrich,
@ErikDietrich Być może możesz, ale prawdopodobnie nie podałbym tej wartości ilościowo. Być może bardziej odpowiedni byłby raport w stylu „podsumowania” na temat tego, co mówią twoje narzędzia metryczne, w odniesieniu do zmian w czasie.
Thomas Owens
2
Kolejną prostą miarą, którą dodam do listy, jest liczba TODO / HACK / WTF? komentarze w bazie kodu ...
MaR
@Mar Zakłada, że ​​właściwie z nich korzystasz i nie grasz w nie dla własnej korzyści. Chcesz trochę czasu, aby wyczyścić bazę kodu, po prostu dodaj te komentarze tam, gdzie nie są odpowiednie. Nie przejmuj się bazą kodu, po prostu usuń je z miejsca, w którym powinny być. Komentarze mogą kłamać, kod nie.
Thomas Owens
1
@Thomas Owens: zgodził się, ale prawie wszystkie dane można oszukać. Przy właściwym i uczciwym zastosowaniu „wskaźnik TODO” zapewnia tanie informacje o tym, jakiego kodu brakuje lub należy go zmienić (= niewidoczny dług dla wskaźników opartych tylko na kodzie).
MaR
23

Sonar ma heurystykę zadłużenia technicznego, a także kilka innych funkcji przydatnych w projekcie oprogramowania.

Obsługuje również dość szeroki zakres języków.

SonarQube (wcześniej Sonar ) to platforma typu open source do ciągłej kontroli jakości kodu ...

  • Obsługa ponad 25 języków: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL itp.
  • SonarQube jest również używany w Android Deveopment.
  • Oferuje raporty na temat powielonego kodu, standardów kodowania, testów jednostkowych, pokrycia kodu, złożonego kodu, potencjalnych błędów, komentarzy oraz projektu i architektury.
  • Wehikuł czasu i widoki różnicowe.
  • W pełni zautomatyzowane analizy: integruje się z narzędziami Maven, Ant, Gradle i ciągłej integracji (Atlassian Bamboo, Jenkins, Hudson itp.).
  • Integruje się ze środowiskiem programistycznym Eclipse
  • Integruje się z narzędziami zewnętrznymi: JIRA, Mantis, LDAP, Fortify itp.
  • Możliwość rozbudowy za pomocą wtyczek.
  • Implementuje SQALE metodologii obliczenia długu technicznego ...
Robert Greiner
źródło
1
Fajne dzięki! Mam i używam NDepend do mojej pracy w języku C #, ale robię też trochę pracy w Javie i tam też jestem zainteresowany danymi. Przynajmniej daje mi to funkcjonalność dla Javy i może okazać się miłym uzupełnieniem NDepend.
Erik Dietrich,
Wspaniale, używamy Sonaru tam, gdzie pracuję i robi kilka naprawdę fajnych rzeczy, które dają wgląd w stan twojej bazy kodu.
Robert Greiner
2
@ErikDietrich, FYI Sonar ma również wtyczkę C # .
Péter Török
@ErikDietrich FYI jest teraz wtyczka NDepend do sonaru ndepend.com/docs/sonarqube-integration-ndepend
Patrick Smacchia - NDepend dev
Czy istnieją alternatywy typu open source?
hellboy
5

Nienawidzę używać analogii z finansów, ale wydaje się to bardzo właściwe. Gdy wyceniasz coś (aktywa dowolnego rodzaju), może to mieć zarówno wartość wewnętrzną, jak i zewnętrzną. W tym przypadku istniejący kod ma wartość wewnętrzną, która byłaby wielkością odpowiadającą względnej jakości wspomnianego kodu, a także miałaby wartość zewnętrzną (wartość z tego, co można zrobić z kodem), a te ilości byłyby addytywne. Rzeczywistą wartość można podzielić na kredyty i obciążenia (dobre i złe) przy użyciu dowolnej metodologii stosowanej do oceny kodu (+5 za komentarze / czytelność, -10 za pokrycie kodu itp.)

Z pewnością nie znam żadnych narzędzi, które by to dziś określały ilościowo i myślę, że miałbyś do dyspozycji zupełnie nową dyskusję, jeśli spierasz się o zalety różnych strategii „wyceny długów”, ale zgadzam się z Matthew - dług jest łączny koszt uzyskania kodu tak dobrego, jak to tylko możliwe, przy użyciu dowolnej metody, której używasz, aby obliczyć liczbę roboczogodzin potrzebnych do jego uzyskania.

Należy również wziąć pod uwagę, że z pewnością istnieje miara opłacalności, dzięki której w miarę zbliżania się do „doskonałości” wartość godziny spędzonej na bazie kodu jest bardziej niż prawdopodobne wykładniczo zmniejszana, więc prawdopodobnie istnieje dodatkowy problem z optymalizacją zmaksymalizować użyteczność wykonanej pracy.

PatternMatching
źródło
Tak, pojęcie malejących zysków krańcowych jest z pewnością czymś, na czym chciałbym się zwrócić przy opracowywaniu i dopracowywaniu tej miary. Zatem nie tylko „oto mój obiektywny argument przemawiający za refaktoryzacją tej klasy z perspektywy biznesowej”, ale także „oto moje uzasadnienie, że nie zawracam sobie tym głowy”.
Erik Dietrich,
5

Pomiędzy programistami miarą zadłużenia technicznego wydaje się być WTF / minutę .

Problem z tą „miarą” polega na tym, że zazwyczaj trudno jest komunikować się „na zewnątrz”.

Metodą, która zadziałała dla mnie w komunikowaniu długu technicznego „osobom z zewnątrz” była ilość wysiłków związanych z testowaniem i naprawą błędów (szczególnie w celu naprawy błędów regresji ) potrzebnych do pomyślnego dostarczenia.

Słowo ostrzeżenia: chociaż takie podejście jest dość potężne, lepiej by było dwukrotnie sprawdzić stare dobre WTF / minutę przed skorzystaniem z niego. Rzecz w tym, że jest to dość kłopotliwe: aby uzyskać dane, należy dokładnie śledzić czas i dokładnie rejestrować je według odpowiednich kategorii.

  • o wiele łatwiej jest podać 3 tygodnie całkowitej kwoty spędzonej na implementacji funkcji A, niż
     
    spędziłem 14 godzin na projektowaniu implementacji funkcji A, następnie 29 godzin na testowaniu dymu, a następnie 11 godzin na implementacji poprawek dla regresji, które odkryłem, a następnie 18 godzin na testowaniu jakości - już implementacja funkcji. Następnie pracownicy działu jakości spędzili 17 godzin na testowaniu pierwszego wydania kandydata. Następnie spędziłem 13 godzin na analizie błędów zgłoszonych przez QA do pierwszego wydania kandydata i 3 godziny na wdrożenie poprawek. Następnie spędziłem 11 godzin na testowaniu zadymienia wprowadzonych przeze mnie zmian w początkowej wersji kandydata. Po tym...

W każdym razie dane o testowaniu i naprawianiu błędów były dość łatwe do przekazania z mojego doświadczenia.

W ostatnim wydaniu spędziliśmy około 90% czasu na testowaniu i naprawianiu błędów regresji. W następnej wersji zasugeruj trochę wysiłku, aby obniżyć tę wartość do 60-70%.


Kolejne słowo ostrzeżenia. Dane takie jak 90% powyżej można interpretować nie tylko jako wskaźnik zadłużenia technicznego, ale także (niespodzianka) jako wskazówkę, że ktoś nie jest dość biegły w programowaniu / określonej technologii. „Po prostu robisz za dużo błędów w swoim kodzie”.

Jeśli istnieje ryzyko błędnej interpretacji danych w ten sposób, pomocne są dodatkowe dane referencyjne dotyczące czegoś mniej podatnego na WTF, z którym można je porównać.

  • Powiedzmy, że jeśli istnieją dwa podobne komponenty / aplikacje utrzymywane przez tego samego dewelopera (programistów), pierwsze wydanie na „poziomie marnotrawstwa” około 50%, a drugie na 80-90, to dość mocny argument za tym, że drugi jest przedmiotem długu technicznego.

Jeśli w projekcie są zaangażowani testerzy, mogą również przyczynić się do bardziej obiektywnej oceny danych. Jak wspomniałem w innej odpowiedzi ,

Dzięki testerom możesz uzyskać pomoc w zrozumieniu problemów projektowych. Gdy tylko programiści narzekają na jakość kodu , często brzmi to jak subiektywne WTF zza zamkniętych drzwi .
 
Ale kiedy to powtórzy facet QA, który powiedział coś w rodzaju component A100 błędów regresji dla 10 nowych funkcji, w przeciwieństwie do component B10 błędów w regresji na 20 nowych funkcji , komunikacja nagle zmienia się w zupełnie inną grę.

komar
źródło
2
Bardzo podoba mi się ta odpowiedź. Dzięki dedykowanemu działowi kontroli jakości stosunek defektów regresji do nowych defektów jest bardzo prosty do obliczenia i na pewno może wiele powiedzieć o zadłużeniu technicznym.
Erik Dietrich
4

Myślę, że pytanie brzmi, ile kosztowałoby „odkupienie” długu technicznego - to znaczy ile pracy to naprawia? Cóż, zespół musi to ustalić.

Podczas planowania sprintu proszę zespół, aby oszacował złożoność naprawy pozycji długu technicznego w taki sam sposób, jak oszacowałby złożoność historii użytkownika. W tym momencie jest to gra negocjacyjna między zespołem a właścicielem produktu, mająca na celu ustalenie, który dług techniczny ma wystarczająco wysoki priorytet, aby zrobić go w bieżącym sprincie (wypieranie faktycznych historii użytkowników) i co może poczekać.

Jeśli nie robisz scrum, trzymałbym się mojej przesłanki - dług techniczny powinien być mierzony kosztem środka zaradczego.

Matthew Flynn
źródło
Czy w kontekście punktów opowieści można uczciwie powiedzieć, że można dodać kilka punktów do każdej opowieści, jeśli wysoki poziom zadłużenia reprezentowany przez dotknięte obszary kodu jest wysoki? Oznacza to, że jeśli historia X wymaga dodania do elementu Y kodu, co jest po prostu okropne, podchodzisz do kilku punktów tej historii, szczególnie ze względu na naturę Y? A ta liczba punktów jest taka sama lub związana z liczbą punktów, aby wykonać poprawkę, o której wspominałeś?
Erik Dietrich,
1
@Erik Dietrich - Cóż, TD zdecydowanie zwiększa złożoność rozwiązania. Trudność może polegać na tym, że ustalanie fragmentarycznych TD może być bardziej kosztowne niż rozwiązanie hurtowe. Może się zdarzyć, że masz 3 historie, które zostałyby ocenione na 5, jeśli niszczono by niszczyciel czołgów, ale każdy ma 8 z zadłużeniem - co daje w sumie 9 punktów niszczenia. Zadanie naprawienia TD jako całości (niezależnie od historii) może być w rzeczywistości 8. Można więc argumentować, że hurtowe rozwiązanie kosztuje mniej (8) niż fragmentaryczne (9). Byłoby to częścią negocjacji
Matthew Flynn
To ma sens. I z pewnością chcę uzyskać (w pewnym sensie) obiektywny przypadek, aby powiedzieć coś w stylu „w ciągu jednego roku, możemy opracować X nowych funkcji, jeśli tylko będziemy orać dalej, ale nowe funkcje X + Y, jeśli spłacić część długu technicznego ”.
Erik Dietrich,
2

Istnieje dość silna platforma o nazwie CASTszukać długu technicznego w dużych aplikacjach. Wykorzystaliśmy go w projekcie, w którym przejęliśmy duże ulepszenie starszego systemu. Nie mówi ci, co było w głowach ludzi, którzy napisali kod, ale bada kod i wykrywa błędy w kodzie i architekturze, a następnie określa kwotę długu technicznego, jeśli chcesz. Prawdziwym zastosowaniem do tego nie jest jednak kwota $, ale lista problemów już zawartych w kodzie. To mówi ci o części twojego długu technicznego (więc nie zgadzam się z niektórymi odpowiedziami powyżej). Istnieje pewien dług techniczny, który opiera się wyłącznie na projektowaniu i jest bardzo subiektywny - jak pornografia - znasz go, kiedy go widzisz i znasz kontekst. Spierałbym się, czy to naprawdę „techniczny” dług. Jest pewien dług techniczny, który jest wyłącznie realizacją i wierzę, że „

Leonhard
źródło
Udostępniłem to pytanie na Twitterze, a ktoś odpowiedział, mówiąc o CAST. Nie jestem do końca jasne, co to wszystko robi po sprawdzeniu ich strony internetowej. Czy jest jakaś wersja bezpłatna lub demo, którą można wziąć na jazdę próbną?
Erik Dietrich
2

Oto seminarium internetowe z MIT opisujące badania długu technicznego w dużych systemach oprogramowania: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Autorzy napisali kod do analizy projektu i wyciągnęli wskaźniki „złożoności architektonicznej”. Wykazano, że wskaźniki te mają silny związek z gęstością defektów, produktywnością programistów i rotacją personelu programistycznego.

Praca opisana w webinarium opiera się na badaniach modułowości przeprowadzonych przez Alana MacCormacka i Carlissa Baldwina z Harvard Business School. Spojrzałbym również na ich papiery. Ich „koszt rozmnażania” może być tym, czego szukasz.

użytkownik94203
źródło
1

Powiedziałbym, że standardowe miary kodu można wykorzystać jako względne spojrzenie na zadłużenie techniczne na wysokim poziomie . VS Ultimate zawiera analizator kodów, który da ci „Indeks utrzymania” oparty na złożoności cyklicznej, sprzężeniu, LoC i głębokości dziedziczenia. Możesz zanurkować w dowolne miejsca problemów i zobaczyć szczegóły (aż do poziomu funkcji). Właśnie uruchomiłem go w moim projekcie, a najniższe wyniki, jakie otrzymaliśmy, wyniosły 69 w naszym pakiecie danych (konfigurowanie i inicjowanie EF) i naszym pakiecie testowym. Wszystko inne miało 90 lat lub więcej. Istnieją inne narzędzia, które dadzą ci więcej wskaźników, takich jak omówione w PPP wuja Boba

Michael Brown
źródło
Powiedzmy, że masz coś, czego nie ma w pakiecie testowym lub pakiecie danych, który uzyskał wynik poniżej 90. Czy masz tam próg liczbowy, w którym mówisz „w porządku, to nie wystarczy, a my dokonamy refaktoryzacji”? Czy wykorzystujesz te informacje, aby uzasadnić dla kierownictwa lub jakiejś zainteresowanej strony, że konieczna jest refaktoryzacja? To znaczy, czy menedżerom / interesariuszom zależy na indeksie konserwacji Microsoft, czy przedstawiasz te informacje w inny sposób? A może po prostu go nie prezentujesz i po cichu samodzielnie rozwiązujesz problem?
Erik Dietrich,
Uwielbiam to pytanie. Moja odpowiedź zawsze będzie taka, że ​​napisanie najlepszego możliwego kodu nie jest czymś, o co prosi się o pozwolenie. Używam tego, co wujek Bob nazywa „regułą boyscouta” (zawsze pozostawiam kod w lepszym stanie niż w momencie przybycia) i nazywam refaktoryzację oportunistyczną. Chodzi o to, że gdy musisz zmodyfikować istniejący kod, poświęć czas na a) omówienie go w testach jednostkowych b) przefiltruj go, aby był czystszy. Michael Feathers skutecznie współpracujący ze starszym kodem zapewnia pewne wskazówki, jak to zrobić.
Michael Brown
@ Mike-That spowoduje zwolnienie z pracy w wielu środowiskach programistycznych, w których ścisła kontrola wszystkich zmian kodu jest śledzona i monitorowana. Zwłaszcza jeśli twoja z pozoru niewinna poprawa, której nikt ci nie powiedział, doprowadziła do zepsucia czegoś, co kiedyś działało.
Dunk
Zauważ, że nie powiedziałem, żeby się zanurzyć i nie chcąc porządnie wyczyścić kodu. Powiedziałem, aby wyczyścić kod, nad którym już pracujesz. Pracowałem również z kodem o wysokim stopniu regulacji (otrzymaj element pracy, musisz podać listę zmian wprowadzanych w celu zaadresowania elementu pracy do zatwierdzenia, wykonaj zatwierdzone zmiany ). 9/10 razy wyjaśnienie refaktoryzacji we wniosku o zmianę spowoduje zatwierdzenie.
Michael Brown
0

Nie uważałbym długu technicznego za dolary, w których potrzebujesz wymyślnego modelu do jego oszacowania. Uważałbym to za przysługę. Jeśli ktoś wyświadczy ci przysługę i prawdopodobnie zapomnisz, zapisz ją. Kiedy zrobisz skrót, zapisz go. To pomaga ci pamiętać, a bardziej bezsilne zmusza cię do uznania tego. Nie jest potrzebne żadne wymyślne narzędzie. Notatnik lub Ecxel mogą załatwić sprawę.

MathAttack
źródło
2
Z perspektywy realpolitik argumentowałbym, że ludzie, którzy są najbardziej skłonni do poniesienia zła w perspektywie krótkoterminowej z powodu krótkoterminowych rezultatów, to prawdopodobnie również osoby najmniej skłonne do udokumentowania swoich decyzji. Tak więc zgadzam się z twoim pomysłem w teorii, ale myślę, że seryjni „żądający łaski” byliby najmniej skłonni do śledzenia równowagi przysług.
Erik Dietrich,
@ErikDietrich - Zgadzam się. A gorsze seryjni przestępcy nawet nie wiedzą, że zwiększają swój dług. (Podobnie jak w przypadku najgorszych przestępców kart kredytowych miażdżących swoje oceny wiarygodności kredytowej). Punktem wyjścia jest jednak chęć dokonania oceny ilościowej, a autorowi trudno jest ją oszacować. Nie wiesz, gdzie jest kupa, chyba że to twój pies, lub zdarzyło ci się w nią wejść.
MathAttack
0

Pracuję dla firmy, która dokładnie się tym zajmuje. Poniżej znajdują się 3 przydatne wskaźniki, które zalecamy wziąć pod uwagę przy rozwiązywaniu problemów technicznych. Aby uzyskać więcej informacji na temat tego, jak i kiedy je śledzić, przygotowaliśmy artykuł podsumowujący 3 Metryki, aby zrozumieć i poradzić sobie z długiem technicznym .

Jakie są Twoje myśli? Z przyjemnością odpowiemy na wszelkie pytania i chętnie usłyszymy Twoją opinię :).

Własność zapobiegająca wadom i niechcianym zadłużeniu technologicznemu

Własność jest wiodącym wskaźnikiem zdrowia inżynieryjnego.

Części bazy kodowej otrzymujące datki od wielu ludzi gromadzą się z czasem w złocie, podczas gdy osoby otrzymujące datki od mniejszej liczby osób są zwykle w lepszym stanie. Łatwiej jest utrzymać wysokie standardy w ciasnej grupie, która jest dobrze poinformowana o swojej części bazy kodu.

Daje to pewną moc predykcyjną: słabo posiadane części bazy kodowej mogą z czasem narastać zadłużenie i stają się coraz trudniejsze do pracy. W szczególności prawdopodobne jest, że dług zostanie przypadkowo przejęty , po prostu jako efekt uboczny niekompletnych informacji i osłabienia własności jakości kodu.

Jest to nieco analogiczne do tragedii społeczności .

Spójność w celu poprawy architektury

Spójność jest końcowym wskaźnikiem dobrze zdefiniowanych składników.

Spójność i jej odpowiednik, sprzężenie, od dawna są uznawane za ważne koncepcje, na których należy się skupić przy projektowaniu oprogramowania.

Mówi się, że kod ma wysoką spójność, gdy większość jego elementów należy do siebie. Wysoka kohezja jest generalnie lepsza, ponieważ wiąże się z łatwością konserwacji, wielokrotnego użytku i solidnością. Wysoka kohezja i luźne sprzęganie zwykle idą w parze.

Oprócz kojarzenia z kodem wielokrotnego użytku i łatwym w utrzymaniu, wysoka spójność minimalizuje również liczbę osób, które muszą być zaangażowane w modyfikację danej części bazy kodu, co zwiększa produktywność.

Odejdź, aby zidentyfikować problematyczne obszary

Odejście (powtarzane działanie) pomaga zidentyfikować i uszeregować obszary dojrzałe do refaktoryzacji w rosnącym systemie.

W miarę rozwoju systemów deweloperom coraz trudniej zrozumieć ich architekturę. Jeśli programiści będą musieli zmodyfikować wiele części bazy kodu w celu dostarczenia nowej funkcji, będzie im trudno uniknąć wprowadzenia efektów ubocznych prowadzących do błędów i będą mniej produktywni, ponieważ muszą zapoznać się z większą liczbą elementów i koncepcji.

Dlatego ważne jest, aby dążyć do pojedynczej odpowiedzialności, aby stworzyć bardziej stabilny system i uniknąć niezamierzonych konsekwencji. Chociaż niektóre pliki są centrami architektonicznymi i pozostają aktywne po dodaniu nowych funkcji, dobrym pomysłem jest pisanie kodu w sposób, który zapewnia zamknięcie plików oraz rygorystyczne przeglądanie, testowanie i obszary ubijania QA.

Churn wyświetla te aktywne pliki, abyś mógł zdecydować, czy powinny zostać one podzielone, aby zmniejszyć pole zmian w bazie danych.

Stefanie
źródło
-1

Jeśli masz dobrą historię za pomocą narzędzia do śledzenia błędów lub jakiegoś zwinnego oprogramowania, możesz to uprościć. Czas spędzony na wykonaniu podstawowych zadań. Również wiarygodność szacunków, kiedy projekt był młody w porównaniu z obecnym.

Erik Reppen
źródło