Sonar Driven Development

Chyba każdy programista ma jakąś opinię na temat jakości oprogramowania. Tematyka ta jest bardzo złożona, gdyż jakość można oceniać z wielu różnych perspektyw:

  • Czy kod działa tak jak trzeba?
  • Czy jest dostatecznie czytelny?
  • Czy jest pokryty testami jednostkowymi?
  • Czy został poprawnie zaprojektowany?

Są to bardzo ogólne kryteria a przecież istnieje ich więcej. Z tego właśnie powodu bardzo ciężko jest arbitralnie określić, czym konkretnie powinien charakteryzować się wysokiej jakości kod. Jednym z podejść może być odrzucenie subiektywnych “odczuć”, na rzecz pomiarów odpowiednimi metrykami. Czy jednak takie podejście jest słuszne?

Na pierwszy rzut oka, wygląda to dość obiecująco. Wystarczy przyłożyć do naszego kodu odpowiednią “linijkę” i już wiemy, czy jakość jest wystarczająco wysoka. Życie pokazuje jednak, że rzeczy na pierwszy rzut oka łatwe, w praktyce mogą sprawiać dużo problemów.

Osobiście uważam, że metryki są ok, należy tylko pamiętać, że to kolejny młotek w naszej skrzynce z narzędziami. Do pewnych zastosowań się sprawdzi, do innych już nie. Nawet używając go zgodnie z przeznaczeniem, możemy się przejechać.

Po pierwsze warto wiedzieć co dana metryka tak naprawdę mierzy. Musimy sobie też uświadomić, co my byśmy chcieli, żeby mierzyła. Dzięki temu wiemy na ile rzeczywistość pokrywa się z naszymi oczekiwaniami. Przykładem może być metryka LCOM4, o której napiszę szerzej w najbliższym czasie. Teoretycznie – metryka ta służy do sprawdzenia, czy dana klasa jest spójna. Dzięki temu można  ocenić, czy spełnia zasadę Single Responsibility Principle. Ale tak naprawdę metryka ta mówi nam, czy dana klasa jest spójna, jeżeli przedstawić ją w formie grafu. Różnica jest taka, że LCOM4 po prostu określi, czy istnieje miejsce w którym możemy “przeciąć” klasę na pół tak, żeby dalej się kompilowało. Ale czy to zawsze oznacza niespójność z punktu widzenia SRP?

Warto wiedzieć, jak konkretnie działa dana metryka – optymalnie byłoby jeżeli umielibyśmy ją policzyć samodzielnie. Dzięki temu patrząc na wyniki możemy, np. ocenić czy mają one sens. Może się przecież zdarzyć, że narzędzie zawiedzie. Znajomość działania metryki ułatwi nam też późniejszy refactoring. Oczywiście trzeba pamiętać, żeby jego celem była poprawa jakości a nie tylko statystyk.

Dobrym pomysłem jest przeczytanie dokumentacji narzędzia do analizy. Powinniśmy sprawdzić, czy liczy ono wartość danej metryki w sposób “książkowy”, czy też może istnieją jakieś odstępstwa. Jeżeli narzędzie działa źle, to może zostać poprawione w niedalekiej przyszłości. Natomiast, jeżeli twócy narzędzia zdecydowali się świadomie zmodyfikować daną metrykę, to prawdopodobnie będziemy musieli z tym żyć.

Najważniejsze jest, żeby podchodzić do wyników analiz z pewnym dystansem. Warto pamiętać, że niekorzystne wartości metryk to jedynie sygnał, żeby przyjrzeć się danym fragmentom kodu. Działa to również w drugą stronę – wzorowe wartości nie gwarantują, że kod jest bez zarzutu.

Czasem bywa tak, że metrykami jest zainteresowany management, co może stanowić problem. Najgorzej jest wtedy, kiedy pożądane wartości metryk są “zaspawane” w kontrakcie. W tym momencie  projekt, nad którym pracujemy, zaczyna być prowadzony wg. metodyki Sonar Driven Development.

Jak już wcześniej wspomniałem, niekorzystne wartości metryk, to tylko wskazówka, ale jeżeli pracujemy pod dyktando wyników Sonara, to każde odstępstwo od normy musi być przez nas zlikwidowane. Gdy zaczynamy poprawiać miejsca, które tego nie wymagają to często musimy uciekać się do brzydkich hack’ów, które niewiele mają wspólnego z jakością.

Moim zdaniem, najgorszym problemem są możliwe zmiany w nastawieniu zespołu. Pewne praktyki można uznać, co do zasady, za słuszne. Ale tylko jeżeli stosuje je się z głową i w miejscach do których pasują. Natomiast jeżeli są one wymuszane, z zupełnym pominięciem kontekstu w którym się znajdujemy, to szybko można się do nich zrazić.

P.S. Początkowo chciałem zacząć od przedstawienia metryki LCOM4, jednak podczas pisania przyszło mi do głowy trochę ogólnych przemyśleń, które zawarłem w tym wpisie. Jako, że istnieje szansa powstania cyklu na temat metryk, to wydaje mi się, że tego typu (mam nadzieję) trzeźwe spojrzenie, może być całkiem niezłym wstępem.