Free Press

Üdvözöljük a szoftverfejlesztés csodálatos világában. Készüljön fel egy izgalmas és izgalmas utazásra, amely tele van kóddal, szabályokkal és még több kóddal. És említettem már, hogy vannak szabályok? Ha Ön olyan valaki, aki jártas a kódolásban, akkor a kódolási szabályok fogalma nem újdonság az Ön számára. Lehetsz ezeknek az irányelveknek a határozott támogatója vagy szabadságharcos, aki úgy véli, hogy a kód a kifejezés egyik formája. Bármi is legyen a helyzet, nem árt megnézni néhányat a legjobb gyakorlatok közül, amikor egy jó kód megírásáról van szó.
Érdemes megemlíteni, hogy bár léteznek kódolási szabványok – sokféle változatban léteznek, és gyakran csupán iránymutatások, amelyeket nem kell követni. Hacsak nem akar jó kódot írni, akkor valószínűleg ragaszkodnia kell a szabványok valamilyen formájához.

Kommentárok és dokumentáció írása

Talán az egyik első dolog, amit fejlesztőként megtanul, hogy kommentálja a kódját. Elsőre időpocsékolásnak tűnhet, követve a “Ha ők is fejlesztők – megérthetik” mentalitást. Bár ez néha igaz, a kód kommentálása és a megfelelő dokumentáció megadása végigvezeti a többi fejlesztőt az általad megvalósított algoritmuson és logikán. De ne essünk túlzásba, és ne kommentáljunk minden egyes kódsort! A nyilvánvaló kódot úgy kell hagyni, ahogy van.

Írd olvasható, mégis hatékony kódot

Az olvasható kódok könnyen követhetők, mégis optimálisan használják a helyet és az időt. Kódíráskor gyakran előfordulhat, hogy a lehető legkevesebb sorban szeretnénk megírni a kódot. Lehet, hogy egy teljes metódust vagy függvényt egy sorban írhatsz, de ez csak nehezebbé teszi az olvashatóságot és a megértést.

Használj segédmódszereket

A jó gyakorlat, hogy a kódot tömör és lényegre törő legyen. Egy metódus csak azt valósítsa meg, amire szüksége van. Ha az implementációd egy része valami mást csinál, tedd egy külön metódusba, és hívd meg azt a metódusodon belül.

Ha elkerülhető, NEM szabad keményen kódolni!

Az egyetlen dolog, amit keményen kell kódolni, azok a konstansok. Ennyi.

Írj teszteseteket. Ne feledkezz meg az éles esetekről sem:

Így tudod, hogy mit csinál a metódusod, mit vesz fel és mit kell visszaadnia. Tudni fogod, hogy mikor kell működnie, illetve mikor kell sikertelenül működnie. Egy függvénynek mindig teszteseteken kell alapulnia; nem pedig függvényeken végzett teszteken.

Írd olvasható, mégis hatékony kódot.Tartsd be az aktuális projekt kódolási szabványait

“A SZEMÉLYES SZEMÉLYI PRAKTIKA akár 75 százalékkal is csökkentheti a HIBÁK BEVEZETÉSÉNEK ARÁNYÁT”

Minden projektnek/cégnek megvannak a saját kódolási szabványai. Egyesek előnyben részesíthetik az egyik stílust a másikkal szemben, amikor olyan dolgokról van szó, mint az elnevezési konvenciók, a fájlszerkezet és a szóközök.
Vannak olyan IDE-k, ahol beállíthatja a preferált stílust, ami mentéskor automatikusan korrigál. Könnyebb olvasni, és ezért könnyebb megérteni, ha a projektek összes fájlja ugyanazt a stílust, elnevezési konvenciót, szóközöket stb. használja.

Használja az IDE legördülő menüjét

Nem annyira szabvány, de jó gyakorlat, ezek nagyon hasznosak, és segítenek abban, hogy kevesebb kódolási hibát kövessen el.

Például:
Ha át akarsz nevezni egy változót vagy egy metódust, csak használd az IDE-d “refactor” opcióját, és az IDE megváltoztatja az összes hívást az adott metódus/változó nevére. Nem kell egyenként megváltoztatnod őket, ami a kódodat hibára/hibára hajlamossá teszi.
Ha az összes privát változókhoz getter/setter metódust akarsz létrehozni, csak használd a “create getter/setter” opciót, és az IDE automatikusan létrehozza neked a metódusokat.

AAPI-k praktikusak

“CURRENT SOFTWARE PROJECTS SPEND ABOUT 40 to 50 PERCENT OF Their EFFORT ON AVOIDABLE REWORK”

Before implementation an method, make sure that they are not available for you to use. Nem kell kódolnod, ha egyszerűen importálhatod a funkcionalitást. Ez szuperül megkönnyíti a fejlesztő életét.”
A híres mondás szerint “Ne találd fel újra a kereket”, és ez sok esetben igaz. Azonban mindig mérlegelni kell egy könyvtár importálásának következményeit, különösen, ha az harmadik féltől származik. Az esetleges licencelési problémáktól eltekintve, lehet, hogy csak felduzzasztod a kódbázisodat. Ha csak egy olyan metódusra van szükséged, amely hőmérsékleteket konvertál, nem kell importálnod egy olyan könyvtárat, amely ezt és száz más dolgot is tud.

Páros programozás/kódellenőrzés

“A PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Ezek nagyon hasznosak, amikor a kódod refaktorálásáról van szó. Mások jobb megvalósítást láthatnak a kódod optimalizálásához, vagy egyszerűen csak elegánsabbá tehetik a kódodat. Azt is biztosítja, hogy a fejlesztők betartják a szabványokat, és a munkát kétszeresen ellenőrzik. Mindezek mellett ez egy csodálatos módja annak, hogy a fejlesztők tanuljanak egymástól.”

MÁSOLJ ÉS MENTSE MUNKÁIDAT SOKSZOR

Elég volt mondva. Lemerült akkumulátor, áramszünet, szoftverhiba, tűz, nukleáris katasztrófa – ezek mind-mind adatvesztéssel járhatnak. Ha gyakran mentesz, és valamilyen verziókezelő rendszerben biztonsági másolatot készítesz a kódodról, az egy egyszerű módja annak, hogy a kódod biztonságban maradjon.

A kódolási szabványok és a legjobb gyakorlatok hatalmas téma – sok oldalon át lehetne folytatni. Valójában, ha valaha is szeretne utánaolvasni a Java kódolási szabványoknak, az Oracle éppen ezt kínálja. Ezeknek a szabványoknak és gyakorlatoknak az alkalmazása is alkalmazásonként változik – akár egy hatalmas vállalati projekten dolgozol, akár a kisöcsédnek segítesz a házi feladatban. Számos tényező alapján végső soron rajtad múlik, hogy az általad fejlesztett kód jó kód legyen.

Disclaimer: A blogbejegyzésben kifejtett nézetek és vélemények kizárólag a szerző sajátjai, és nem feltétlenül az Aversan Inc.

véleményét képviselik.