Sonarqube megmondja...

Panaszkodott, hogy az SQL darabokbol van összeragasztgatva. Gondoltam, talán ha lát egy replaceAll-t, megbékül. De sikerült?!

stmt = con.prepareCall("begin " + Connector.getDBSchema().replaceAll("[\\W]", "_")
                    + ".packagename.functionname(?,?,?,?,?,?,?,?);end;");

De mivel rendes hozzám a szoftver, elmagyarázza, hogy azért vannak a bind-változók, hogy használjuk őket. Csak jó dolog, ha valaki ilyen okos. (Gyk: például séma-, tábla- és oszlopnév helyett nem lehet bind változó.)

Szerk: Ennek a szabálynak a száma S2077, írja is valahol, hogy nem valami kifinomult szabály, az S3649 okosabb, csak az nem ingyenes.

Hozzászólások

Előfordul, hogy túlreagálja a dolgokat. Ilyenkor # NOSONAR

Code review alkalmával úgy gondolom, hogy a kódot átnéző félnek fel kell tűnjön ha túl sok és/vagy indokolatlan kivétel van a kódban. Ez minimum egy kérdést jelent, de ha tényleg indokolt a kivétel akkor megér akár egy hosszabb kommentet is a kódban a pontos indoklás. Így a későbbiekben mások is értesülnek róla.

Nyilván nem bolondbiztos a rendszer. :)

Nálunk minden PR-nál (legyen az app vagy infra kód) van code review, anélkül nincs merge, nincs kész a munka. Közepes méretű, nemzetközi a csapat, vegyes tudásszinttel, gyakornoktól kezdve egészen senior fejlesztőkig van minden. Nem mondom, hogy nem csúsznak át hülyeségek, mert mint említettem, nem bolondbiztos a rendszer, de működik a megosztott felelősség, odafigyelünk egymás kódjára.

Később sem lehet olyan, hogy hirtelen hozzádcsapódnak emberek/csapatok, akik ilyet csinálnak, illetve természetes fluktuáció sincs, nem jön egyik pillanatról a másikra ilyen, sőt: az emberek mindig ugyanazt a minőséget hozzák, sosem tévednek. Jó lehet egy ilyen ideális világ!

Magatol eleg ritkan szokott bezuhanni a szakmai szinvonal egy csapatban, azert valakinek dolgoznia kell.

Egyebkent mi a konkluzio? Ne hasznaljunk toolokat, mert lehet, hogy kesobb hulye emberekkel kell egyutt dolgozni? A Sonar meg tarsai nem csodafegyver, nem gondolkodik helyetted, de ettol meg tud hasznos lenni. Nyilvan ebbol is lehet olyan kerdest csinalni, mint a test coverage-bol, hogy legyen meg a 100% coverage, mert az KPI, amugy meg egyetlen ertelmes test case sincsen.

Tapasztalataim szerint pedig amikor bővül a cég, és újabb csapatok esnek be, akkor hirtelen megváltozik a színvonal is. Legtöbbször negatív irányba sajnos.

Szerintem te nem ismered fel a szarkazmust, pusztán ironikus reagálás volt részemről a NOSONAR-ra az egész, itt meg mindenki ráfeszült az én vélt (vagy valós) dilettantizmusomra.

itt meg mindenki ráfeszült az én vélt (vagy valós) dilettantizmusomra.

Ha igy van, nem volt szandekos, sorry. :)

A fentit sem koltoi kerdesnek szantam, nemreg egy orat beszeltem valakivel static analysis eszkozokrol, es kb. hasonlo ive volt a beszelgetesnek, de ott sem derult ki, hogy akkor hogy lenne jobb. Oke, a lusta kollegak megkerulik a Sonart, ahelyett, hogy megneznek, mik a valos problemak (igen, sok a fals pozitiv talalat), es azokat kijavitanak. De akkor mi legyen helyette? Emiatt rugjuk ki oket? Nem tulzas az? :)

Szerintem az alapvető probléma ez: „When a measure becomes a target, it ceases to be a good measure.”

Tök jó a Sonar, abszolút hasznos eszköz lehet code review során. De amint direkt lépéseket teszel, hogy csökkentsd a számokat, már teljesen elszakad a statisztika a tényleges kódminőségtől. (Ez a problémám a NOSONAR-ral is, persze az nyilván kevésbé káros a kódminőségre, mint a fenti példa.)

Szerk: De visszaolvasva azt hiszem te is pont erre céloztál :)

A DB schema nem lehet implicit az SQL-ben, connection alapján? Mivel (látszólag) ez egy static call ezért feltételezem futásidőben már nem változik, akkor meg akár a connection is hozzá lehetne kötve. Ha csak nincs ugyanaz a connection más schemaval is használva.

De hát épp ezaz, a DB connection string része kéne, hogy legyen a schema, a kapcsolat felépülése után impliciten használva van.
PostgreSQL esetén például a currentSchema paraméter adja meg:

jdbc:postgresql://localhost:5432/mydatabase?currentSchema=myschema

És ez meg amúgy is konfigban van.

Hasonló, csak ez Oracle. Itt mondjuk 'hajocsavar' user-nek vannak táblái, eljárásai és egyéb objektumai, amelyek közül némelyikre adunk jogot az 'hcs-technikai' usernek. Az alkalmazás az utóbbival konnektál, de az előbbinek az okbjektumait használja.
Továbbá fontos kritérium, hogy egyik usernév se legyen hardkódolva, hogy pl.:

connect as ${TECHUSER}/${TECHPWD}@${DB}
execute ${IGAZIUSER}.procedurenev(?, ?, ?);

(Még rosszabb esetben a procedurenev is lehetne futásidőben konfigurálható.)