A saját 10 fejlesztési szabályom
Mindenki valamilyen szabály szerint dolgozik, és weben is sok írás foglalkozik jobbnál-jobb ajánlásokkal, hogy mi is lenne az a 10-20-sok szabály, aminek meg kell feleljen egy webfejlesztő.
Én nem állítok fel új dogmákat, és nem is mondom, hogy az én szabályaim elengedhetetlen feltételei a jó webfejlesztésnek, csak annyit mondok, hogy ezek hosszú távon megkönnyítették – és megkönnyítik ezután is – a munkámat. Ezalatt pedig már nem csak a webfejlesztést értem, hanem a fejlesztést tágabb értelemben. Bizonyos szabályok pedig egyéb területeken is hasznosak lehetnek.
Nincs közöttük semmilyen sorrend, és annyira különböző területhez kapcsolódnak, hogy talán nincs is értelme sorrendbe szedni őket.
Tehát, mindenféle sorrendiség nélkül az én 10 fejlesztési szabályom:
Szabványkövető fejlesztés
Elsőként ez jutott eszembe, mivel csak kiegészítő odafigyelést igényel a munkafolyamatok közben, de a későbbiekben nagyban hozzásegíthet, hogy könnyen és gyorsan lehessen módosítani egy honlapot. Ezenfelül egy szabványkövető kialakítás sokkal kevésbé valószínű, hogy “szétesik” a későbbiekben, mint egy aktuális értelmezéshez hozzádrótozott megoldás. Részletesebb – ajánlott – olvasmány a témakörben Jeffrey Zeldman és Ethan Marcotte Szabványkövető webtervezés című könyve.
A kevesebb néha több
Az ismert szólás a fejlesztésben is jól megállja a helyét. Minél kevesebb kóddal tudjuk előállítani a kívánt végeredményt, annál kevesebbet kell majd karbantartani, és honlapok esetében annál kisebb sávszélességre – vagy rövidebb időre – lesz szükség a letöltéshez.
Ezért érdemes a matematika órán sokat hallott megfogalmazás mentén kódolni: annyi és csak annyi kódot hozzunk létre, amennyi a feladat maradéktalan elvégzéséhez szükséges.
Nagyvonalú dokumentáció (ahol szükséges)
Az én fogalmaim szerint a legjobb dokumentáció bármilyen kód leírására maga a kód. Amennyiben megfelelően van kialakítva és tördelve, a kód elmondja, hogy mire való, ezért a jó kódnak nincs szüksége dokumentációra. Részletes olvasmány Robert C. Martin Tiszta kód című könyve.
A felhasználói kézikönyv azonban már más terület. Itt mindenképpen nagyvonalúan kell bánnunk a leírással, adott esetben a képekkel. A felhasználó nem tudja kiolvasni a kódból, hogy mit hogyan kell csinálni, és sok esetben a felületet sem lehet intuitív módon kialakítani. Ebben az esetben a legjobb részletes instrukciókat írni, ha kell átolvastatni valakivel átadás előtt, mert én magam tudom mit írok le, de az nem biztos, hogy ugyanolyan egyértelmű olyasvalakinek, aki nem programozó.
Csak olyan kódot használj másokéból, amit magad is meg tudnál írni
Érdekes a megfogalmazás, hiszen, ha meg tudom írni, akkor miért használnám másét?
Az egyértelmű magyarázat: csak azokat a harmadik fél által írt kódokat használom, amiket magam is meg tudnék írni, de nincs időm a fejlesztésre vagy hibajavításra. Ebben az esetben ismerem a kód elméletét, tudom, hogy mit miért csinál, és bele is tudok nyúlni majd, ha valahol eltévedne, viszont sok időt nyerek azzal, hogy már készen van.
Használj ingyenes szoftvereket, vagy vedd meg őket
Szinte minden feladatot meg tudok oldani ingyenes szoftverrel, viszont vannak olyan kényelmi funkciók a fizetős szoftverekben, amik igencsak megérik a vásárlást.
Aki azon gondolkodik, hogy másképp tegyen, annak egy egyszerű kérdést tennék fel: amennyiben nem tervezi kifizetni egy másik fejlesztő munkáját, miért várja el, hogy az övét az elvárásainak megfelelően honorálják majd?
Folyamatos tesztelés
Senki sem születik úgy, hogy fejből hibamentes kódot ír. Ráadásul olyant, ami a specifikációnak hiba és kivétel nélkül megfelel. Éppen ezért folyamatos teszteknek kell alávetni a készülő kódot.
Minél bonyolultabb fejlesztésen dolgozunk, annál nagyobb a valószínűsége annak is, hogy egy módosítás befolyásolja más részek funkcióját.
Éppen ezért nem csak az éppen módosított részeket kell tesztelni, hanem a korábbi teszteket is folyamatosan elő kell venni, nehogy egy korábban befejezettnek tekintett kód-darabot tegyünk használhatatlanná.
Következetes kódkialakítás
Érdemes megszokni egy kódolási stílust, és utána amellett maradni. Kivételt képez, ha egy – már összeszokott – fejlesztőcsoporthoz kell csatlakozni. Ebben az esetben a csoport stílusa van nyerő helyzetben.
Sokkal gyorsabban lehet újraolvasni régebbi kódokat is, ha legalább a stílusa ugyanaz, mint amit jelenleg is használunk. Amennyiben harmadik féltől származó kódot építünk be a projektbe, a fejlesztőkörnyezetek (Eclipse, Netbeans, …) segíthetnek a saját szánk ízére formázni azt.
A honlap a felhasználóknak kell készüljön, nem a keresőrobotoknak
Elsősorban a használhatóságot és a felhasználói élményt kell szem előtt tartani fejlesztés során, mert hiába kerül első helyre egy honlap a keresőkben, ha a felhasználók menekülnek amint meglátják…
A keresőbarát megoldás csak kiegészítés lehet.
Csak azt tudd, amit tudsz
Ne ess abba a hibába, hogy azt mondod tudsz valamit, amit nem tudsz. Ebből hamar következhet, hogy a fejlesztésre fordítandó idő nem felel meg az elvárásoknak, és a határidőt sem sikerül tartani.
Sokkal jobb tulajdonság, ha valaki felvállalja ha nem tud valamit, mintha belekezd mindenbe, és közben folyamatosan elbukik.
… és végül, de nem utolsósorban:
Ne add fel az elveidet
Miközben egy projektet beszélsz meg a megrendelővel, tartsd tiszteletben az elgondolásait, de nyugodtan javítsd ki, vagy vezesd rá egy jobb megoldásra. Mindamellett, hogy Ő a megrendelő, nekünk kell lefejleszteni a kész honlapot/applikációt, és meglehet, hogy több tapasztalattal rendelkezünk ezen a téren.
Összefoglalás
Minden szabályomra jut egy fejlesztéssel eltöltött év, és minél inkább haladunk tovább az időben, annál biztosabb vagyok, hogy jól döntöttem amikor ezeket a szabályokat meghoztam magamnak.
Nem mondhatom, hogy mindenki fogadja meg a nekem bevált elgondolásokat, csak bízhatok benne, hogy az igényesség példája ragadós, ahogy én is elkaptam másoktól.
Hatékony kódolást!
Mennyibe kerül az ingyenes alkalmazás? Automatikus hook létrehozás minden új svn repository-ban
Comments are currently closed.