Automatyczna weryfikacja jakości – jak to zrobić?

Być może po przeczytaniu tekstu o jakości (Czym jest jakość oprogramowania) przyszedł Ci do głowy pomysł, aby w swoim projekcie wprowadzić jakieś narzędzia badające różne aspekty jakości w sposób automatyczny. Jeśli tak, to super! Bo właśnie to powinieneś zrobić. Niestety jednak same dobre chęci nie wystarczą. W poniższym tekście pojawi się kilka rad i pomysłów jak to zrobić dobrze.

Zakładając, że chcesz wdrożyć narzędzie typu Checkstyle, Stylecop, FXCop, FindBugs, Sonar czy coś podobnego w projekcie już istniejącym, prawdopodobnie bardzo szybko napotkasz jeden istotny problem. Po pierwszym uruchomieniu narzędzia okaże się, że wykrytych błędów / ostrzeżeń / rad… jest mnóstwo! Zależnie od rozmiaru projektu będzie ich pewnie od kilkuset do kilkuset tysięcy – tak czy siak zdecydowanie za dużo, żeby przejrzeć dokładnie tą listę i wszystko naprawić. (Przy okazji warto wspomnieć, że nie ma nic gorszego niż odpalenie takiego narzędzia i naprawianie problemów w sposób niedokładny, pobieżny i niemalże mechaniczny – bez testowania i zastanowienia. Pamiętaj, że w tym wszystkim chodzi o poprawę jakości a nie powiększenie ryzyka!)

Co więc zrobić? Chcemy aby wszystkie istniejące pliki w projekcie, w których nasze narzędzie znajdzie jakiś błąd trafiły na listę obiektów do ignorowania przy analizie! Ignorowania? Tak! Pierwszy krok, to napisać skrypt (w bashu, powershellu, pythonie, perlu czy czymkolwiek innym), który wygeneruję taką listę plików do ignorowania. Następnym zadaniem jest znalezienie sposobu zastosowania takiej listy w programie analizującym. Jest to moim zdaniem jedyny sensowny sposób aby zacząć, bo nie wprowadzamy żadnych zmian w kodzie naszego systemu – a jak wiadomo zmiany to ryzyko. Chciałbym wyraźnie zaznaczyć, że nie chodzi nam tu o regułę „ignoruj pliki o nazwie pasującej do .*”, tylko o wymienienie nazw wszystkich istniejących plików. Każdy nowy plik/element ma już być kontrolowany od samego początku. Ta lista do ignorowania będzie w przyszłości zmniejszana – to znaczy będziemy chcieli usuwać z niej coraz więcej elementów, ale to dopiero później!

Drugi krok, to zintegrowanie sprawdzania z systemem budowania. Jeśli masz już ciągłą integrację to super – zapewne dodanie tam dodatkowe kroku nie będzie trudne. Jeśli nie, to sprawa może być lekko bardziej skomplikowana i znów wymagać pisania jakiegoś skryptu – ale przecież jesteś programistą, więc to chyba nie problem. Wszystko powinno działać tak, że jeśli wykryto jakikolwiek problem/naruszenie zasad to kompilacja jest przerwana i generowany jest raport wysyłany e-mailem do zainteresowanych, tak aby poprawić błędy. Ten krok umożliwia regularne stosowanie narzędzia i znów jest niezbędny do osiągnięcia sukcesu. Jeśli co jakiś czas będą szły bokiem jakieś „buildy” zrobione ręcznie bez sprawdzenia, to wszystko prędzej czy później (prędzej!) się rozjedzie.

Konsekwencją drugiego kroku jest to, że każdy programista przed zapisaniem zmian w systemie kontroli wersji powinien myśleć o jakości. Żeby mu to ułatwić potrzebna jest kolejna rzecz – możliwość wygodnego (najlepiej w ramach IDE) uruchamiania narzędzia kontrolnego na wybranych plik z dokładnie tymi samymi regułami co w „prawdziwych buildach”. Chodzi o szybką i wygodną metodę sprawdzenia czy wszystko jest dobrze. Co więcej, część IDE oferuje możliwość automatyczne poprawiania typowych błędów i problemów. Ważne aby rozpropagować w zespole takie ustawienia IDE, które są zgodne z wprowadzonymi zasadami kontroli – czyli, żeby IDE automatycznie nie generowało nowych problemów.

