Dzień dobry
Jestem początkującym programistą. Mam dwa kody źródłowe i chciałbym je porównać pod względem jakości. Za pomocą jakich metod mogę tego dokonać ?
0
0
Najważniejszą metryką jest CRAP: http://www.artima.com/weblogs/viewpost.jsp?thread=215899
Duży wskaźnik CRAP oznacza, że kod jest gówn... tzn. zmiany w takim kodzie są ryzykowne, bo jest słabo pokryty testami.
0
Co powinienem wiedzieć na temat tych metryk ? Najważniejsze rzeczy czy wszystko ? Mam rozumieć, że metryki to złożoność obliczeniowa, ilość linii kodu, liczba tokenów, liczba linii komentarzy, duplikowane linie kodu, zduplikowane pliki.
2
Jedyna prawdziwa metryka to:
http://mbaranowski.pl/wp-content/uploads/2012/09/wtf.png
A te podane wyżej to takie teoretyczne dywagacje ;) Poza tym nie są tak skomplikowane żeby nie dało sie ich ogarnąć ;]
Ale to co powinno cię interesować:
- cyclomatic complexity
- rozmiary klas i metod
- pokrycie sensownymi testami (tzn testami jednostkowymi a nie że ktoś odpala jedną metodę która robi kaskadę wywołań przez pół projektu i potem mówi ze ma 70% pokrycia tym jednym testem :P)
- dokumentacja publicznego API
0
Jestem początkującym programistą. Mam dwa kody źródłowe i chciałbym je porównać pod względem jakości. Za pomocą jakich metod mogę tego dokonać ?
Musisz znać dobre praktyki programowania. Jeśli jesteś dobrym programistą, samemu piszesz dobry, czytelny i optymalny kod, rozpoznasz taki kod u innych osób.
Inaczej będziesz błądził we mgle. Polecam książkę "Czysty kod" :) Albo ogólne czytanie o wzorcach, dobrych i złych praktykach itp.
Ale na pewno złe praktyki to chociażby programowanie typu kopiuj-wklej (czyli te zduplikowane linijki kodu), albo nieumiejętność dzielenia programu na podmoduły (czyli napisanie funkcji, która ma z 200 linijek kodu - jak zobaczysz coś takiego, to na 90% możesz od razu założyć, że coś jest nie tak. Normalnie powinno się wydzielić jakieś mniejsze podfunkcje), czy np. łączenie kilku różnych warstw aplikacji - np. mieszanie logiki z widokiem (nagminne wśród zaczynających PHPowców, chociaż pewnie nie tylko), albo brak decouplingu (decoupling to niezależność poszczególnych części od siebie. Nie zawsze da się to wykonać, ale warto dążyć do tego, żeby klasy, funkcje czy moduły były w miarę od siebie niezależne, żeby nie bylo tak, że chcesz zmienić coś w jednym module/klasie, a posypie się cały program. Zmiennych globalnych też raczej powinno być mało, chociaż czasem nie da się uniknąć zmiennej globalnej (ale uwaga - tzw. singletony to również zmienne globalne).
liczba linii komentarzy
Im mniej tym lepiej. Kod powinien sam się komentować. Oczywiście w pewnych sytuacjach trzeba dać komentarz, ale generalnie to z kodu powinno wynikać co program robi (odpowiednio nazwane zmienne, metody, klasy, pliki, odpowiedni przepływ sterowania itp.)
4
Największy problem z ilościowymi metrykami jest taki, że niektórzy (słabi) programiści, znając algorytm oceny kodu, próbują ograć system i otrzymać odpowiedni wynik, zamiast skupić się na pisaniu dobrego kodu. Np. nie jest trudno uzyskać wysokie pokrycie testami, które.... nic nie testują. Albo nie jest trudno uzyskać dowolnie niski współczynnik złożoności cyklomatycznej przez mechaniczne stosowanie "extract method". Tyle, że kod wcale od tego nie staje się lepszy. Oczywiście metryki też nie sprawdzają bardzo wielu aspektów kodu, np. nazewnictwa, poprawności doboru algorytmu do problemu, stopnia skomplikowania rozwiązania w stosunku do stopnia skomplikowania problemu itp.
No i metryki potrafią być up****iwe jak np. są powiązane z akceptacją commita.
Jedyną sensowną metryką jest code-review i pomiar liczby WTFów rzucanych przez recenzujących. Oczywiście działa tylko jeśli recenzenci są na odpowiednio dobrym poziomie, bo słabi recenzenci nie zauważają WTFów.
1
Popieram przedmówcę ^
Ocenianie kodu po metrykach jest jak ocenianie kobiet po rozmiarze miseczki ...
Metryki mogą sygnalizować problem jest nie są żadną wyrocznią. Nadmierne zawierzenie nim prowadzi do absurdów typu:
- pisanie bezsensownych komentarzy nie wnoszących nic do czytelności kodu
- pisanie testów jednostkowych do rzeczy których nie da się przetestować jednostkowo, a jedynie integracyjnie (konfiguracja systemu w np. Java Config, łączenie się do zewnętrznego systemu)
PS. Z chwilą gdy powstaną metryki, które potrafią rzetelnie ocenić dług techniczny, programowaniem będą mogły już się zajmować komputery.