A kezdő programozók által elkövetett gyakori hibák elemzése, pt. 1

Helló Világ! Ha mindent megtanultál, amit tudnod kell, és végre elkezdtél gyakornokként vagy junior fejlesztőként dolgozni, valószínűleg megnyugodhatsz, igaz? Dehogy. Minden csak most kezdődik számodra... Sok minden vesz körül, ami új és felfoghatatlan. Hogy nem csavarod ki rögtön a kapun? Erről fogunk ma beszélni. Ebben a cikkben szeretném elemezni az újoncok gyakori hibáit, és saját tapasztalataim alapján tanácsot adni ezek elkerülésére. Tehát kezdjük minden további nélkül:

1. Fél a tapasztaltabb kollégák segítségétől

Mindannyian emberek vagyunk. Mindannyian félünk attól, hogy hülyének nézünk, különösen új, tapasztaltabb kollégáink szemében. Amikor a fejlesztőket elfoglalják az első munkájukat, gyakran ez a félelem vezérli őket, és erős hallatszóval visszahúzódnak magukba, és mindent maguktól próbálnak kitalálni. Emellett tapasztaltabb kollégák is körülvehetik valakit, akik viszont a legígéretesebb irányt tudják mutatni, így elkerülhető a több hiba és a felesleges "bökkenő a fején". Tehát ne feledje: ne féljen kérdéseket feltenni. Kezdő vagy és ezt mindenki tökéletesen érti. Ha kérsz, senki nem fog bottal megverni. Talán még az ellenkezője is megtörténik: gyorsabban barátkozik meg kollégáival, és aktívabb kommunikációt kezd velük. ÉN' Még többet mondok: minél többet kérdez és megvitat különféle technikai kérdéseket, annál gyorsabban tudja levetkőzni zöld újonc bőrét, és a szakterülete szakértőjévé válni. És még egy tanács. Ne legyen idegen tőleStackOverflow . Kifejezetten arról beszélek, hogy kérdéseket teszek fel ezzel az erőforrással kapcsolatban. Egyrészt időbe telik, mire választ kapsz a kérdésedre. Másrészt azonban gyorsan megtanulhat többféle megközelítést a probléma megoldására, és egy kicsit más szemszögből nézheti meg. Azt is szeretném megjegyezni, hogy gyakorlati előnyökkel jár, ha megjegyzéseket/válaszokat ír, illetve tisztázó kérdéseket ír a StackOverflow-kérdésekre más fejlesztőktől: lehetőséget kap a vitára és a kérdések mélyebbre ásására, nem beszélve a karma növeléséről.

2. Nem próbál meg önállóan információkat keresni

Ez a hiba az előző másik oldalának tekinthető.Itt arra gondolok, amikor elkezdi zaklatni kollégáit és ismerőseit minden felmerülő problémáról vagy akadozásról. Kérdezni jó, de ne ess túlzásokba a kérdésekkel. Ellenkező esetben az emberek egyszerűen bosszantónak találhatják. Ha valamiben összezavarodik, először gyakorolja keresési készségeit a legjobb keresőben – a Google-ban. Valaki más már találkozott az érthetetlen hibák és egyéb problémák túlnyomó többségével. És igencsak meg fog lepődni, ha a google-ba keresve látja, hogy hány ember ismeri a hasonló problémát, és akik már kaptak kimerítő választ, amit a saját munkájukban is alkalmazhatunk. Ezért gyakran hallja kollégáinak válaszát a „Google it” kifejezéssel. Don' Ne sértődjön meg ezen a válaszon – a kollégája nem az Ön személyes tanára, akinek át kell adnia a munkaterületének minden finomságát. Az Internet végtelen kiterjedése lesz a mentorod. Néha a programozókat úgy is emlegetikfekete öves emberek a Google keresőben . Tehát ha "csuklásunk" van, először keressük a google-ban a problémát. Ha nem sikerül megoldást találni (ritka, de előfordul), csak akkor kezdjük el megkérdezni a kollégákat. Az azonnali kérdések arra szolgálnak, hogy tanácsot kapjunk arról, melyik megközelítést válasszuk inkább a probléma megoldásához, mint azt, amit tennének, ha ráütődnének egy gyorshajtóműre vagy egy érthetetlen hibaüzenetre. Végül is képesek lehetnek az Ön által preferált megközelítésen túlra látni, és azonnal megjósolhatják, hogy az adott megközelítés hová vezet hosszú távon.

3. Vakon másolás és beillesztés

