Főoldal

"Mérnököt a mérnöktől"

A Schönherz Bázis összeköti az állást kereső és állást kínáló mérnököket.

CV küldés

Küldj önéletrajzot! Gyorsan, egyszerűen.
Megjegyzésbe írd be a pozíció nevét.
CV küldés

Iratkozz fel hírlevelünkre!

Hírek

Ezt a hét hibát kerüld el Java fejlesztés közben
Ezt a hét hibát kerüld el Java fejlesztés közben

A Java az idők múlásával igen kedvelt programozási nyelvvé vált a szoftverfejlesztésben. Hiába népszerűbb a C-nél és a C++-nál is, azért még megvannak a saját problémái. Felsoroltunk 7 hibát, amit fejlesztőként elkövethetsz, és persze elmondjuk, hogyan kerülheted el ezeket .


1. „Break” utasítás kifelejtése

„A ’break’ utasítás kihagyása döntő lehet a kódod működése szempontjából.” – írja Austin Moulden, a Papar Fellows és az Australian Help tech írója. – „Hiszen, ennek hiányában a program a ’nulla’ után ’egy’-et ír, majd az egész switchen utasításblokkon végighalad, amíg el nem ér egy ’break’-hez. És ez a hiba akár a bevezetésig észrevétlen maradhat, ami káros lehet a kódnak. Ezért soha ne felejtsd a ’break’ parancsot, ahol szükséges.


2. A kapcsos zárójelek nem bezárása

A kapcsos zárójelek a programozásban a kód lezárására és indítására valók. Sok fejlesztő, főképp az újoncok közül, elfelejti lezárni a kódot a kapcsos zárójellel. Bár ezt a hibát a fordítóprogramok és a modern IDE-k is gyorsan kiszúrják, egy programozónak nem árt, ha figyel zárójelek bezárásának hiányára. A legegyszerűbb, ha már előre kiteszed a zárójel mindkét felét, mielőtt még leírnád a kódot.



3. Nyitva hagyott ajtó a memóriaszivárgás előtt

Az, hogy a Java automatikus memória menedzsmenttel rendelkezik, nem jelenti azt, hogy mindig tökéletesen működik, ha „memória-takarékosságról” van szó.

A memória allokáció gyenge pontja a memóriaszivárgás. Ez a probléma az állandó objektum referenciáknál lép fel, mert a szemétgyűjtő nem tud megszabadulni azoktól az objektumoktól, amikhez még kapcsolódik referencia. Ezek a referenciák egyes objektumokat tartalmazó statikus mezővel rendelkező osztály definiálásával jönnek létre. Ha ez a mező, az „eldobás” előtt, véletlenül nincs nullára állítva, akkor nem is lesz begyűjtve.

Vagy, a memóriaszivárgás olyan objektumokhoz is kapcsolódhatnak, amik egymás referenciái, körkörösen függnek egymástól, ezzel megtévesztve a szemétgyűjtőt, hogy meglétük szükséges-e, vagy sem. Akárhogy is, memóriaszivárgást okozhat az objektumok memóriafogyasztása.

A memória szivárgásának megakadályozása érdekében próbálkozz a „pollLast” módszerrel, amely visszaadja az elemet és eltávolítja a deque-ből.


4. Nem megfelelő kivételkezelés

Egy másik Java fejlesztő probléma a kivételkezelés elmulasztása. Bár sokszor csábítónak tűnhet ignorálni a kivételeket, ezeket mindenképp kezelni kell. A következőkkel próbálkozhatsz:

· Kivételek visszadobása,

· Üzenet írás a logba vagy

· Hiba párbeszédpanel megjelenítése a felhasználónak

Az előbb felsorolt lépésekkel a többi fejlesztő tudtára adhatod, miért maradt az adott kivétel kezeletlenül.


5. Összehasonlítás: (==) vagy ’equals?

Az == operátor és az equals() metódus, bár hasonlóak, mégis eltérő dolgot jelentenek.

· Az == operátor dirketben hasonlít össze két objektumot

· az equals() metódus szemantikailag végzi az összehasonlítást (az adataik alapján)

Csak akkor használd a == operátort, ha két objektumot közvetlenül szeretnél összehasonlítani. Ezen kívül két objektum tartalmi összehasonlításakor használd az equals () metódust.



6. Generikus típusok paraméterezésének elmaradása

A generikus típusok messze felülmúlják a nyers típusokat, hiszen az utóbbiak nincsenek paraméterezve és nem tartoznak az R osztály statikus tagjai közé sem (tehát, nem származtathatóak le az R szuperosztályból vagy szuperinterfészből). A 1.5 verzió óta a Java generikus programozása sokat fejlődött: paraméterezett és elég biztonságos, hogy a nélkülözhetetlen információk ne legyenek véletlenül a kódba rejtve. Bár a fordítóprogramok nem képesek a nyers típusok hibáit kiszűrni, az inkonzisztens részek beazonosítására fontos a generikus típusok használata, így ezek nem fogják megtörni a típus rendszert.


7. Contract megszegése

„Akár a standard könyvtárból, akár egy harmadik eladó féltől származó code contract-ról van szó a fejlesztők lehivatkozhatják ezeket.” – írja Jorja Gilfillan, az Essay roo és a State of writing business bloggere. Mint minden másnak, a programozásnak is megvannak a saját szabályai, amit egy fejlesztőnek be kell tartania. Ha ezt nem teszi meg, annak számos negatív következménye lehet:

· Hibás kód ami veszélyezteti a működést

· Rossz UI viselkedés

· Téves adatriportok

· Adatvesztés

· Alacsony teljesítmény

A legbiztosabb betűről-betűre követni a contract-ot, így garantáltan elkerülheted a problémákat. Bár egyes hibák első ránézésre ártalmatlannak tűnhetnek, mindig rögtön javítsd őket.


Konklúzió

Mint minden programozási nyelvnek, így a Java-nak is megvannak a saját előnyei és hátrányai. A legjobb megoldás az, ha azonnal javítod a hibát, amit észrevettél a kódodban. A Stackify Prefix-hez hasonló dinamikus kódelemzők implementálása segítenek a hibák felfedésében.


***

Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minőségi munkáltatónál, jó helyen jársz, mert a Schönherz Bázis épp azért jött létre, hogy Neked segítsen.
Gyere, nézz szét aktuális állásaink között!


2020.12.23.