Po tych krokach możemy przejść do etapu testowania reguł. Ponieważ tylko nowe pliki w projekcie będą poddawane kontroli musimy poczekać trochę aż coś nowego będzie się pojawiać. Na pewno jednak dość szybko okaże się, że część reguł jest notorycznie łamana przez programistów i sporo „buildów” jest przez to zepsutych. Po kilku takich sytuacjach warto usiąść i przeanalizować sprawę. Trzeba wybrać jedną z możliwości:

• reguła jest zła i trzeba ją globalnie wyłączyć,
• reguła jest dobra i trzeba poprawić dany problem i nauczyć się więcej go nie popełniać,
• reguła ogólnie jest dobra, ale w danym wyjątkowym przypadku należy ją pominąć (większość systemów daje takie możliwości – chociażby przez użycie odpowiedniej annotacji/atrybutu).

Jeśli zdecydujemy się na zmianę konfiguracji narzędzia przez wyłączenie jakiejś reguły lub zmianę jej działania, musimy koniecznie wykonać (za każdym razem gdy się to dzieje!) dodatkowy krok. Otóż znów trzeba napisać kilka sprytnych skryptów, które wezmą obecną listę ignorowanych plików, wyłączą ją na chwilę, przeanalizują projekt i sprawdzą czy czasem któryś z ignorowanych plików nie przechodzi już wszystkich weryfikacji pomyślnie (co jest możliwe jeśli zmieniliśmy reguły). W ten sposób lista ignorowanych plików może się zmniejszać wraz z dostosowywaniem reguł. Niesamowicie ważne jest, aby opracować tą część planu w formie skryptów a nie ręcznej pracy! Jeśli będzie to się wiązało z jakimkolwiek mozolnym, ręcznym sprawdzeniem czegoś… to po prostu nie będzie robione! Ponownie – pamiętaj, że chodzi nam o poprawę jakości, a to uda się tylko wtedy jeśli reguły będą ewoluować a list ignorowanych obiektów będzie maleć.

Ostatnim krokiem jest podjęcie ukierunkowanego i konkretnego wysiłku, żeby naprawić wszystkie „starocie”, które mimo wcześniejszych działań nie chciały zejść z „listy ignorancji”. Na pewno nie będzie to łatwe i na pewno nie warto próbować zrobić tego za szybko. Co więcej, koniecznie trzeba podzielić to zadanie na kawałki i skorzystać z dobrodziejstw różnego rodzaju testów, żeby nie okazało się, że w imię walki o jakość wprowadzamy masę nowych błędów funkcjonalnych (lub jakichkolwiek innych). Warto również pomyśleć o priorytetach – nie wszystkie błędy / naruszenia reguł są równie ważne. Podobnie z ryzykiem – poprawienie niektórych rzeczy jest trywialne (np. zmiana formatowaniu kodu), z kolei w innych przypadkach dokładne zrozumienie problemu może zająć czas i rodzić wiele ryzyk. Dlatego nigdy nie myśl o tym zadaniu jako o definitywnej konieczności. Lista ignorowanych plików wcale nie musi zniknąć całkowicie. Być może masz w projekcie jakiś obszar bardzo starego kodu, który działa i bardzo rzadko się zmienia. Być może jest brzydki, zawiera mnóstwo dziwnych konstrukcji i niejednorodny styl itd. Nie zawsze jest sens cokolwiek z tym robić!

Podsumowując – cały proces wdrożenia narzędzia (czy narzędzi) monitorujących jakość naszego rozwiązania może być dość czasochłonny i złożony. Jeśli zaplanujemy to dobrze, to już niemal od samego początku będziemy mogli czerpać pewne (choć dość ograniczone) korzyści z takiego narzędzia, a dalej – wraz z rozwojem projektu – będzie tylko coraz lepiej. Jeśli jednak zaplanujemy wszystko źle lub nie zrobimy żadnego planu – to albo nie uda się nic zrobić, albo nie będzie w ogóle korzyści, albo koszta będą olbrzymie.

Na koniec chciałbym wspomnieć, że miałem okazję pracować w projekcie gdzie wdrożenie takiego narzędzia się udało i kod na bieżąco był badany i udoskonalany. Jest to naprawdę pomocna i cenna rzecz – znacznie ułatwia pracę! Co więcej jeśli mamy w firmie wiele projektów i jeden ustalony zestaw reguł dla wszystkich, to dużo łatwiej nam o przenoszenie ludzi między zadaniami i support rozwiązań. Jednym słowem… naprawdę warto to zrobić dobrze!