De a problémák és megoldásaik guglizásnak megvannak a buktatói. Például vak másolás és beillesztés .Ez általában akkor történik, ha hasonló problémát (de talán nem pontosan ugyanazt) és egy kapcsolódó megoldást talál, például a StackOverflow-n. Megragadja ezt a megoldást, és másolja és illessze be anélkül, hogy tovább mélyedne a részletekben. És akkor Ön vagy munkatársai furcsa hibákat vagy helytelen viselkedést fedeznek fel a kódjában. És senki sem tudja azonnal kitalálni, honnan jöttek. Végül persze megtalálják a másolt kóddal ellátott helyet, és biztosan nem dicsérik meg a megoldást. Ezért, ha kész megoldást talál a StackOverflow-n (vagy bárhol máshol), először alaposan meg kell értenie a mit, hogyan és miért. Esetleg keresse meg a google-ban a megfelelő funkciót, és olvassa el a dokumentációt. És csak miután ezt megtette, adja hozzá a projekthez.

4. Ragaszkodni a rossz megoldáshoz

Megoldás írásakor néha azt tapasztalod, hogy az folyamatosan egyre bonyolultabbá válik, végül zsákutcába érkezik. Aztán megpróbálod még kifinomultabbá tenni a megoldást, hogy valahogyan működőképes legyen, ahelyett, hogy másik, alkalmasabb alternatívát keresel. Lehet, hogy úgy érzed, sok időt és energiát fektetett bele, és ezért úgy döntött, hogy bármi is legyen, nem adod fel, és a meglévő megközelítéseddel megoldod a problémát. Ez nem egészen helyes hozzáállás. Legalábbis a programozásban. Minél hamarabb próbál ki egy másik megközelítést, annál több időt takaríthat meg a végén. Tehát ne féljen kísérletezni és más megközelítéseket is kipróbálni, függetlenül attól, hogy mennyi időt fektetett be a jelenlegibe. Sőt, ha többféle megközelítést kipróbál, és mélyebben belemerül a témába,

5. Fél attól, hogy kérdéseket tesz fel az aktuális feladatával kapcsolatban

A szoftverfejlesztési projekten végzett munka általában meghatározott feladatok elvégzéséből áll. Például Jirában. Ezek a feladatok nincsenek mindig világosan és részletesen körvonalazva. A feladatleírásokat általában a csapatvezetők írják, akik szintén puszta halandók. Előfordulhat, hogy elfelejtenek hozzáadni valamit, vagy nem veszik figyelembe azt a tényt, hogy Ön nem ismeri ezt vagy azt a funkciót. Vagy esetleg nincs hozzáférése a projekthez (például hozzáférése az adatbázishoz, a naplószerverhez és így tovább). És most megkaptad a feladatot, több mint pár órán át tanulmányoztad, de még mindig ott ülsz, és tanácstalanul bámulod a képernyőt. Ahelyett, hogy továbbra is sikertelenül próbálná megérteni ezt, kezdjen el magyarázatot vagy útmutatást kérni attól, aki a feladatot létrehozta. Például abban az alkalmazásban, amelyet csapata kommunikációra használ (például Microsoft Teams), kérdéseket tehet fel, vagy közvetlen megjegyzést tehet a feladattal kapcsolatban. Egyrészt, ha személyes üzenetben írod meg kérdésedet, valószínűleg gyorsabban kapsz választ, hiszen az illető azonnal látja kérdésedet. Másrészt azzal, hogy feltesz egy kérdést Jira-ban, bizonyítékot adsz arra, hogy csinálsz valamit, nevezetesen a probléma elemzését. Van mód ennek a folyamatnak a felgyorsítására: tedd fel kérdésedet egy megjegyzésben a Jira-ban, majd egy DM-ben, dobj egy linket a megjegyzésedre, és kérd meg, hogy nézzék meg.

6. Irreálisan magas elvárások támasztása a csapatvezetéssel szemben

Ez ismét az előző pont másik oldala. A csapatvezető a fejlesztőcsapat vezetője. Általános szabály, hogy a csapatvezető ideje nagy részét különféle kommunikációs formákkal tölti. Ennek ellenére kódot is ír, hogy ne felejtsen el mindent a programozásról. Amint érti, a csapatvezető élete nagyon mozgalmas. Nyilvánvalóan nem lesz kellemes, ha minden alkalommal megrángatja a csapatvezető ujját, amikor tüsszenteni kell. Képzeld el, hogy a csapat minden tagja egy csomó kérdéssel bombázza a vezetést. Ez bárkit megőrjíthet, igaz? És ha sok kérdést halmoz fel, akkor a csapatvezetőjének sok időt kell töltenie a megválaszolással. Mit tehetünk a csoportvezetőhöz intézett kérdések számának csökkentése érdekében:

