Tartalom
- 01. A kódolás nem vágja tovább
- Szélesség és mélység
- 02. A nagy figyelmeztetés
- 03. Amit az internet mond
- Értsd meg a közeget
- 04. A dolgok, amelyekkel építünk
- 05. Devops
- Értse meg a verem
- Titokzatos munka
- Praktikus eszközök
- 06. Dev megoldja ... talán
- Hibakeresés
- 07. Mit akarnak a felhasználók
- Versenypiaci
- 08. Rajz és írás
- 09. Érezd jól magad
- 10. Maradj éles
- Tetszett ez? Olvassa el ezeket!
A fejlesztőknek többnek kell lenniük, mint kódgeneráló morgós munkásoknak. Többet várunk digitális életünkre, és épp ezek a srácok építik fel, tehát mit kell tudniuk a legjobb fejlesztőknek? Itt vannak azok a dolgok, amelyeket túl sok fejlesztőnél látok hiányozni. Ez nem teljes, de ezek a tulajdonságok teszik egy ésszerű kódolót csodálatos fejlesztővé.
De ez nem egy dolog, és különösen soha nem az XML elemzésének és a kód optimalizálásának képessége, hanem meglepő olyan készségek gyűjteménye, amelyeket nem tanítanak a kódírásról szóló könyvek. Ők egy kis valami extra.
Miért kell így szellőztetni? Mivel a fejlesztés számít, de a fejlesztőket túl gyakran más világba küldik, nem mindig ők alkotják. Ez soha nem működik. A fejlesztés - bármi technikai jellegű - mindig virágzik, ha a know-how-val rendelkezők nemcsak a kódot értik.
01. A kódolás nem vágja tovább
Olyan világban vagyunk, ahol a kódolás egyre kevésbé lenyűgöző. Mindenki épít webhelyeket, némelyik kódol, de nem kell. Már nem csak a nerdy tud webhelyeket, alkalmazásokat és szolgáltatásokat létrehozni.
Amióta megjelent a web, és az emberek megtaníthatták magukat, voltak autodidakta fejlesztők. De még a diplomások is veszélyben vannak. Önéletrajzokat kapok informatikus végzettséggel, mesterséges intelligencia tanfolyamokkal, különféle médiumokkal és kódolással az övük alatt, de még mindig hiányzik valami. Néha sok hiányzik.
Nem ezt mondom elsőként. A „kódolás nem vágja tovább” a 3. fejezet címe A szenvedélyes programozó, amely olyan könyvekkel együtt, mint pl Pragmatikus gondolkodás és tanulás sürgeti a programozókat, hogy fejlesszék magukat a kódon túl; hogy a csapat felelősségteljes és teljesen emberi tagjaivá váljon.
Szélesség és mélység
A fejlesztőknek két szempontból jobbaknak kell lenniük: szélesség és mélység. Meg kell érteniük az emberi interakciók szélességét csapatukban és az általuk épített dolgokkal. Meg kell érteniük a rendszer mélységét, amellyel dolgoznak, egészen az O / S-ig.
És nemcsak a fejlesztőknek kellene elolvasniuk ezeket a dolgokat. Ha fejlesztőkkel dolgozol, úgy gondolom, hogy többet kellene elvárni tőlük. Vázolja őket, hogy miről beszélnek. Kérd meg őket, hogy magyarázzák el képekkel, tárgyakkal, és (működnek) kivágják az emberekből, hogy pontosan milyen lesz a rendszer az azt használó emberek számára.
02. A nagy figyelmeztetés
Negatívan fogok beszélni a fejlesztőkről, de azt hiszem, megengedett, mert az vagyok. Azért is, mert legalább egy dolog, amiről itt beszélek, igaz sok fejlesztőre, akivel találkozom. Bár munkájuk nagyszerű és ismerik a kódjukat, az idők versenyképesek. Szüksége van egy élre, és ez:
- legyél ügyesebb
és
- lenni sokkal emberibb
03. Amit az internet mond
Az „alapvető webfejlesztési készségek” keresése a Google-on hozza fel azt, amire számíthat. Keretrendszer, x-böngésző, CSS és JS. Felsorolják azokat a keretrendszereket, amelyeket ismernie kell, a platformokat, amelyekhez írnia kell, valamint az új trendeket, amelyekre figyelnie kell.
Ezek a médiánk. Ők azok a dolgok, amelyekkel építkezünk, de nem ez adja a projekt sikerét. A fejlesztő megértheti a rendszer minden részletét, elmondhatja az API és az új CSS technológia minden jellemzőjét, de mégis használhatatlant hoz létre.
Értsd meg a közeget
A fejlesztőknek, mint mindenkinek, meg kell érteniük a médiumukat - de meg kell érteniük a közönséget is, legyen az a felhasználó, a csapat vagy más fejlesztő. Meg kell érteniük, hogy médiumuk hogyan illeszkedik a világba (más szóval a termelési környezetbe), és milyen hatása van (az emberek hogyan használják).
Láttam, hogy ezt a „széles és mély” emberként írják le. Széles, mert meg kell értened a világot, mint más emberekkel dolgozó embert. Mélyen, mert alapos műszaki ismeretekre van szüksége a projekt részének szintje alatt. Ezek a fejlesztők hatalmas lendületet adnak a projektjének, és megváltoztatják a projekt ütemét, amely nélkül a nem technikai személyzetet unalmas részletekbe keveredve találja meg, amely túlcsordul a technológiai csapattól.
04. A dolgok, amelyekkel építünk
Nemrég írtam fel egy listát mindarról, amit webhelyek felépítéséhez, a tárhely kezeléséhez és a dolgok elvégzéséhez használunk, hogy a csatlakozó embereknek csalódási lapja legyen a technológiákról, amelyeket az első hetekben meg kell tanulniuk. Olvastuk olvasottnak, hogy az emberek tudják ezeket a dolgokat, ezért, hogy az újoncok megkezdhessék a dolgot, felsorolunk mindent, amit minden nap használunk.
Fél tucat technológiára számítottam, de sokkal többel végeztem. Ez a lista - „amit használunk” - tartalmazza a szokásos CMS-eket, programozási nyelveket és böngésző technológiákat, de egy csomó eszközt is, amelyekről a csapat nem is emlékezett arra, hogy használnák magukat. Az egész izom memória volt. A „git”, a „phing”, a „thor” beírása a parancssorba nem is gondoltuk, hogy valaki esetleg nem.
Eszközök építése; CI; A verzióellenőrzés gitjét természetesnek vették, de az önéletrajzokra visszatekintve ezek alig jelentek meg. A divatosak megjelennek (és cinikus, hogy szerintem bizonyos ügynökségek felveszik őket ?!), de gyakran konkrét tapasztalatok nélkül.
Ezek az eszközök fontosak a projektfejlesztés felgyorsításához, ezért győződjön meg arról, hogy sokkal gazdagabb eszközkészlettel rendelkezik, mint a nyelve, a CMS és néhány keretrendszer. Szüksége van telepítésre, tesztelésre, CI-re, erős verziókezelésre (csapatokban - nem önállóan), és néhány oktatóanyag helyett meg kell értenie ezek alapvető fogalmait.
05. Devops
Ezek az extra eszközök és trükkök szépen illeszkednek abba, amit az emberek devopnak hívnak. A Devops két hagyományos silóval szemben repül: a termeléssel, amely folyamatosan tartja a dolgokat, és a fejlesztéssel, amely új dolgokat készít (és gyakran leállítja a dolgok működését). A silók két tábort eredményeznek, kevés együttérzéssel az iránt.
A gyártási ismeretekkel nem rendelkező fejlesztők gyakrabban állítanak elő gyártásra nem alkalmas kódot olyan konfiguráció vagy funkciók felhasználásával, amelyek még nincsenek a gyártási veremben. Mivel nincsenek tisztában a termelési környezet problémáival, a teljesebb kódolás helyett a termelésbe történő telepítés érdekében kódolják.
Ezek az apró részletek fájdalmas késéseket okozhatnak, amelyeket súlyosbít a szerverkezelés külföldre küldésének tendenciája.
Értse meg a verem
A Devops önmagában is hatalmas terület, amely magában foglalja a folyamatos telepítést és rengeteg automatizálást. Ez egy átfogó összefoglaló, de a fejlesztőknek meg kell érteniük azt a veremet, amelyen futnak. Nem elég ezt átruházni a szerver rendszergazdájára, meg kell értenie, hogy a platform milyen következményekkel jár a kódjára.
Ha a Rails-n dolgozik, olvassa el a Rails kódot, és tudja, hogyan hajtja végre az Apache a Rubyt. Ha Java-on dolgozik, ismerje meg a konfigurációs lehetőségeket. Ha a Perl-t használja, ismerje meg a Perl-modulok telepítésének és konfigurálásának módját.
Titokzatos munka
A ’mit használunk’ lista rengeteg ilyen anyagot tartalmaz, és a jó fejlesztők erre ugranak, hogy megértsék, hogyan történik ez a titokzatos munka. És miután megkapják, a telepítések gyorsabban mennek, a munka gördülékenyebben zajlik, és mindenki csak boldogabb.
A fejlesztők folyamatos telepítése és a kapcsolódó gyakorlatok olyannyira megszokottá válnak, hogy minden fejlesztő vagy vállalat, aki ezt nem gyakorolja, megelőzni fogja magát. Valaki más elkezdi csinálni, és akkor gyorsabbak lesznek, mint te.
Praktikus eszközök
A „devops” guglizása ötletet ad arról, milyen eszközöket használnak ezek a srácok. Nem a PHP-ről és a MySQL-ről, vagy a Railsről szól. Szoftver szállításáról és a projektek kockázatos darabjainak kockázatmentességéről szól. Összpontosítanak a telepítésre, az automatizálásra és arra, hogy a fejlesztőtől a termelési környezetig a lehető leggyorsabban működjenek.
Meg fogja tapasztalni, hogy ez a fejlesztési stílus olyan fejlesztőket kínál, akik jobban működnek egymással, más osztályokkal és vállalatokkal. Ha egy harmadik fél API-jával dolgoznak, megértik a másik oldalon valószínűleg felmerülő problémákat. Amikor a kiszolgáló rendszergazdáival dolgoznak, meg fogják érteni, hogy mire van szükségük a telepítésre, és tudják, hogyan telepítik a szoftvert a termelési kiszolgálókon. Ennek fordítottja fájdalmas lehet ...
06. Dev megoldja ... talán
Az „alapvető webfejlesztői készségek” keresése Michael Greer (The Onion's CTO) szép válaszát hozza meg a Quorán:
- Lustaság: Kétszer sem hajlandó bármit is megtenni: ír hozzá egy szkriptet vagy algót.
- Gyávaság: Kipróbálásra gondol, aggódik a terhelés és a kód hatása miatt
- Vakmerőség: Folyamatosan próbál új dolgokat, ötleteket indít ugyanazon a napon
A gyávaság a „részletekre való figyelem” megfogalmazásának szép módja. A hibakeresés és tesztelés a fejlesztő életének 99 százaléka, amelyet senki sem említett, amikor eljutottak a W3Schoolsba vagy elindították a 101 számítástechnikai tanfolyamot.
Az alkalmazások javításának képessége kiváló problémamegoldó képességeket igényel, de nem csak a kód hibakeresését. Néha az a megoldás, hogy a felhasználók nem tudják letölteni a számláikat, az, hogy az oldalt nyomtathatóvá teszik, ahelyett, hogy egy napot töltenének PDF-fájlokkal. Néha egy link helyettesítheti a fejlesztés egy hetét, de ez az elegáns megoldás nem fog bekövetkezni, ha a fejlesztők pusztán rengeteg kódsor megírásával oldják meg a problémákat.
A tesztelés sok fejlesztő számára csodálatos vakfolt, a sok eszköz ellenére. Használjon egységteszteket, szelént, terhelésvizsgálatot és profilalkotási eszközöket, például az xhprof-ot. Elemzés olyan dolgokból, mint a New Relic, hogy kicsi legyen az alkalmazásod lábnyoma. És tekintse ezt az egészet a fejlesztő munkájának részévé: ez a kódja, győződjön meg róla, hogy tudja, hogy rendeltetésszerűen működik, és nem remélem, hogy működik.
Hibakeresés
A hibakeresés szintén fájó pont. Nem a hibakereső, hanem a probléma hibakeresése - így kiegészíteném Michael Greer listáját:
- Türelmetlenség: agresszíven figyelmen kívül hagyja az irreleváns információkat a valós probléma megtalálása és megoldása érdekében
Ez az összes hibakeresési technika sarokköve. Az irreleváns figyelmen kívül hagyása és a releváns jelentés megtalálása. Sajnos sokan hajlamosak órákig vagy napokig rabszolgasággal kalapálni az irrelevánsokat, és megoldani a problémát azzal, hogy 10-szer megpróbálják ugyanazt.
A sok könyv (sajnos, nem az, amelyet a kiadónak adtam, nem nevezem meg) a hibakeresésről szól, és minden fejlesztőnek el kell olvasnia mindet. Egy igazán nagy fejlesztő hibakeresést végezhet a rendszeren anélkül, hogy látna egy kódsort.
07. Mit akarnak a felhasználók
Értsd meg, mit próbálnak tenni a körülötted élő emberek. Élvezze a kódot - szeresse a CSS fájlok tökéletes behúzásának művészetét vagy a sínek alkalmazás optimalizálását -, de ne felejtse el, hogy mindez egy célra szolgál.
A fejlesztőknek meg kell érteniük az üzleti életet, a műveleteket és az üzleti folyamatokat, mert dolgaik segítenek annak futtatásában. Az ilyen ismeretekkel rendelkező fejlesztők képesek olyan szoftvereket és alkalmazásokat építeni, amelyek segítik a felhasználókat, de gyakran szokatlanul produktívnak tűnnek. Ennek oka lehet a gyors gépelés vagy a csodálatos veremismeret, de valószínűleg annak tudása, hogy a felhasználók mit akarnak.
Versenypiaci
Visszatérve az eredeti álláspontomra, hogy a fejlesztés egyre könnyebbé válik, és a nagyszerű fejlesztők piaca versenyképesebb minden olyan fejlesztő számára, aki képes megérteni az üzleti követelményeket és valami kiváló dolgot hozni azok teljesítéséhez. Segít megérteni a piacot, az ügyfeleket és azt, hogy miért válnak el a pénztől.
Ismerje meg az adatokat, és hogyan változik az idő múlásával. A fejlesztő fejében új technológiákat kellene felsorakoztatniuk a kihívásokkal, amelyek ma megvannak vagy látni fogják. Így, ha egy divatos új ötletet javasol az MD-nek vagy egy ügyfélnek, az azon fog alapulni, hogy az ügyfelek valóban mit akarnak, és megkapja a ráfordítást / időt. (Ezzel szemben a legrosszabb, ha tanúi vagyunk annak, ha a fejlesztők új kedvenc technológiájukat választják minden bajunk megoldására.)
A fejlesztőknek nagyon sok ellenőrzésük van - tudniuk kell-e, hogy az adatbázis egyes mezői mit jelentenek a végfelhasználó számára? Ha megváltoztatjuk az adatokat, mit látnak a felhasználók? Van-e jobb módszer a felhasználók megsegítésére? Túl gyakran a DB rendszergazdák véleménye szerint a világ rosszul tükrözi az adatbázisukat, ahelyett, hogy az adatbázis rosszul reprezentálja a való világot. A világ rendetlen és meglepően tele van éles esetekkel. Foglalkozz vele, a DB rendszergazdái.
08. Rajz és írás
A rajz a legközvetlenebb módja a kommunikációnak arról, hogy milyen dolgok lesznek. A fejlesztőknek képesnek kell lenniük táblára, papírra és sörszőnyegre rajzolni ötleteiket.
A fejlesztőknek képesnek kell lenniük papírra prototípus készítésére, képernyőképek nyomtatására és firkálgatásra, csak a szándékuk közlése érdekében. Ne bízzon abban a fejlesztőben, aki bólint, azt mondja, hogy megérti és megnyitja a szerkesztőjüket.
Olcsóbb kudarc: a legjobb kódolás a rajzolással kezdődik, mint gyors prototípus. Gyakrabban bukjon meg, és győződjön meg arról, hogy a körülötted lévő összes devi ugyanazt csinálja, mint nagyobb valószínűséggel így.
09. Érezd jól magad
És mi van akkor, ha 10 órát kell eltöltened egy probléma megoldásával egy link áthelyezésével? Élvezze - még akkor is, ha ez csak a munka elvégzésének kihívása.
A fejlesztők (vagy bárki) legrosszabb hozzáállása az apátia ahhoz, amit a csapat elérni próbál. Sajnos ez általános, mert a fejlesztők úgy látják, hogy kívül vannak azon, amit a csapat elér. (A szenvedélyes programozó felteszi a kérdést: „mennyivel szórakoztatóbbá tudná tenni a munkáját?” - próbálja ki.)
És készen áll arra, hogy megmutassa munkáját, mivel ennek fordítottja: ne terjessze ki, miután kipróbált egy pár oktatóanyagot a Ruby-ról a „Ruby élményére”!
A web- és alkalmazásfejlesztés még mindig fiatal szakma, de az igazán nagy fejlesztői igények egyre bővülnek. Mindenkinek több fejlesztőre kell számítania, mert minél előbb jövünk ki a csúnya hátsó szobából, és bekapcsolódunk a kreatív folyamatba, annál jobbak lesznek az eredmények.
10. Maradj éles
Ahhoz, hogy ez egy szép 10. körbe kerüljön, hozzáteszek még egy utolsó dolgot. Maradj észnél. Keresse meg a versenyt. A legrosszabb minden elszigetelt.
"Mindig legrosszabb srác legyél minden zenekarban, amelyben vagy."
A legrosszabb - valóban, nagyon rossz - programozók, kódolók, tervezők megtanulják a dolgukat, és a babérjaikon nyugszanak. Szívritmus-szabályozó nélkül túl könnyű lelassítani, és a verseny meglátása nélkül szokássá válik átlagon felüli magadat látni.
Tehát legyél a lehető legrosszabb azáltal, hogy jobbat találsz. Csatlakozzon a munkán kívüli projektekhez, járuljon hozzá, és kérjen visszajelzést és kritikát, mert minél több kritikát kap, annál kevesebb ember fog adni a jövőben. Amikor kitalálod, hogy mit akarnak jobban, mint ők, akkor te vagy a ninja fejlesztő, akit mindenki szeretne.
Dan Frost a 3EV teljes körű szolgáltatást nyújtó webcég technikai igazgatója, az AWS hivatalos partnere. Hét éve dolgozik a CMS és a webalkalmazások fejlesztésében.
Tetszett ez? Olvassa el ezeket!
- Hogyan készítsünk egy alkalmazást
- A legjobb ingyenes webes betűtípusok a tervezők számára
- Fedezze fel a kibővített valóság következő lépéseit
