Statyczna analiza kodu, czy to ma sens?

Ostatnio się zajmuję statyczną analizą kodu i się nad tym zastanawiam. Czy to ma sens, gdzie jest ten sens i tak dalej.

Z jednej strony nigdy nie lubiłem statycznej analizy kodu.
Nawet jak w tamtym roku robiłem wtyczkę do SonarQube to prezentując ją zacząłem od stwierdzenia, że SQ używa się zwykle po to żeby development poczuł się lepszy, że proszę tak bardzo dbamy o jakość kodu. Że to głównie na pokaz, ale jakoś normalnie nie działa szczególnie dobrze.
Bo niby cala idea opiera się na całkiem rozsądnym założeniu, że jak kod jest "brzydki" i łamie pewne dobre praktyki to istnieje duże prawdopodobieństwo, że sam kod też ma błędy.
Nie działa to w drugą stronę, bo "ładny" kod wcale nie musi być bezbłędny, ale to nie jest aż tak istotne.
Problem w tym, że większość narzędzi jest po prostu bardzo głupia.

Może się np. rzucać, że nasz kod, który od 10 lat był pisany z całą możliwą miłością jaką mu można poświęcić, nie używa lambd. Bo ktoś uznał, że skoro gdzieś używam Runnable to zamiast interfejsu powinniśmy użyć lambdy, bo to poprawni czytelność kodu.
Może, i rzeczywiście tak może powinniśmy pisać teraz kod, ale skoro mamy fragment kodu, który działa od 10 lat i od tego czasu nie był zmieniany to czy użycie Runnable jest tu zbrodnią?

OK, można w takim przypadku dodać historię kodu i próbować wysnuwać wnioski z tego jak kod się w trakcie swojego życia zmieniał i np. nie rzucać się tak bardzo w przypadku czegoś co obecnie jest uznawane za brzydkie jeśli napisano to 10 lat temu i nigdy nie zmieniano.

Ale nadal ktoś musi na to wszystko spojrzeć i jak liczba issues które są uznane za Blockery wynosi ponad 2 tysiące sztuk to powstaje pytanie czy w ogóle warto.

Chociaż ciekawa sprawa, zagregowane dane w postaci "242 tysiące issues" i później miliony plików z błędami nie są zbyt pomocne, ale inspekcje w IntelliJ już zwykle są.

Tak na "chłopski" rozum masę rzeczy da się zautomatyzować.
Sam tu kiedyś wypisywałem code smellsy które wzbudzają moje podejrzenia w trakcie inspekcji kodu. Nie ufam np. protected, albo sytuacji gdy za dużo metod jest public.
Ale szybko się okazuje, że te takie łatwe strzały się kończą i jest o wiele trudniej.
Kiedyś w jednej z firm nasz architekt miał genialny pomysł, żeby użyć Prologa i wnioskowania do znajdowania akcji z menu które trzeba przetestować bo mogły być "zaafektowane" zmianami w kodzie.
Zrobiliśmy świetne narzędzie, które potrafiło na podstawie logów z historii wersji stwierdzić, które linie, a więc i które metody w klasach się zmieniły i znając strukturę kodu wskazać które opcje menu tego używają.
Ale w końcu narzędzie nie działało bo zbyt często pokazywało wszystkie opcje jako zaafektowane.
Problem nie był w toolu, ale w tym jak nasza aplikacja była napisana.

Znów w poprzedniej firmie zbudowałem narzędzia które na podstawie analizy skompilowanego kodu potrafiły odkryć gdzie tworzymy i przetwarzamy jeden z ponad 500 rodzajów komunikatów JMS, a inne na podstawie analizy zależności między projektami potrafiło powiedzieć i napisać plik do zrobienia clone'a z wszystkich niezbędnych repozytoriów.

Próbowałem jakoś zbudować coś podobnego w obecnej firmie i okazuje się, że nie ma to sensu. Tu mamy innego rodzaju problemy (mniejsze, to fakt :-)).
To co teraz próbujemy rozwiązać jest jeszcze innym rodzajem problemu i nie wiem czy analiza statyczna jest dobrym rozwiązaniem czy nie.... na razie jest pierwszym kandydatem ;-)

Podobne posty^beta
Moc wykresu.... Czyli jak wieść szczęśliwsze życie ;-)
Klasa statyczna - ki diabeł?;-)
Inercja i koło wielokrotnego wynajdywania, czyli radosne macki piekieł w kodzie [alem pojechał w tytule ;-)]
Jak walczyć z gigantycznym kodem w Java'ie, część 1.5 ;-) - czyli jak je się słonie ;-)
O tym czemu branche są złe...