• Fedezze fel alaposabban a projektdokumentációt, hogy csökkentse a holtfoltok számát.
• Kérdéseit irányítsa a többi csapattaghoz. Lehet, hogy annyira ismerik ezt a funkciót, mint a vezető, vagy talán még jobban is, mivel a funkciót valószínűleg egyikük írta.

Alternatív megoldásként megtekintheti az IDE-ben található megjegyzéseket, hogy ki és mikor módosította utoljára az adott sorban lévő kódot. Pontosan így tudhatja meg, hogy ki a legalkalmasabb személy kérdésének feltevésére. Amint azt már valószínűleg észreveszi, amikor a csapatvezetőknek intézett kérdésekről van szó, csakúgy, mint a kollégákhoz intézett kérdések esetében, meg kell próbálnia boldog közeget találni – ne féljen kérdéseket feltenni, de ne tegyen fel túl sokat. tőlük.

7. Félelem a kód felülvizsgálatától

A kód áttekintéseEz egy olyan szakasz, amely azelőtt történik, hogy elküldi a kódot egy közös alkalmazáshoz (egy megosztott ághoz, például mesterhez vagy fejlesztőhöz). Ezt az ellenőrzést egy olyan fejlesztő végzi, aki nem vesz részt a feladatban, és akinek friss szeme észlelheti a kód stílusának hibáit, pontatlanságait vagy hibáit, amelyeket a kód első megírásakor nem vettek észre. Ha vannak kritikák, azokat megjegyzésként hagyják a kód bizonyos részeihez. Ebben az esetben a kódot író fejlesztőnek ki kell javítania a felülvizsgálat során feltárt hibákat (vagy meg kell vitatnia döntéseit a bírálóval, esetleg meggyőzve őt azok helyességéről). Ezután a kódot újra és újra elküldik felülvizsgálatra, amíg a bírálónak nincs több megjegyzése. A felülvizsgáló „átjáróként” működik a kód véglegesítése előtt. A kihívás az, hogy sok kezdő programozó a kódellenőrzést kritikának és elítélésnek tekinti. Nem értékelik a kódellenőrzéseket, és félnek tőlük. Nem kellene. A kód áttekintése pontosan az, ami lehetővé teszi kódunk fejlesztését. Hiszen fontos információkat kapunk arról, hogy mit csinálunk rosszul, és mire érdemes odafigyelni. Minden kód áttekintést a tanulási görbe részének kell tekintenie, ami segíthet abban, hogy jobb legyen. Amikor valaki megjegyzést fűz a kódjához, megosztja veled a tapasztalatait és a bevált gyakorlatokat. Én személy szerint nem hiszem, hogy jó programozóvá válhat anélkül, hogy kódellenőrzést kapna. Mert nem is vagy tisztában a kódod minőségével és azzal, hogy egy tapasztalt kívülálló rámutat-e a hibákra. nem értékeli a kódértékeléseket, és fél tőlük. Nem kellene. A kód áttekintése pontosan az, ami lehetővé teszi kódunk fejlesztését. Hiszen fontos információkat kapunk arról, hogy mit csinálunk rosszul, és mire érdemes odafigyelni. Minden kód áttekintést a tanulási görbe részének kell tekintenie, ami segíthet abban, hogy jobb legyen. Amikor valaki megjegyzést fűz a kódjához, megosztja veled a tapasztalatait és a bevált gyakorlatokat. Én személy szerint nem hiszem, hogy jó programozóvá válhat anélkül, hogy kódellenőrzést kapna. Mert nem is vagy tisztában a kódod minőségével és azzal, hogy egy tapasztalt kívülálló rámutat-e a hibákra. nem értékeli a kódértékeléseket, és fél tőlük. Nem kellene. A kód áttekintése pontosan az, ami lehetővé teszi kódunk fejlesztését. Hiszen fontos információkat kapunk arról, hogy mit csinálunk rosszul, és mire érdemes odafigyelni. Minden kód áttekintést a tanulási görbe részének kell tekintenie, ami segíthet abban, hogy jobb legyen. Amikor valaki megjegyzést fűz a kódjához, megosztja veled a tapasztalatait és a bevált gyakorlatokat. Én személy szerint nem hiszem, hogy jó programozóvá válhat anélkül, hogy kódellenőrzést kapna. Mert nem is vagy tisztában a kódod minőségével és azzal, hogy egy tapasztalt kívülálló rámutat-e a hibákra. rosszul csinálod, és mire érdemes odafigyelni. Minden kód áttekintést a tanulási görbe részének kell tekintenie, ami segíthet abban, hogy jobb legyen. Amikor valaki megjegyzést fűz a kódjához, megosztja veled a tapasztalatait és a bevált gyakorlatokat. Én személy szerint nem hiszem, hogy jó programozóvá válhat anélkül, hogy kódellenőrzést kapna. Mert nem is vagy tisztában a kódod minőségével és azzal, hogy egy tapasztalt kívülálló rámutat-e a hibákra. rosszul csinálod, és mire érdemes odafigyelni. Minden kód áttekintést a tanulási görbe részének kell tekintenie, ami segíthet abban, hogy jobb legyen. Amikor valaki megjegyzést fűz a kódjához, megosztja veled a tapasztalatait és a bevált gyakorlatokat. Én személy szerint nem hiszem, hogy jó programozóvá válhat anélkül, hogy kódellenőrzést kapna. Mert nem is vagy tisztában a kódod minőségével és azzal, hogy egy tapasztalt kívülálló rámutat-e a hibákra.

