Sisu
- 01. Kodeerimine ei lõika seda enam
- Laius ja sügavus
- 02. Suur hoiatus
- 03. Mida Internet ütleb
- Mõista keskmist
- 04. Asjad, millega ehitame
- 05. Devops
- Aru virnast
- Saladuslik töö
- Käepärased tööriistad
- 06. Dev parandab selle ... võib-olla
- Silumine
- 07. Mida kasutajad soovivad
- Konkurentsiturg
- 08. Joonistamine ja kirjutamine
- 09. Naudi ennast
- 10. Jää teravaks
- Meeldis see? Loe neid!
Arendajad peavad olema midagi enamat kui koodi genereerivad nurinatöötajad. Ootame rohkem oma digitaalsest elust ja seda ehitavad just need kutid, mida siis peavad parimad arendajad teadma? Need on asjad, mida näen liiga paljudelt arendajatelt puuduvat. See pole ammendav, kuid just need omadused muudavad mõistliku kodeerija hämmastavaks arendajaks.
Kuid see pole üks asi ja eriti mitte kunagi võime XML-i sõeluda või koodi optimeerida, see on üllatav kogum oskusi, mida koodi kirjutamise raamatutes ei õpetata. Nad on natuke midagi ekstra.
Miks niimoodi tuulutada? Kuna arendamine on oluline, kuid arendajaid suunatakse liiga sageli teise maailma, mitte alati nende enda loodud. See ei toimi kunagi. Areng - mis tahes tehniline - on alati edukas, kui oskavad inimesed saavad aru mitte ainult koodist.
01. Kodeerimine ei lõika seda enam
Oleme maailmas, kus kodeerimine muutub vähem muljetavaldavaks. Kõik ehitavad saite, mõned neist kodeerivad, kuid te ei pea seda tegema. Saite, rakendusi ja funktsioone ei saa luua enam ainult nohik.
Alates veebi ilmumisest ja sellest, et inimesed said ise õpetada, on olnud iseõppinud arendajaid. Kuid isegi lõpetajad on ohus. Saan CV-sid inimestega, kellel on arvutiteaduse kraad, tehisintellekti kursused, erinevad meediumid ja nende vöö all kodeeritud inimesed, kuid midagi on ikkagi puudu. Vahel jääb palju puudu.
Ma pole esimene, kes seda ütles. "Kodeerimine ei lõika seda enam" on 3. peatüki pealkiri Kirglik programmeerija, mis koos selliste raamatutega nagu Pragmaatiline mõtlemine ja õppimine kutsuge programmeerijaid üles ennast koodeksist kaugemale täiendama; saada meeskonna vastutustundlikeks ja täielikult inimlikeks liikmeteks.
Laius ja sügavus
Arendajad peavad olema paremad kahel viisil: laius ja sügavus. Nad peavad mõistma inimeste suhtlemise laiust oma meeskonnas ja ehitatavate asjadega. Nad peavad mõistma töötava süsteemi sügavust kuni O / S-ni.
Ja seda ei peaks lugema mitte ainult arendajad. Kui töötate arendajatega, peaksite neid rohkem ootama. Pange nad visandama, millest nad räägivad. Laske neil piltide, objektide ja (see töötab) inimestelt välja lõigata, kuidas süsteem täpselt seda kasutavate inimeste jaoks välja näeb.
02. Suur hoiatus
Räägin arendajatest negatiivselt, kuid arvan, et mul on lubatud, sest olen selline. Ka sellepärast, et vähemalt üks asi, millest siin räägin, kehtib paljude arendajate kohta, kellega kohtun. Kuigi nende töö on suurepärane ja nad tunnevad oma koodi, on ajad konkurentsivõimelised. Teil peab olema serv ja see on:
- ole nutikam
ja
- olema palju inimlikum
03. Mida Internet ütleb
Googeldamine „oluliste veebiarenduse oskuste” kohta toob esile selle, mida võite oodata. Raamistiku teadmised, x-brauser, CSS ja JS. Seal on loetletud raamistikud, mida peaksite teadma, platvormid, millele peate kirjutama, ja uued suundumused, millel peaksite silma peal hoidma.
Need on meie meedia. Need on asjad, millega me ehitame, kuid mitte see ei anna projektile edu. Arendaja saab aru süsteemi igast detailist, ütleb teile API ja uue CSS-tehnoloogia kõiki funktsioone, kuid toodab siiski midagi kasutamiskõlbmatut.
Mõista keskmist
Arendajad, nagu kõik, peavad mõistma oma meediumit - kuid nad peavad mõistma ka vaatajaskonda, olgu selleks siis kasutajad, meeskond või muud arendajad. Nad peavad mõistma, kuidas nende meedium sobib maailma (teisisõnu, tootmiskeskkonda) ja millist mõju see avaldab (kuidas inimesed seda kasutavad).
Olen näinud, et seda kirjeldatakse kui "laia ja sügavat" inimest. Lai, sest peate mõistma maailma kui inimest, kes töötab koos teiste inimestega. Sügav, sest vajate põhjalikke tehnilisi teadmisi, mis jäävad alla teie projekti osa. Need arendajad annavad teie projektile tohutu tõuke ja muudavad projekti tempot, ilma milleta leiate tehnilise personali, kes on tehnikameeskonnast üle ujutatud tüütute detailidega.
04. Asjad, millega ehitame
Kirjutasin hiljuti nimekirja kõigest, mida kasutame saitide loomiseks, hostimise haldamiseks ja asjade tegemiseks, et liituvatel inimestel oleks oma esimestel nädalatel õppida petta tehnoloogiatest. Me pidasime seda loetuks, et inimesed teadsid neid asju, nii et uute värbajate jaoks oleks kiire algus, loetleksime kõik, mida iga päev kasutame.
Ootasin, et pool tosinat tehnoloogiat, kuid jõudsin lõpuks hoopis enama juurde. See loend - mida me kasutame - sisaldab tavalisi CMS-e, programmeerimiskeeli ja brauseritehnoloogiaid, aga ka hulga tööriistu, mida meeskond isegi ei mäletanud enda kasutamisest. See kõik oli lihasmälu. Trükkides käsureale ’git’, ’phing’, ’thor’, ei mõelnud me isegi, et keegi võib-olla mitte.
Ehitada tööriistu; CI; Versioonikontrolli gitit peeti enesestmõistetavaks, kuid CV-de peale tagasi vaadates ei ilmunud need peaaegu üldse. Trendikad ilmuksid välja (ja kas see on küüniline, et ma arvan, et teatud agentuurid lisavad need ?!), kuid sageli ilma konkreetse kogemuseta.
Need tööriistad on projekti arendamise kiirendamiseks olulised, nii et veenduge, et teil oleks palju rikkam tööriist kui teie keel, CMS ja paar raamistikku. Teil on vaja juurutamist, testimist, CI-d, tugevat versioonihaldust (meeskondades - mitte üksi) ja peate mõistma nende mõisteid, mitte ainult mõnda õpetust.
05. Devops
Need lisatööriistad ja nipid sobivad kenasti sellesse, mida inimesed nimetavad devopideks. Devops lendab kahe traditsioonilise silo ees: tootmine, mis hoiab asju käimas, ja arendus, mis teeb uut kraami (ja peatab sageli asjade käigu). Silode tulemuseks on kaks leeri, kus teineteist vähe kaastakse.
Arendajad, kellel pole tootmisteadmisi, toodavad sagedamini tootmiseks sobimatut koodi, kasutades konfiguratsiooni või funktsioone, mida pole veel tootmisvirnas. Kuna nad pole teadlikud tootmiskeskkonna probleemidest, kodeerivad nad funktsiooni lõpuleviimiseks, mitte selle tootmiseks juurutamiseks.
Need väikesed üksikasjad võivad põhjustada valusaid viivitusi, mida võimendab serverihalduse välismaale saatmise trend.
Aru virnast
Devops on omaette tohutu valdkond, mis hõlmab pidevat juurutamist ja palju automatiseerimist. See on ülevaatlik kokkuvõte, kuid peamine asi, mida arendajad peavad mõistma, on virn, millel nad töötavad. Sellest ei piisa, kui delegeerida see serveri administraatorile, peate mõistma platvormi mõju teie koodile.
Kui töötate Railsil, lugege Rails'i koodi ja teadke, kuidas Apache Ruby käivitab. Kui töötate Java-s, siis teadke konfiguratsioonivalikute kohta. Kui kasutate Perli, saate aru, kuidas Perli mooduleid installida ja konfigureerida.
Saladuslik töö
Nimekiri “mida me kasutame” sisaldab palju seda kraami ja head arendajad hüppavad selle üle, et mõista, kuidas kogu see salapärane töö tehakse. Ja kui nad selle saavad, lähevad lähetused kiiremini, töö on sujuvam ja kõik on lihtsalt õnnelikumad.
Devopsi pidev kasutuselevõtt ja sellega seotud tavad on muutumas nii tavapäraseks, et kõik arendajad või ettevõtted, kes seda ei praktiseeri, seavad end ette. Keegi teine hakkab seda tegema ja siis on ta sinust kiirem.
Käepärased tööriistad
Google'i otsing "devops" annab teile aimu tööriistadest, mida need poisid kasutavad. See ei käi PHP ja MySQL ega Rails kohta. See puudutab tarkvara edastamist ja projektide riskantsete osade riskivaba hoidmist. Need keskenduvad kasutuselevõtule, automatiseerimisele ja gaasijuhtme arendajalt tootmiskeskkonnale võimalikult kiiresti töötamisele.
Leiate, et selline arengustiil annab teile arendajad, kes töötavad omavahel paremini ning teiste osakondade ja ettevõtetega paremini. Kui nad töötavad kolmanda osapoole API-ga, saavad nad aru probleemidest, mis tõenäoliselt teisel pool esile kerkivad. Serveri administraatoritega töötades saavad nad aru, mida nad vajavad, ja teavad, kuidas nende tarkvarasaidid tootmisserverites asuvad. Selle tagurpidi võib olla valus ...
06. Dev parandab selle ... võib-olla
See otsing "oluliste veebiarendajate oskuste" järele pakub Quoralt Michael Greeri (The Onion's CTO) toreda vastuse:
- Laiskus: keeldub midagi kaks korda tegemast: kirjutab selle jaoks skripti või algo.
- Argus: mõtleb testida, muretseb koormuse ja koodi mõju pärast
- Hoolimatus: proovib pidevalt uusi asju, käivitab ideid samal päeval
Argus on tore viis sõnastada “tähelepanu detailidele”. Silumine ja testimine on 99 protsenti arendaja elust, mida keegi ei maininud, kui nad said W3Schoolsi või alustasid kursust 101.
Rakenduste parandamise võime nõuab suurepäraseid probleemide lahendamise oskusi, kuid mitte ainult koodi silumist. Mõnikord on lahendus, et kasutajad ei saa arveid alla laadida, muuta leht prinditavaks, selle asemel, et veeta päev PDF-ide loomisel. Mõnikord võib link asendada nädala arendust, kuid seda elegantset lahendust ei juhtu, kui arendajad lahendavad probleeme puhtalt palju koodiridu kirjutades.
Testimine on paljude arendajate jaoks suurepärane pimeava, hoolimata paljudest tööriistadest. Kasutage ühikute teste, seleeni, koormuse testimist ja profileerimise tööriistu nagu xhprof. Analüüs sellistest asjadest nagu uus reliikvia, et teie rakenduse jalajälg oleks väike. Ja pidage seda kogu arendaja töö osaks: see on teie kood, veenduge, et teaksite, et see töötab ettenähtud viisil, mitte loodan, et see töötab.
Silumine
Silumine on samuti valus punkt. Mitte seda, kuidas silurit kasutada, vaid kuidas probleemi siluda - nii et ma täiendaksin Michael Greeri loendit:
- Kannatamatus: agressiivselt ignoreeritakse ebaolulist teavet tegeliku probleemi leidmiseks ja lahendamiseks
See on kõigi silumisvõtete nurgakivi. Eirates ebaolulist ja leides asjakohases tähenduse. Kahjuks on paljud kalduvad tundide või päevade jooksul ebaolulist orjalikult vasardama, probleemi lahendama, proovides sama asja kümme korda.
Silumite otsimiseks on palju raamatuid (kahjuks mitte ühtegi kirjastajale välja antud raamatut, mida ma ei nimeta) ja kõik arendajad peaksid need kõik läbi lugema. Tõeliselt suur arendaja võib süsteemis probleeme siluda ilma koodirida nägemata.
07. Mida kasutajad soovivad
Saage aru, mida ümbritsevad inimesed üritavad teha. Nautige koodi - armastage CSS-failide taandamise kunsti või rööbastee rakenduse optimeerimist - kuid pidage meeles, et see kõik on eesmärgipärane.
Arendajad peavad mõistma äri, toiminguid ja äriprotsesse, sest nende asjad aitavad seda juhtida. Selle teadmisega arendajad suudavad luua tarkvara ja rakendusi, mis kasutajaid aitavad, kuid sageli tunduvad need ebatavaliselt produktiivsed. Selle põhjuseks võib olla nende kiire kirjutamine või hämmastavad teadmised virnast, kuid pigem nende teadmine kasutajate soovidest.
Konkurentsiturg
Tulles tagasi oma algsele mõttele, on see, et arendamine muutub lihtsamaks ja suurepäraste arendajate turg on konkurentsivõimelisem, kui igal arendajal, kes suudab mõista ärinõudeid ja tuua neile vastamiseks midagi suurepärast, on eeliseid. Turust, klientidest ja sellest, miks nad rahaga lahku lähevad, on kõik aru saada.
Mõistke andmeid ja nende muutumist aja jooksul. Arendaja arvates peaksid nad seadma uued tehnoloogiad väljakutsetega, mis teil täna on või näete. Nii, kui pakute MD-le või kliendile väljamõeldud uut ideed, põhineb see sellel, mida kliendid tegelikult tahavad, ja saate eelarve / aja. (Seevastu halvim tunnistajaks on see, et arendajad müüvad oma uue lemmiktehnoloogia kõigi meie probleemide lahenduseks.)
Arendajatel on palju kontrolli - kas nad peavad teadma, mida andmebaasi iga väli tähendab lõppkasutaja jaoks? Kui me andmeid muudame, mida kasutajad näevad? Kas kasutajate aitamiseks on olemas parem viis? Liiga sageli on DB administraatorite arvates maailm pigem nende andmebaasi halb peegeldus kui see, et nende andmebaas kujutab endast reaalset maailma. Maailm on segaduses ja üllatavalt täis servajuhtumeid. Tegele sellega, DB administraatorid.
08. Joonistamine ja kirjutamine
Joonistamine on kõige otsesem viis suhelda, mis värk välja näeb. Arendajad peavad saama oma ideid joonistada tahvlile, paberile ja õllemattidele.
Arendajad peavad saama oma kavatsusest teatamiseks paberil prototüüpida, printida ekraanipilte ja neile kritseldada. Ärge usaldage arendajat, kes noogutab, ütleb, et mõistab oma redaktorit ja avab selle.
Ebaõnnestumine odavalt: parim kodeerimine algab joonistamisest kui kiire prototüübist. Ebaõnnestuge sagedamini ja veenduge, et kõik teie ümber olevad arendajad toimiksid samamoodi, kui teil on suurem tõenäosus sel viisil õnnestuda.
09. Naudi ennast
Ja mis siis, kui peate kulutama 10 tundi probleemi lahendamiseks, viies lingi ümber? Nautige seda - isegi kui see on vaid töö läbisaamise väljakutse.
Arendajate (või kellegi) kõige halvem suhtumine on apaatia selle suhtes, mida meeskond üritab saavutada. Kahjuks on see tavaline, sest arendajad näevad end väljaspool meeskonna saavutusi. (Kirglik programmeerija esitab küsimuse: "Kui palju lõbusam oleks teie töö?" - proovige seda.)
Ja olge valmis oma tööd näitama, sest vastupidine on järgmine: ärge laiendage, olles proovinud paar Ruby kohta käivat õpetust rubriiki Experience of Ruby!
Veebi- ja rakenduste arendamine on endiselt noor elukutse, kuid tõeliselt suurte arendajate vajaduste oskus laieneb. Kõik peaksid ootama rohkem arendajaid, sest mida kiiremini me kõik vastikust tagatoast välja tuleme ja loomeprotsessiga tegeleme, seda paremad on tulemused.
10. Jää teravaks
Et tuua see kena vooru 10 juurde, lisan veel ühe asja. Jää teravaks. Leidke konkurents. Halvim miski on eraldiseisev.
"Ole alati kõige halvem mees igas bändis, kus sa oled."
Halvimad - tõesti, väga halvad - programmeerijad, kooderid, disainerid õpivad oma asju ja puhkavad loorberitel. Südamestimulaatorita on liiga lihtne tempot aeglustada ja konkurentsi nägemata muutub harjumuseks näha ennast üle keskmise.
Nii et olge kõige halvem, leides parema. Liituge projektidega väljaspool tööd, andke oma panus ja otsige tagasisidet ja kriitikat, sest mida rohkem kriitikat saate, seda vähem inimesed teile tulevikus annavad. Kui arvate, mida nad tahavad, kui nad on, siis olete ninjaarendaja, keda kõik tahavad.
Dan Frost on täisteenust pakkuva veebifirma 3EV tehniline direktor, AWSi ametlik partner. Ta on CMS-i ja veebirakenduste arendamisega tegelenud seitse aastat.
Meeldis see? Loe neid!
- Rakenduse loomine
- Parimad tasuta veebifondid disaineritele
- Vaadake, mis on liitreaalsuse järgmine
