A programozás nem arról szól, hogy a billentyűzetet nyomkodjuk és a lehető leggyorsabban gépeljünk. Nem arról szól, hogy vallásos módon megjegyezzük a billentyűzet gyorsbillentyűket, és végül elavulttá tesszük az egeret. Nem arról szól, hogy minden egyes létező programozási nyelvet megtanuljunk, már ha ez egyáltalán lehetséges. A jó programozót nem a számítógépének márkája, ára, teljesítménye és operációs rendszere határozza meg, sem pedig az, hogy milyen kódszerkesztőt és IDE-t választ – VS Code, Atom, IntelliJ IDEA, Vim, Notepad++ vagy más -. A sok hollywoodi filmnek köszönhető közhiedelemmel ellentétben a programozás semmiképpen sem egyenlő a hackeléssel.
A programozás továbbá túlmutat egy programozási nyelv szintaxisának és beépített funkcióinak memorizálásán. A logika, a feltételek, a if utasítások és az algoritmusok – különösen a rendezéssel kapcsolatosak – nem festenek teljes képet arról, hogy mi is a programozás valójában. A matematika, a rekurzió, a számítástechnika és a tervezési minták sem tesznek igazságot. Bár hatalmas részét képezik annak, amit a programozás jelent, mégis csak a kirakós játék egyik darabját jelentik.
Tervezés és tervezés
Mielőtt egyetlen sor kódot is írnánk, a projekt tervét és architektúráját alaposan megtervezzük, hogy biztosítsuk vagy legalábbis növeljük a zökkenőmentes fejlesztési ciklus valószínűségét. Itt jön a képbe a szoftvertervezés. Az eszközláncok, a csővezetékek, a nyilvános és belső API-k absztrakciós rétegei, a modularizáció, az objektumkapcsolatok és az adatbázisok strukturálása mind-mind a fejlesztés ezen szakaszában kerülnek megtervezésre.
Élő, lélegző hibakeresők vagyunk
A programozás művészete megköveteli, hogy a dobozon kívül gondolkodjunk, és a problémákat a legpraktikusabb, leghatékonyabb és legmegvalósíthatóbb megoldásokkal oldjuk meg. Valószínűleg ezért vagyunk leginkább mi a háztartás “informatikusa” vagy “ügyfélszolgálatosai”. Gyakorlatilag az a feladatunk, hogy megjavítsuk, ami elromlott. Olyan, mintha a “programozás” a “problémamegoldás” megdicsőült változata lenne.”
Más szóval, élő, lélegző hibakeresők vagyunk a számítógépünkön és azon kívül is, és emiatt fontos, hogy tudjunk dokumentációt olvasni és írni. A megfelelő dokumentáció – amely valódi, részletes dokumentációt tartalmazó oldalak formájában jelenik meg, vagy olyan egyszerű, mint a kódbázisra érdemes kommentárokkal való megszórása – a programozó egyik legfontosabb mentőöveként szolgál. Enélkül elveszünk a sötétben, és képtelenek vagyunk teljesíteni a hibakeresési feladatainkat. Kevés vagy semmilyen előrelépést nem érhetünk el, mert időnk nagy részét a kísérletezéssel és annak vizsgálatával töltenénk, hogyan működik egy keretrendszer vagy egy örökölt kódbázis. Összességében ez egy borzasztóan szörnyű fejlesztői élményt eredményezne.
Vegyünk figyelembe minden lehetséges forgatókönyvet
A hibakeresés már így is elég nehéz. A helyzetet tovább rontja, hogy a kód végrehajtása általában nem lineáris. A nagy projektek a if utasítással rendelkező programlogika miatt a lehetséges végrehajtási utak több “elágazását” vonják maguk után. Minden egyes lehetséges forgatókönyvvel és hibával számolnunk kell, különösen, ha felhasználói bemenetről van szó. Az a kognitív terhelés, amelyet az összes lehetséges végrehajtási útvonal nyomon követése igényel, még nehezebbé teszi a programozást.
Felhasználói élmény
A fejlesztés világából kilépve egy átlagos felhasználó helyébe lépünk. A funkcionalitás biztosítása, az új funkciók hozzáadása, a hibák javítása és a kódbázisunk dokumentálása mellett arra is összpontosítunk, hogy egy átlagos felhasználó hogyan lép kapcsolatba az alkalmazásunkkal vagy szoftverünkkel. Több olyan tényezőt is figyelembe veszünk, amelyek nagyszerű felhasználói élményhez vezetnek, mint például (de nem kizárólagosan) a hozzáférhetőség, a használhatóság, a felhasználóbarátság és -felismerhetőség, a felhasználói felület kialakítása, a színtémák, a funkcionális animációk és a teljesítmény.
Teljesítmény és optimalizálás
Apropó, a teljesítmény önmagában is hatalmas aspektusa a programozásnak. Mi, különösen az informatikai háttérrel rendelkezők, igyekszünk a legidő- és helytakarékosabb algoritmusokat használni és megírni. A mikroszekundumok kifürkészhetetlen időskálájának megszállottjai vagyunk, hogy a lehető legtöbbet hozzuk ki a rendelkezésre álló memóriából, CPU-kból és GPU-kból.
A webfejlesztés kontextusában a hálózatoptimalizálás fontos fogalom, amit meg kell értenünk. Átugrunk a karikákon, hogy minifikáljuk és tömörítsük HTML-ünket, CSS-ünket és JavaScriptünket, csak azért, hogy minimalizáljuk a kiszolgálótól érkező válasz hasznos terhét. A képeket és egyéb különféle erőforrásokat szintén tömörítjük és lustán töltjük be, hogy minimalizáljuk a felhasználó által letöltendő adatmennyiséget, mielőtt az oldal értelmet nyer és használhatóvá válik.
Vannak azonban olyan esetek, amikor túlságosan is a teljesítmény megszállottjaivá válunk. Az idő előtti optimalizálás akkor válik problémává, amikor szükségtelenül a kódbázis bizonyos részeinek optimalizálásával foglalatoskodunk ahelyett, hogy arra koncentrálnánk, amit a tényleges fejlődés és termelékenység érdekében meg kell tenni. Ebben az esetben bölcsen kell megítélnünk, hogy a kódbázis mely részei szorulnak valóban optimalizálásra.
Biztonság
A szoftverünk felhasználói felületén és logikáján túl, programozóként felelősek vagyunk a felhasználóink biztonságáért. Napjainkban, amikor az adatok nagyon áhítottak és erősen pénzzé válnak, fontosabb, mint valaha, hogy biztosítsuk felhasználóink személyes adatainak biztonságát. Azért teszünk extra lépéseket a személyes adatok védelme érdekében, mert felhasználóink megbíznak a szoftverünkben. Ha nem tartjuk fenn ezt a felelősséget, akkor bizonyosan nem vagyunk igazi programozók, még csak távolról sem.
A biztonságot megközelítve sosem lehetünk eléggé biztosak. Általános ökölszabályként “soha ne bízzunk a felhasználói bemenetben”. Még az is “legjobb gyakorlatnak” tekinthető, hogy nagy erőfeszítéseket teszünk az adatok és a felhasználói bemenet szanálása érdekében. Nemcsak a szoftverünket és az infrastruktúránkat tesszük ki nagy kockázatnak, ha nem vagyunk óvatosak velük, hanem azt is kockáztatjuk, hogy érzékeny felhasználói adatokat veszélyeztetünk – éppen azokat az adatokat, amelyek védelmét programozóként ígérjük.
A biztonság azonban nem kizárólag a felhasználói adatokra és a felhasználói bemenetre vonatkozik. A vírusok, férgek, trójai falovak, reklámprogramok, kulcsnaplózók, zsarolóprogramok és a számítógépes kártevők egyéb formái továbbra is terjednek, és világszerte több millió számítógépet és eszközt sújtanak. Még a hardverek és szoftverek több évtizedes technológiai fejlődése után sem létezik sebezhetetlen rendszer. A biztonság egyszerűen egy mesterség, amelyet folyamatosan csiszolnak, de soha nem lesz tökéletes, mert mindig lesznek olyan kíváncsiak, akik minden lehetséges módot felkutatnak, hogy “feltörjenek” egy rendszert.
Ezért a felhasználási esettől és a felhasználói bázistól függetlenül úgy tervezzük a szoftvereinket, hogy a biztonság az egyik, ha nem a legfontosabb prioritás legyen. Azért tesszük ezt, hogy megvédjük felhasználóinkat a fent említett fenyegetésektől, amelyek olyan kellemetlenségeket okozhatnak, mint az adatvesztés, a fájlok sérülése és a rendszer összeomlása, hogy csak néhányat említsünk.
Teamwork makes the dream work
Még ha nem is feltétlenül a programozáshoz kapcsolódik, a csapatmunka rendkívül fontos szerepet játszik a szoftverfejlesztésben. Bármely nagy projekt minden összetettségével és mozgó részével együtt lehetetlen, hogy egyetlen személy minőségi szoftvert fejlesszen a rendszeres iteráció gyors ütemében vagy az ügyfél vagy bármely felügyelő szervezet szigorú határidői és időkorlátai mellett.
Ez az oka annak, hogy különböző, a programozás számos aspektusának valamelyikére szakosodott csapatok működnek. Egyetlen személynek soha nem lesz meg az összes szükséges készség és tudás ahhoz, hogy minden aspektust hatékonyan és egységesen összeragasszon. Az egyik csapat a felhasználói felület tervezéséért és a hozzáférhetőségért felelhet, míg egy másik csapat magának a szoftvernek a funkcionalitásán dolgozik. Ha a különböző szakosodott csapatok összes kompetenciáját egyesítik, az eredményül kapott szoftver a lehető legjobb funkcionalitással, felhasználói élménnyel, teljesítménnyel és biztonsággal fog rendelkezni a pénzügyi és gyakorlati korlátok között.
Az időgazdálkodás és a határidők betartása szempontjából a munkafolyamatok szervezése és automatizálása rendkívül fontos. Időt szánunk arra, hogy megfelelően konfiguráljuk build eszközeinket és pipeline-ainkat, mert ezzel sok időt takaríthatunk meg a jövőben. Általánosságban elmondható, hogy a befektetés megtérülése az idő múlásával növekszik.
Jó együttműködés másokkal
A csapatmunka és együttműködés gondolatát kifejtendő, egészséges kapcsolatokat alakítunk ki társainkkal, mert végső soron egy projekt sikere nagyban függ a mögötte álló csapat sikerétől. Igyekszünk támogató munkakörnyezetet kialakítani, ahol a tapasztalt idősebbek átgondoltan irányítják az újoncokat.
Mivel csapatban fejlesztünk szoftvert, tekintettel kell lennünk arra, hogy mások is olvassák a kódunkat. Ahhoz, hogy a fejlesztési ciklus hosszú távon fenntartható legyen, az olvashatóságot és a karbantarthatóságot ugyanolyan fontosnak tartjuk, mint a projekt logikáját és funkcionalitását. Következetesen jó, olvasható kódot írunk, miközben informatív commit-üzeneteket és dokumentációt biztosítunk, mert ezek mindenképpen segítenek nekünk és másoknak is jobban megérteni a kódunkat.
Apropó, hogy mások olvassák a kódunkat, egy kódellenőrzés remek lehetőség arra, hogy többet tudjunk meg a programozás legjobb gyakorlatairól. Ez egy másik módja annak is, hogy megismerkedjünk egy kódbázissal és az alapjául szolgáló dizájnnal és architektúrával. Bár az építő jellegű kritika kellemetlen és nehezen kezelhető a fogadó oldalon, fontos, hogy jó tanácsként fogadjuk el, hogy programozóként fejlődhessünk.
A programozás nehéz
A programozás a funkcionalitáson túl számos szempontot felölel, mint például a felhasználói élmény, a teljesítmény, a biztonság és a csapatmunka. Nem elég szigorúan csak egy szempontra koncentrálni, miközben a többit kihagyjuk. Jelentős méretű és jelentőségű projektek esetében ez nem olyan egyszerű, mint néhány sor kód beírása. A sikerhez sok gondos tervezésre, tervezésre, megfontolásra és csoportos együttműködésre van szükség. Valójában programozás közben több időt töltünk gondolkodással, mint gépeléssel, különösen a hosszú hibakeresések során.
A programozás végül is valójában a folyamatos, megállás nélküli tanulásról szól. Az alkalmazkodóképesség és az állandó tanulás a kulcsa annak, hogy túléljük ezt az iparágat. Nem számíthatunk arra, hogy relevánsak maradunk, ha nem vesszük ki a részünket a folyamatos tanulásból. Egy ilyen változékony, exponenciális technológiai fejlődéssel jellemezhető iparágban lépést kell tartanunk a gyors ütemmel, nehogy a porban végezzük.
A cikket azzal szeretném zárni, hogy elismerem a világ összes fejlesztőjének kemény munkáját. Ahhoz, hogy megírhassam ezt a cikket, el kellett gondolkodnom egy fejlesztőcsapat napi munkafolyamatán. A programozás és a szoftverfejlesztés számos olyan aspektusát kellett megvizsgálnom, amelyek általában észrevétlenek maradnak. Azóta jobban megbecsülöm a számítógépemre telepített összes szoftvert. Ennek érdekében mindenkit arra bátorítok, hogy ma köszönetet mondjon egy programozónak, függetlenül a tapasztalatától. Hol lennénk nélkülük?
Soha ne vegyük természetesnek a kemény munkájukat.