8. Arkán döntésekre való hajlam

A különféle feladatoknak/problémáknak gyakran többféle megoldása is lehet. És az összes rendelkezésre álló megoldás közül a kezdők hajlamosak a legbonyolultabb és legrégebbi megoldásokat használni. És ennek van értelme: a kezdő programozók éppen tegnap tanultak meg egy csomó különböző algoritmust, mintát és adatstruktúrát, így viszket a kezük, hogy végre is hajtson néhányat. Bízz bennem, én is ilyen voltam, szóval tudom, miről beszélek :) Volt egy olyan helyzetem, hogy sokáig implementáltam valamilyen funkciót. Nagyon-nagyon bonyolultnak bizonyult. Aztán a vezető fejlesztő átírta a kódomat. Persze nagyon érdekelt, hogy mit és hogyan változtatott rajta. Megnéztem a megvalósítását, és meglepődtem, hogy mennyivel egyszerűbb. És háromszor kevesebb kód volt. És az is meglepő, hogy ennek a funkciónak az automatizált tesztjeit nem távolították el vagy nem módosították! Más szóval, az általános logika ugyanaz maradt. Ebből arra a következtetésre jutottama legzseniálisabb megoldások mindig egyszerűek . E felismerés után a kódolás sokkal könnyebbé vált, és a kódminőségem lényegesen magasabb szintre ugrott. Akkor mikor érdemes tervezési mintákat és divatos algoritmusokat alkalmazni, kérdezed? Alkalmazásukkor a legegyszerűbb és legkompaktabb megoldás lesz.

9. A kerék újrafeltalálása

A kerék egy strapabíró megoldás, amit nagyon régen találtak fel. Ebben az antimintában a fejlesztő saját fejlesztésű megoldást valósít meg egy már megoldott problémára. Néha ezek a meglévő megoldások jobbak, mint amit a programozó kitalál. A kerék újrafeltalálása általában időveszteséggel és csökkenő termelékenységgel jár, mert előfordulhat, hogy a talált megoldás messze van a legjobbtól, vagy lehet, hogy egyáltalán nem találja meg. Ennek ellenére nem zárhatjuk ki, hogy saját, független megoldást készítsünk: ha megtennénk, akkor már csak a másolás-beillesztés maradna hátra. A programozót megfelelően kell irányítani a felmerülő konkrét programozási feladatokhoz, hogy azokat szakszerűen és gyorsan megoldja, akár kész megoldások használatával, akár egyedi megoldások készítésével. Egyrészt, az egyetemeken és az online kurzusokon különféle feladatokkal bombáznak bennünket, amelyek úgy tűnik, hogy segítsenek újra feltalálni a kerekeket. De csak első pillantásra: A valódi cél itt az algoritmikus gondolkodás fejlesztése és a nyelvi szintaxis mélyebb elsajátítása. Az ilyen feladatok az algoritmusok és adatstruktúrák jobb megértésében is segítenek, és szükség esetén kifinomultabb megfelelők megvalósításához is készségeket adnak (ez néha szükséges, de rendkívül ritka). A való életben az esetek túlnyomó többségében nem kell saját kereket feltalálnia, hiszen az Ön igényeinek megfelelő kerekek már régóta léteznek. Talán a tapasztalatlansága megakadályozza, hogy tudjon a szükséges funkciók megvalósításairól. Itt kell megfogadnia a cikk első pontjában található tanácsokat, nevezetesen: kérje tapasztaltabb kollégák segítségét. Képesek lesznek eligazodni (például a megfelelő irányba mutatni a Google-keresésben), vagy konkrét megvalósítást javasolhatnak (például valamilyen könyvtárat).

10. A tesztek megírásának elmulasztása

