Meg nem talalkoztam senior/expert szintu dev-vel, aki hasznosnak talalta volna ezeket.
Szerintem meg pont ez a rossz hozzáállás. Igenis sok problémát tud megtalálni, bármekkora tapasztalata is van az embernek. Aki ezzel nem ért egyet, az küldje rá a Sonar-t a kódjára, és majd meglátja, hogy mennyi issuet talál. És igen, a találatok 90+ százaléka fals pozitív lesz, de ennek az egésznek az a lényege, hogy a munkafolyamat része a sonar check (vagy ugye bármilyen másik SCA/SAST megoldás), és amikor jelez, akkor egyből el kell dönteni, hogy javítani kell, vagy lehet ignorálni. És ha csak 1-1 bug-ot hamarabb meg lehet találni vele, vagy segít a kódminőséget jobbá tenni, akkor már megéri. Amúgy általában egy fejlelsztőcsapat eltérő képességű emberekből áll és igenis segít, hogy nem csak a code review-n múlik, hogy milyen minőségű kód kerül a kódbázisba, ráadásul tudjuk, hogy a code review minősége is tud igencsak hullámzó lenni (finoman szólva).
update: illetve van egy borzaszto feature-e a static code analysis-nek: raijeszt szegeny kezdo dev-re. Ugye van a szokasos 'unused variable' meg hasonlo hasznavehetetlen warning-ja, ez meg OK, bar szegeny junior dev ilyenkor jol nekiall kiirtani az adatmodellt, amihez epp irjuk a kodot :P, de a durvabb, amikor ilyen okossagokat nyog be, hogy 'reassigned variable', vagy hasonlo, error prioritassal. Megprobal okoskodni, kitalalni, hogy de az az algoritmus ott hibas. Barmilyen primitiv, 3 if es 1 while ciklus jellegu kod blokkba bele tud kotni random modon, mondvacsinalt indokkal, szegeny kezdo dev meg hisz neki, es aztan rohangal hozzam, hogy mi a baj (semmi). Na ezert talalom irritalonak oket.
Ez megint félreértése az egésznek. Egyrészt igaza van, nem merge-ölünk félkész kódot a mainre, teljesen jogos, hogy unused variable-re sikít. Elég nagy baj, ha két különböző task között az interface egy variable... A SQ-nak (illetve bármilyen más static code analyzernek is) pont az a lényege, hogy nem engedjünk rossz minőségű kódot merge-ölni, a mainen alapvetően mindig olyan kódnak kellene lennie, amit release-elni lehet, amibe nyilván nem fér bele a félkész kódból adódó warningok. Azt, hogy neked mi számít jó minőségű kódnak, azt neked kell beállítani, nincs one-size-fits-all solution, a quality gate-eket úgy kell beállítanod, hogy csak azokat a szabályokat használja, amik a te projekted számára hasznosak (pl. lehetnek coding style eltérések, vagy olyan szabályok, amivel nem értesz egyet).
De ami az igazan gaz, hogy szegeny junior dev-et rossz iranyba tereli. Ahelyett, hogy programozni tanitana, tippeket adna, raijeszt hibas/mondvacsinalt dolgokkal. Nem egy dev-et lattam mar iranyt teveszteni a 80-as evek pedantic OO java vilagaba a static analysis tool-ok 'tanacsai' miatt. Rigolyakat tanit ugyanis, dinamikus, funkcionalis programozas helyett.
A SonarQube-ot is a helyén kell kezelni, nem ebből kell megtanulni programozni, de segít rámutatni azokra a kritikus pontokra, amik hibákat rejthetnek. A juniorok terelése meg a senior fejlesztők dolga lenne egyrészt a saját példájukon, másrészt meg code-review-k/design review-k során.