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).
Tudod, hany kodot lattam mar, amiben tobbtucatnyi sonar hiba volt, es gyonyoruszep commit, ment is a merge, es hany olyat, amelyikben nem jelzett hibat, de egy okadek fos hanyas volt? Pont ez a baj, ha valaminek 90% a fals pozitiv aranya, es semmi olyat nem ellenoriz, ami tenylegesen a kodminoseg jelzoje lenne, akkor az olyan szinten megbizhatatlan, hogy kar is idot tolteni vele.
Az egyetlen megbizhato (es gyors/egyszeru) code review az, amikor leultok ketten es vegigmentek a changeset-en.
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).
Nem egy unused variable -tol lesz rossz a kod. Hanem pl. amikor jon az OO-agyu user, es elkezdi mixelni az adatmodellt a business logic-kal, teleszorja a kodot getter/setter-rel total feleslegesen, amikor nem veszi eszre, hogy tobb szalon fer hozza egy nem thread-safe adathoz (vagy forditva). A legdurvabb eddig az volt, amikor egy .clone() metodust ugy oldott meg egy dev, hogy serializalta json-be, es visszaszerializalta utana. Persze tokeletes kod sonar szerint...
De attol is falnak lehet rohanni, amikor jon a felrekonfiguralt IDE-jevel, es a changelog fele import auto-rearrange.