Minden újonc nem szereti a teszteket. De miért kellene itt kiemelnünk az újoncokat? A tapasztaltabb fejlesztők szintén nem szeretnek teszteket írni, de jobban megértik, miért van szükség tesztekre. Amikor teljesen zöld vagy, azon töprengsz, hogy miért írd meg őket. Minden működik, szóval nem lehet hiba. De hogyan biztosíthatja, hogy a változtatások ne rontsanak el valamit a rendszer más részein? Kollégái nem fogják értékelni, ha olyan változtatásokat hajt végre, amelyek több kárt okoznak, mint hasznot. Itt jönnek a tesztek a segítségünkre. Minél jobban lefedik egy alkalmazás kódját a tesztek, annál jobb (ezt hívják kódlefedettségnek vagy tesztlefedettségnek). Ha az alkalmazás jó tesztlefedettséggel rendelkezik, akkor az összes tesztet lefuttathatja, hogy megtalálja azokat a helyeket, amelyeket a kódja megsért. És ahogy a fenti példában mondtam, Amikor a vezető fejlesztő újrafaktorálta a kódot, a tesztek nem buktak el. Ennek oka az volt, hogy az általános logika nem változott. Tesztekkel kimutatjuk, hogy bizonyos funkciók logikája megváltozott-e vagy sem. Tehát még ha nem is szeret teszteket írni, azok mindenképpen hasznosak, és megérik a rájuk fordított időt.

11. Túlzott megjegyzések

Sok fejlesztő szenved a perfekcionizmustól, és az újoncok sem kivételek. Néha ennek a hajlamnak csak egy oldalát mutatják meg, amikor elkezdenek kommentálni mindenkit és mindent. Még olyan megjegyzéseket is tenni, amelyek feleslegesek, mert a kód annyira nyilvánvaló:

Cat cat = new Cat(); // Cat object

Nem minden kezdő programozó veszi észre azonnal, hogy a kód kommentálása nem mindig jó, mert a felesleges megjegyzések összezavarják a kódot, és megnehezítik az olvasást. És mi van, ha a kód megváltozik, de a régi megjegyzések nem frissülnek? Akkor csak félrevezetnek és összezavarnak minket. Akkor minek egyáltalán ilyen megjegyzést tenni? Általában a jól megírt kódot nem kell kommentálni , mivel minden benne látható és olvasható. Ha megjegyzést kell írnia, akkor már elrontotta a kód olvashatóságát, és próbálja valahogy orvosolni a helyzetet. A legjobb megoldás az, ha eleve olvasható kódot írunk, azaz olyan kódot, amelyhez nincs szükség megjegyzésekre. Nem tehetek mást, mint megemlíteni, hogy a metódusok, változók és osztályok helyes elnevezési konvencióit kell követni. Íme a szabályom: A legjobb megjegyzés az, ha nincs megjegyzés, vagy helyes elnevezés , amely egyértelműen leírja az alkalmazás funkcióit.

12. Rossz névadás

Az újoncok gyorsan és lazán játszanak az osztályok, változók, metódusok stb. elnevezésében. Például egy olyan osztály létrehozásával, amelynek a neve egyáltalán nem írja le a célját. Vagy deklarálnak egy változót egy rövid névvel, például x . Amikor két további változót neveznek n és ylétrejönnek, nagyon nehéz megjegyezni, hogy x miért felelős. Ezzel a helyzettel szembesülve alaposan meg kell gondolnia a kódot, mikroszkóp alatt elemezve (talán hibakereső segítségével), tanulmányoznia kell a funkcionalitást, hogy egyszerűen megértse, mi történik. Itt jönnek a segítségünkre a fentebb említett helyes elnevezési konvenciók. A helyes elnevezés javítja a kód olvashatóságát, így csökkenti a kód megismeréséhez szükséges időt, mivel egy metódust sokkal könnyebb használni, ha a neve megközelítőleg leírja a funkcionalitását. A kódban minden nevekből áll (változók, metódusok, osztályok, objektumok, fájlok stb.), így ez a pont nagyon fontossá válik a helyes, tiszta kód létrehozásánál. Ne feledje, hogy a névnek jelentést kell adnia, például, hogy miért létezik a változó, mit csinál, és hogyan használják. Nem egyszer megjegyzem, hogy a változóhoz a legjobb megjegyzés az, ha jó nevet adunk neki. A megjegyzések mélyebb tanulmányozásához és a helyes elnevezéshez ajánlom az időtlen klasszikusok elolvasását:"Tiszta kód: Az agilis szoftverkészítés kézikönyve", Robert Martin . Ezzel kapcsolatban a cikk első része (elmélkedéseim) a végéhez ért. Folytatjuk...