A rossz szokásokat nehéz megtörni, és még nehezebb, ha nem veszed észre, hogy amit csinálsz, az aláássa a munkádat. Ha tudod, de nem érdekel – az lenne a legrosszabb. De hát itt vagy, nem?
Programozóként rengeteg rossz gyakorlatot láttam, nemcsak a kód, hanem a csapatmunkával kapcsolatos készségek terén is. Sok ilyen rossz szokás gyakorlásában magam is bűnös voltam. Íme a 35 legfontosabb rossz programozási szokásom, négy kategóriába rendezve: kódszervezés, csapatmunka, kódírás, tesztelés és karbantartás.
Kódszervezés
1. Azt mondani: “Majd később javítom”
A kódjavítások elhalasztásának szokása nem csupán a prioritások problémája. A hibakövető rendszerezése generálhat némi előrelépést, de a felmerülő kisebb problémák nyomon követésére is szükség van. A “TODO” megjegyzések hozzáadása gyors módja annak, hogy ne hagyjon ki semmit.
2. Ragaszkodik az egysoros megoldáshoz
A hatékony, elegáns kódrészletek megrögzött megírása a programozók közös vonása. Olyan, mintha egy rejtvényt oldanál meg – megtalálod a függvények és reguláris kifejezések olyan kombinációját, amely 20 kódsorból 2 vagy 3 sor lesz. Sajnos ez nem mindig eredményez olvasható kódot, pedig általában ez a sokkal fontosabb eredmény. Először a kódodat tedd hozzáférhetővé, aztán okossá.
3. Értelmetlen optimalizációk készítése
Egy másik hely, ahol gyakran félrevisszük az erőfeszítéseinket, az optimalizálás. Jól hangzik, hogy néhány bájtot csökkenthetünk a weboldalunk méretén, de a gzip nem fogja ezt amúgy is pótolni? És nem fontosabbak-e a kérések? Az optimalizálással csak a projekt végén foglalkozzunk, mert a legtöbbször az igények megváltoznak, és az időnk kárba veszett.”
“Az idő előtti optimalizálás minden rossz gyökere.”
-Donald Knuth
4. Az idő előtti optimalizálás minden rossz gyökere. Meggyőzni magunkat arról, hogy a stíluskérdések nem olyan fontosak
Ha valamit megtanultam az évek során, amikor mások kódját néztem, az az, hogy a kódolási stíluskérdésekkel való foglalkozás az a dolog, amit a fejlesztők a legnagyobb valószínűséggel elhalasztanak. Lehet, hogy a tapasztalatlan kódolóknak nehéz belátni, hogy mi jó származik a stílusproblémák kezeléséből, de idővel nyilvánvalóvá válik, hogy ha a kód minősége egyszer kisiklik, a hólabdaeffektus bármilyen projektet teljes zűrzavarba sodor. Szigorúan tartsa be a legjobb gyakorlatokat, még akkor is, ha azok elhanyagolhatónak tűnnek. Állítson be kódellenőrző és linting-eszközöket, hogy legyen ideje a fontosabb dolgokkal foglalkozni.
5. A dolgok szőnyeg alá söprése
Vagy a kivételek elkapásával és figyelmen kívül hagyásával, vagy olyan könyvtárak használatával, amelyek nem jelentik a hibákat (mint például a jQuery), számos módja van a dolgok szőnyeg alá söprésének. De amikor az egyik ilyen hiba prioritássá válik, a javítás kihívása sokszorosan nagyobb lesz, tekintve, hogy fogalmad sem lesz, hol kezdd el. Egyszerű módja ennek elhárítására, ha naplózza ezeket a figyelmen kívül hagyott hibákat, hogy később tanulmányozhassa őket.
6. Olyan nevek használata, amelyek nem adnak hozzá információt
A névadás nehéz dolog, de van egy egyszerű módja annak, hogy a változó- és függvényneveid legalább tisztességes minőségűek legyenek. Mindaddig, amíg a nevek valamilyen információt adnak hozzá, amit a kód többi része nem közvetít, más fejlesztőknek könnyebb lesz elolvasniuk a kódodat. Az elnevezések azért olyan fontosak, mert a nevek általános képet adhatnak arról, hogy mit csinál a kód. Több időt vesz igénybe, ha bele kell ásni a számításokba, hogy kitaláljuk, mit csinál a kóddarab, de egy jó név másodpercek alatt segíthet megérteni, mit csinál a kód.
7. A bevált legjobb gyakorlatok figyelmen kívül hagyása
Kódvizsgálatok, tesztvezérelt fejlesztés, minőségbiztosítás, telepítésautomatizálás – ezek és számos más gyakorlat számtalan projektben bizonyították már értéküket, ezért a fejlesztők folyamatosan blogolnak róluk. Ezeknek a legjobb gyakorlatoknak nagyszerű referenciája a Making Software című könyv: What Really Works, and Why We Believe It. Szánjon időt arra, hogy megtanulja, hogyan kell ezeket megfelelően csinálni, és a fejlesztési folyamata minden projektjében olyan módon fog javulni, ami meglepni fogja.
Csapatmunka
8. Hogyan kell ezeket a gyakorlatokat alkalmazni? A tervek túl korai elhagyása
A rendszered kifürkészhetetlenné tételének biztos módja, ha nem kötelezed el magad egy terv mellett. Mindig mondhatod, amikor a kódodat kritizálják, hogy a terv még nem teljes. Azonban a félig kész modulok megléte szorosan összekapcsolt kódhoz fog vezetni, amint megpróbálod ezeket a befejezetlen modulokat egymással együttműködésre bírni. Ez a fajta bonyodalom akkor is felmerül, amikor egy projekt vezetői szerepe megváltozik, és az új vezetők úgy döntenek, hogy a saját útjuk fontosabb, mint az architektúra konzisztenciája.
9. Ragaszkodik egy olyan tervhez, amelynek kevés esélye van a működésre
Ahogyan a tervek elhagyása is problémákat okozhat, úgy a nem működő tervhez való ragaszkodás is. Éppen ezért meg kell osztania az ötleteit a csapatával, hogy visszajelzést és tanácsot kapjon, amikor a dolgok bonyolulttá válnak. Néha egy másik nézőpont is sokat számíthat.
10. Mindig egyedül dolgozol
Arra kell törekedned, hogy megoszd a fejlődésedet és az ötleteidet a csapattal. Néha azt hiszed, hogy valamit jól építesz, de nem így van, ezért a folyamatos kommunikáció nagyon értékes. A többiek számára is előnyös, ha velük együtt dolgozol. Az ő munkájuk gyakran javul, ha megvitatod velük az ötleteidet, és mentorálod a csapat kevésbé tapasztalt tagjait, akik nagyobb valószínűséggel akadnak el.
11. A rossz kód írásának visszautasítása
Minden fejlesztő életében eljön az az idő, amikor a határidők arra kényszerítenek, hogy szörnyű kódot írj, és ez rendben van. Próbáltad már figyelmeztetni az ügyfeledet vagy a menedzseredet a következményekre, de ők ragaszkodnak a határidőhöz, így most itt az ideje kódolni. Vagy talán van egy sürgős hiba, ami nem várhat arra, hogy tiszta megoldással állj elő. Ezért fontos, hogy programozóként sokoldalú legyél, és képes legyél nagyon gyorsan megírni a rossz kódot éppúgy, mint a jó kódot. Remélhetőleg újra átnézheted a kódot, és visszafizetheted a technikai adósságot.
12. Mások hibáztatása
Nem titok, hogy az arrogancia túlságosan gyakori tulajdonság a fejlesztők és más műszaki szakemberek körében. A hibáidért való felelősségvállalás olyan erény, amellyel ragyogni fogsz a társaid között. Ne félj beismerni, hogy hibáztál. Amint ezt elfogadod, szabadon összpontosíthatsz arra, hogy megtanuld, miért követted el a hibát, és hogyan kerülheted el azt. Ha nem ismered be, a tanulás lehetetlenné válik.
13. Nem osztod meg a csapatoddal, amit tanultál
Az értéked fejlesztőként nemcsak a kódon van, amit írsz, hanem azon is, amit írás közben tanulsz. Oszd meg a tapasztalataidat, írj hozzá megjegyzéseket, tudasd a többiekkel, hogy a dolgok miért olyanok, amilyenek, és segíts nekik új dolgokat megtanulni a projektről és annak fortélyairól.
14. Ne felejtsd el, hogy a munkatársak nem tudnak a projektről. Túl lassan ad visszajelzést a vezetőknek/ügyfeleknek
Minden mesterember egyik legértékesebb jellemvonása abban rejlik, hogy a lehető legjobban gondoskodik arról, hogy mindenki egy véleményen legyen a munkával kapcsolatban. Ennek nem az az oka, hogy a menedzsered táblázatokat tudjon tölteni. Hanem a saját érdekedben is: Kevesebb lesz a bizonytalanságod, és csökken a projekt élettartamával és jövőjével kapcsolatos bizonytalanság.
15. Nem használja eléggé a Google-t
Az összetett probléma gyors megoldásának legjobb módja, ha egyáltalán nem kell megoldani. Ha kétség merül fel, Google-ozz rá. Persze zavarhatod helyette a melletted ülő mérnököt is, de ő ritkán fog tudni olyan részletes választ adni, mint a Stack Overflow, arról nem is beszélve, hogy ezzel az ő munkáját is megzavarod.
16. A Google. A személyes stílusod túlértékelése
Mindig törekedj arra, hogy a munkastílusodat és a környezeted beállítását összehangold a csapatoddal. Ideális esetben a csapatodban mindenki hasonló körülmények között dolgozik, és ugyanazt a kódolási stílust követi. Ha a saját módszereid szerint csinálod a dolgokat, az szórakoztatóbb lehet, de a munkatársak nem biztos, hogy hozzászoktak a kódolási stílusodhoz, és ha az szokatlan, akkor a következő fejlesztőnek nehezebb lesz azon dolgozni, amit te építettél.
17. Nehezítsd meg a munkádat. Személyes kötődés a kódodhoz
Ha valaki megjegyzést tesz a kódodra, ne vedd magadra. A kódodnak szilárd alapokon kell állnia, vagyis meg kell tudnod magyarázni, miért írtad úgy, ahogy. Ha javításra szorul, az csak a kód helyességéről árulkodik, nem rólad.
Kódírás
18. Nem tudod, hogyan kell optimalizálni
A jó optimalizálási stratégiához némi tapasztalatra van szükség. Feltárást, elemzést és egy folyamat minden érintett rendszerének ismeretét igényli. Tájékozódjon ezekről a dolgokról. Ismerje meg az algoritmikus komplexitást, az adatbázis-lekérdezések kiértékelését, a protokollokat, és általában a teljesítmény mérésének módját.
19. Rossz eszközt használsz a feladathoz
Azért kell folyamatosan tanulnod, mert minden új probléma más kontextust hoz, és más eszközt igényel – olyat, amely jobban alkalmazható az adott feladatra. Légy nyitott az új könyvtárakra és nyelvekre. Ne hozzon döntéseket szigorúan a tudása alapján.
20. Nem törődik az eszközök és az IDE elsajátításával
Minden egyes új gyorsbillentyű, gyorsbillentyű vagy paraméter, amit a mindennapos munka során megtanul, sokkal pozitívabb hatással lesz a kódolási sebességére, mint gondolná. Nem arról van szó, hogy néhány másodpercet spórolsz egy gyorsbillentyű használatával; a kontextusváltás csökkentéséről van szó. Minél több időt töltesz egy-egy apró művelettel, annál kevesebb időd lesz arra, hogy átgondold, miért csinálod, és mi következik ezután. A gyorsbillentyűk elsajátítása felszabadítja az elmédet.
21. A hibaüzenetek figyelmen kívül hagyása
Ne feltételezd, hogy a hibaüzenet elolvasása nélkül is tudod, mi a baj a kódoddal, vagy hogy elég gyorsan rájössz. Mindig jobb, ha több információval rendelkezünk egy problémáról, és ha időt szánunk arra, hogy összegyűjtsük ezeket az információkat, hosszú távon több időt takarítunk meg.
22. A fejlesztői eszköztár romantizálása
Néha a kedvenc szerkesztője vagy parancssori eszköze nem a legjobb eszköz az adott feladathoz. A Visual Studio nagyszerű az író IDE-khez, a Sublime nagyszerű a dinamikus nyelvekhez, az Eclipse nagyszerű a Java-hoz, és így tovább. Lehet, hogy imádod a vimet vagy az emacset, de ez nem jelenti azt, hogy minden feladatra az a megfelelő eszköz.
23. Az értékek keménykódolása ahelyett, hogy konfigurálhatóvá tenné őket
Mindig gondoljon arra, hogy milyen változások jöhetnek, és hogyan kezelje azokat. A technikai adósság monstre ütemben fog növekedni, ha nem választja el a mozgó darabokat a munka többi részétől. Használjon konstansokat és konfigurációs fájlokat, ahol szükséges.
24. A kerék állandó újra feltalálása
Ne írjon olyan kódot, amire nincs szüksége. Lehet, hogy valaki más már sok időt töltött a problémáddal, és lehet, hogy van egy jól tesztelt megoldása, amit újra felhasználhatsz. Kímélje meg magát egy kis fáradságtól.
25. Kód vakon történő másolása/beillesztése
Értse meg a kódot, mielőtt újrafelhasználja. Néha első ránézésre nem veszed azonnal észre mindent, amit a kód csinál. Akkor is többet tudhatsz meg egy problémáról, ha időt szánsz arra, hogy részletesen elolvasd a kódot.
26. Nem szán időt arra, hogy megtudja, hogyan működnek a dolgok valójában
Mindig használja ki a lehetőséget, hogy bővítse ismereteit azzal, hogy elgondolkodik a dolgok működésén, és elolvassa a mögöttes problémákat. Lehet, hogy időt spórolsz azzal, ha most nem vesződsz vele, de amit egy projekt során megtanulsz, az hosszú távon fontosabb lesz, mint az, hogy ténylegesen megcsináld
27. Túlzottan bízol a saját kódodban
Veszélyes azt feltételezni, hogy csak azért, mert te írtál valamit, annak nagyszerűnek kell lennie. A programozásról akkor tanulsz többet, amikor új dolgokon dolgozol és tapasztalatot szerzel, ezért időről időre vess egy pillantást a régi kódodra, és gondolkodj el azon, hogyan haladtál előre.
28. A programozással kapcsolatban. Nem gondolkodsz el az egyes tervek, megoldások vagy könyvtárak kompromisszumain
Minden terméknek megvannak a maga finomságai, amelyeket csak a használat és az elemzés során ismerhetsz meg. Egy könyvtár néhány használati példáját látva nem leszel a könyvtár mestere, és ez nem jelenti azt sem, hogy az a tökéletes megoldás minden olyan helyzetre, amely a projektedben felmerül. Legyen folyamatosan kritikus mindennel szemben, amit használ.
29. Nem kérsz segítséget, ha elakadsz
A rövid visszacsatolási hurok megtartása mindig kevésbé lesz fájdalmas számodra. Ha segítséget kérsz, az nem jelenti azt, hogy inkompetens vagy. A megfelelő emberek az erőfeszítéseidet és a tudatlanságod beismerését a tanulásra való törekvésednek fogják tekinteni, és ez nagyszerű erény.
Tesztelés és karbantartás
30. Ne feledd, hogy a segítségedre van szükséged. Átmenő tesztek írása
Olyan teszteket kell írni, amelyekről tudod, hogy átmennek. Sokkal biztonságosabbá teszik a projekt refaktorálását és átszervezését. Másrészt olyan teszteket is kell írni, amelyekről tudjuk, hogy nem fognak átmenni. Szükség van rájuk a projekt előrehaladásához és a problémák nyomon követéséhez.
31. A teljesítménytesztelés figyelmen kívül hagyása a kritikus esetekben
A projekt fejlesztési folyamatának körülbelül a közepénél készítsen egy automatizált teljesítménytesztelési beállítást, hogy megbizonyosodhasson arról, hogy nincsenek eszkalálódó teljesítményproblémák.
32. Teljesítménytesztelés. Nem ellenőrzi, hogy a buildje működik-e
Ritkán fordul elő, hogy egy build átmegy, de valójában nem működik, de előfordulhat, és annál problémásabb lehet a probléma kijavítása, minél tovább vár a vizsgálatával. Minden build gyors tesztelése fontos szokás.
33. A nagy változtatások későn tolása, vagy távozás egy nagy push után
Ez az a pont, ahol a túlzott magabiztosság a vesztedbe rohan, és többször is megégetheted magad, hogy megtanuld, miért nem szabad ezt tenned, ezért most fogadd meg a tanácsomat, és győződj meg róla, hogy mindig ott vagy, amikor a builded végül elromlik.
34. Ez az a pont, ahol a túlzott magabiztosság a vesztedbe rohan. Az általad írt kód megtagadása
Légy hajlandó támogatni az általad írt kódot. Te vagy a legalkalmasabb személy arra, hogy segíts másoknak megérteni. Törekedj arra, hogy a kódod sok év múlva is olvasható maradjon saját magad és mások számára.
35. A nem funkcionális követelmények figyelmen kívül hagyása
Amikor megpróbálsz valamit átadni, könnyen előfordulhat, hogy megfeledkezel néhány fontos területről, például a teljesítményről és a biztonságról. Tartson egy ellenőrző listát ezekről. Nem akarod, hogy tönkretegyék a bulit, mert úgy állítottad fel a határidőket, hogy nem gondoltál ezekre a nem funkcionális aggályokra.
Mik a legrosszabb programozási szokásaid?
Amint gyakran mondják, a szokások teremtményei vagyunk. A munkamódszer javítása a szokásokon keresztül nagyszerű módja annak, hogy ne kelljen túl sokat gondolkodni minden egyes szituáción. Ha egyszer már elsajátítottál egy jó módszert arra, hogy valamit csinálj, az könnyedén megy.