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.

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.

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

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.

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

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.

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 „

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.

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

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

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.

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.