Pl. "Java fejlesztő", "SAP tanácsadó", "Unix adminisztrátor"

IT blog
Szakmai tanácsok, új módszertanok, hogy napról-napra jobb fejlesztővé válhass.

7 hasznos tipp a kódminőség javítására

IT január 31. ITHub

Kódot írni könnyű, minőségi kódot írni annál nehezebb. Ezt mi sem bizonyítja jobban, mint hogy a “vadonban” valószínűleg sokkal kevesebbszer csattintunk elismerően egy kódbázis láttán, mint amennyiszer a hajunkat tépnénk a benne használt rossz megoldások miatt. Az alábbi posztunkban összeszedtünk néhány hasznos tippet, amelyek segíthetnek a magas kódminőség fenntartásában.

A kódot elsősorban munkatársainknak, nem pedig a compilernek írjuk

Az általad írt programkód legkomolyabb tesztje, hogy az elég egyszerű és átlátható-e ahhoz, hogy bármely munkatársad könnyen megértse. Ha ez nincs így, és azt veszed észre, hogy a kollégáid nehezen tudják kihámozni az általad kódról azt, hogy mit csinál tulajdonképpen, próbáld meg kideríteni, miért van ez. Lehet, hogy a megoldásod túl komplex, vagy túl kevés tesztet írtál hozzá, de akár az is előfordulhat, hogy egy közismert problémára a megszokottól eltérő algoritmust használtál. A kulcs ezeknek a problémáknak a feltárására és megoldására a folyamatos párbeszéd.

A probléma, amit te fedezel fel, a tiéd

Ha a mindennapi munkádban felfedezel valamilyen hibát vagy szuboptimális megoldást, attól a ponttól a te saját felelősséged, hogy javíts a helyzeten. Természetesen ez egyáltalán nem azt jelenti, hogy azonnal változtatásokat kell eszközölnöd, ez már az adott problémától függ. Lehet, hogy elég egy bejegyzés egy bug-adatbázisban, lehet, hogy elég, ha megemlítjük munkatársainknak. A lényeg, hogy a legrosszabb, amit tehetünk ebben az esetben az, ha csendben maradunk.

Ne akarj túl okos lenni!

Egy fontos szabály: az “okos” kód általában rossz. Ne használj kriptikus, nehezen átlátható megoldásokat csak azért, hogy megmutasd, mennyire okos és szellemes vagy. A kulcsszavak az egyszerűség és az átláthatóság.

A követelmények nincsenek kőbe vésve

Mérnökként, fejlesztőként kötelességed, hogy megkérdőjelezz egy esetleges követelményt, ha az számodra nem teljesen világos, vagy értelmezhetetlen, zavaros. Nem robotok vagyunk, akik vakon implementálják az üzleti követelményeket, mindig próbáljuk megérteni, mit akar pontosan a másik fél elérni, és segítsük őt technikai szakértelmünkkel!

Itt azért fontos megjegyezni, hogy vannak, akik nem szeretik az ilyesfajta megkérdőjelező magatartást, így ebben az esetben fontos lehet a diszkréció – nem kell mindezt feltétlenül nyilvánosan tennünk.

Kezdj a “Miért?”-el!

A “vision” és a “big picture” eléggé elnyűtt, menedzserek szájából gyakran elhangzó szavak, azonban ahogy mondani szokás: nem zörög a haraszt, ha nem fújja a szél. Amikor egy projekten dolgozunk, próbáljuk a saját részterületünkön túl is megérteni, hogy miért is készítjük az adott szoftvert, milyen problémát és ki(k)nek oldunk meg vele.

Sokszor ha egy-egy nagyon specifikus probléma mélységeiben járunk, könnyen szem elől téveszthetjük ezt a bizonyos “miért”-et. Ezekben a pillanatokban érdemes egy kicsit magasabbról szemlélni a dolgokat, és végiggondolni a fentebb taglalt kérdéseket.

A “miért”-et persze legtöbbször nem mi magunk fogalmazzuk meg, hiszen a legtöbbünk valaki másnak dolgozik. Ebben az esetben a vezető feladata ezeket mindenki számára egyértelművé és világossá tenni.

A SOLID fontos, a tervezési minták kevésbé

A formális oktatásban sokszor nagy hangsúlyt fektetnek a tervezési minták bemagolására, ami sokszor ahhoz vezethet, hogy a gondolkodásunk túlságosan merevvé válik, hiszen bármilyen problémára az általunk ismert megoldások kötött listájából próbálunk egyet kiválasztani.

A tervezési minták a valóságban sokkal ritkábban fordulnak elő, mint gondolnánk. Természetesen néhány alap minta ismerete valóban szükséges, de számos komplexebb patternnel szinte sosem fogsz találkozni.

Tervezési minták bemagolása helyett inkább fontos, hogy betartsuk a SOLID szabályait. Ezeknek az ismeretése meghaladja a cikkünk kereteit, de ha ez számodra keveset mond, érdemes a hozzá tartozó Wikipedia bejegyzéssel kezdeni.

A fejlesztésben nincsenek dogmák

Egy problémának szinte mindig több megoldása van. Az, hogy ezek közül melyik a legjobb, óriási mértékben függ az adott kontextustól és számos egyéb paramétertől.

Ne használjunk valamilyen technikát, frameworkot vagy bármi mást csak azért, mert az épp trendi, vagy épp ún. “best practice”. Nincs legjobb programozási nyelv, legjobb keretrendszer, legjobb adatbáziskezelő rendszer. Csak eszközök vannak, amiket különböző problémák megoldására fejlesztettek ki; a mi dolgunk az, hogy megtaláljuk ezeknek egy olyan halmazát, amely a mi problémánkat a lehető legjobban oldja meg.

Címkék

Még nincs ITHub szakmai profilod?

Hozz létre egyet pár perc alatt, és csatlakozz a magyar IT karriercsomóponthoz!

Készítsd el szakmai profilodat!

Hasonló cikkek

Code review: 5 tipp, hogy jobban csináljuk
IT 2015-09-01 | Farkas Gábor
Cargo cult SCRUM
IT 2016-03-08 | Kóbor Ádám
Mitől lesz valaki jó DevOps engineer?
IT 2018-02-26 | Kóbor Ádám
2017 legnépszerűbb IT témái
IT 2018-01-01 | ITHub