Efni.
- 01. Kóðun skera það ekki meira
- Breidd og dýpt
- 02. Stóri fyrirvarinn
- 03. Hvað internetið segir
- Skilja miðilinn
- 04. Hlutirnir sem við byggjum með
- 05. Devops
- Skilja stafla
- Dularfull vinna
- Handhæg verkfæri
- 06. Dev mun laga það ... kannski
- Villuleit
- 07. Hvað notendur vilja
- Samkeppnismarkaður
- 08. Teikning og skrift
- 09. Njótið vel
- 10. Vertu skarpur
- Líkaði þetta? Lestu þessar!
Hönnuðir þurfa að vera meira en kynslóðandi nöldurstarfsmenn. Við búumst við meira af stafrænu lífi okkar og það eru þessir strákar sem byggja það, svo hvað þurfa bestu devs að vita? Hér eru hlutirnir sem ég sé vanta hjá of mörgum forriturum. Þetta er ekki tæmandi en það eru þessir eiginleikar sem gera sanngjarnan kóðara að ótrúlegum verktaki.
En það er ekki einn hlutur og það er sérstaklega aldrei möguleikinn á að flokka XML eða fínstilla kóða, það er óvænt safn af færni sem ekki er kennt í bókunum um ritun kóða. Þeir eru svolítið eitthvað aukalega.
Af hverju að sleppa svona? Vegna þess að þróun skiptir máli en forritarar eru of oft sendir í annan heim, ekki alltaf af gerð þeirra. Þetta gengur aldrei. Þróun - hvað sem er tæknilegt - þrífst alltaf þegar þeir sem þekkja til skilja meira en bara kóðann.
01. Kóðun skera það ekki meira
Við erum í heimi þar sem kóðun verður minna áhrifamikil. Allir byggja síður, sumar þeirra kóða en þú þarft ekki. Það er ekki lengur bara nördinn sem getur búið til síður, forrit og eiginleika.
Síðan vefurinn kom og fólk gat kennt sjálfum sér hafa verið sjálfmenntaðir verktaki. En jafnvel útskriftarnemum er ógnað. Ég fæ ferilskrá með fólki með tölvunarfræðipróf, AI námskeið, ýmsa miðla og kóðun undir belti en það vantar samt eitthvað. Stundum vantar mikið.
Ég er ekki sá fyrsti sem segir þetta. ‘Coding don't cut it no more’ er titill 3. kafla úr Ástríðufulli forritarinn, sem ásamt bókum eins og Raunsæ hugsun og nám hvet forritara til að bæta sig umfram kóðann; að verða ábyrgir og algjörlega mannlegir meðlimir liðsins.
Breidd og dýpt
Hönnuðir þurfa að vera betri á tvo vegu: breidd og dýpt. Þeir þurfa að skilja breidd mannlegra samskipta í teyminu og með hlutina sem þeir byggja upp. Þeir þurfa að skilja dýpt kerfisins sem þeir vinna með, allt að O / S.
Og það eru ekki bara forritarar sem ættu að vera að lesa þetta. Ef þú ert að vinna með devs held ég að þú ættir að búast við meira af þeim. Láttu þá skissa upp það sem þeir eru að tala um. Fáðu þá til að útskýra með myndum, hlutum og (það virkar) klippa út fólk nákvæmlega hvernig kerfið verður fyrir mennina sem nota það.
02. Stóri fyrirvarinn
Ég ætla að tala neikvætt um forritara, en ég held að ég sé leyfður af því að ég er einn. Einnig vegna þess að að minnsta kosti eitt sem ég tala um hér á við um marga af þeim verktökum sem ég hitti. Þó að verk þeirra séu frábær og þau þekki kóðann sinn eru tímar samkeppnishæfir. Þú verður að hafa brún og þetta er:
- vertu tæknivæddari
og
- vera mikið mannlegri
03. Hvað internetið segir
Með því að googla eftir „nauðsynlegri færni í vefþróun“ kemur fram það sem þú átt von á. Rammaþekking, x-vafri, CSS og JS. Þeir telja upp ramma sem þú ættir að þekkja, palla sem þú verður að skrifa fyrir og nýjar strauma sem þú ættir að fylgjast með.
Þetta eru fjölmiðlar okkar. Þetta er efni sem við byggjum með en það er ekki það sem skilar árangri í verkefninu. Hönnuður getur skilið öll smáatriði kerfisins, sagt þér alla eiginleika API og nýrrar CSS tækni en samt framleitt eitthvað ónothæft.
Skilja miðilinn
Hönnuðir, eins og allir, þurfa að skilja miðilinn sinn - en þeir verða líka að skilja áhorfendur, vera það að notendur, teymið eða aðrir verktaki. Þeir þurfa að skilja hvernig miðill þeirra passar inn í heiminn (með öðrum orðum framleiðsluumhverfið) og hvaða áhrif það hefur (hvernig fólk notar það).
Ég hef séð þessu lýst sem „breiða og djúpa“ manneskjuna. Breitt, vegna þess að þú þarft að skilja heiminn sem manneskju sem vinnur með öðrum mönnum. Djúpt vegna þess að þú þarft ítarlega tækniþekkingu undir stigi þíns hluta verkefnisins. Þessir verktaki veita verkefninu mikla uppörvun og breyta hraðanum á verkefninu, án þess að þú finnur ekki tæknilegt starfsfólk bogið niður í leiðinlegum smáatriðum sem flæða yfir frá tækniteyminu.
04. Hlutirnir sem við byggjum með
Ég skrifaði nýlega niður lista yfir allt sem við notum til að byggja upp vefsíður, stjórna hýsingu og fá hluti til að fólk sem tengist gæti haft svindlblað af tækni til að læra á fyrstu vikunum. Við vorum að taka það eins og lesið að fólk vissi þessa hluti, svo til að gefa nýliðum byrjun myndum við telja upp allt sem við notum á hverjum degi.
Ég bjóst við hálfum tugi tækni en endaði með miklu fleiri. Þessi listi - „það sem við notum“ - inniheldur venjuleg CMS-skjöl, forritunarmál og vafra-tækni, en einnig fullt af verkfærum sem teymið mundi ekki einu sinni eftir að hafa notað. Þetta var allt vöðvaminni. Við slóðum ‘git’, ‘phing’, ‘thor’ á skipanalínuna, við héldum ekki einu sinni að einhver gæti ekki.
Byggja verkfæri; CI; git fyrir útgáfustýringu var tekið sem sjálfsögðum hlut, en þegar litið er yfir ferilskrár birtust þær varla. Þeir töffu myndu birtast (og er það tortryggilegt að ég held að ákveðnar stofnanir bæti þeim við ?!) en oft án áþreifanlegrar reynslu.
Þessi verkfæri eru mikilvæg til að flýta fyrir þróun verkefnisins, svo vertu viss um að þú hafir miklu ríkari verkfærasett en tungumálið þitt, CMS og nokkur ramma. Þú þarft dreifingu, prófun, CI, sterka útgáfustýringu (í teymum - ekki á eigin spýtur) og þú þarft að skilja kjarnahugtök þessara frekar en aðeins nokkrar námskeið.
05. Devops
Þessi auka verkfæri og brögð falla snyrtilega að því sem fólk kallar „devops“. Devops flýgur andspænis tveimur hefðbundnum sílóum: framleiðsla, sem heldur hlutunum gangandi og þróun, sem gerir nýtt efni (og stöðvar oft hlutina í gangi). Silóin hafa í för með sér tvær búðir með litla samúð hver við aðra.
Hönnuðir án þekkingar á framleiðslu framleiða oftar kóða sem er ekki hentugur til framleiðslu með því að nota stillingar eða eiginleika sem ekki eru ennþá í framleiðslubunkanum. Vegna þess að þeir eru ekki meðvitaðir um vandamál framleiðsluumhverfisins kóða þeir til að ljúka löguninni frekar en að dreifa henni til framleiðslu.
Þessar litlu smáatriði geta valdið sársaukafullum töfum, aukið af þróuninni á netþjónastjórnuninni.
Skilja stafla
Devops er risastórt svið í sjálfu sér, sem nær yfir stöðuga dreifingu og mikla sjálfvirkni. Þetta er yfirgripsmikið yfirlit en lykilatriðið sem verktaki þarf að skilja er stafla sem þeir eru að keyra á. Það er ekki nóg að framselja þetta til netþjónastjórnandans, þú verður að skilja hvaða áhrif vettvangurinn hefur á kóðann þinn.
Ef þú vinnur á Rails skaltu lesa Rails kóðann og vita hvernig Ruby er keyrður af Apache. Ef þú vinnur í Java skaltu vita um stillingarvalkostina. Ef það er Perl sem þú notar skaltu skilja hvernig á að setja upp Perl einingar og stilla þær.
Dularfull vinna
Listinn „það sem við notum“ inniheldur mikið af þessu efni og góðir verktaki stökkva á það til að skilja hvernig öllu þessu dularfulla starfi er háttað. Og þegar þeir fá það, fara útbreiðslur hraðar, vinnu er dreift á greiðari hátt og allir eru bara ánægðari.
Stöðug dreifing og tengd vinnubrögð devops eru að verða svo stöðluð að allir verktaki eða fyrirtæki sem ekki stunda þetta eru að stilla sig upp til að komast framhjá. Einhver annar mun byrja að gera það og þá verða þeir hraðari en þú.
Handhæg verkfæri
Googling fyrir ‘devops’ gefur þér hugmynd um verkfærin sem þessir krakkar nota. Það snýst ekki um PHP og MySQL eða Rails. Þetta snýst um að senda hugbúnað og halda áhættusömum verkefnum hættulausum. Þeir einbeita sér að dreifingu, sjálfvirkni og halda leiðslunni frá verktaki til framleiðsluumhverfis gangandi eins hratt og mögulegt er.
Þú munt komast að því að þessi þróunarstíll gefur þér forritara sem vinna betur saman og með öðrum deildum og fyrirtækjum. Ef þeir eru að vinna með API frá þriðja aðila, skilja þeir vandamálin sem líkleg eru til að koma upp hinum megin. Þegar þeir vinna með stjórnendum netþjónsins skilja þeir hvað þeir þurfa að setja upp og vita hvernig hugbúnaðarsíður þeirra eru á framleiðsluþjónum. Andstæða þessa getur verið sársaukafullt ...
06. Dev mun laga það ... kannski
Sú leit að „mikilvægri færni vefhönnuða“ færir gott svar frá Michael Greer (CTO Onion) á Quora:
- Leti: Neitar að gera neitt tvisvar: skrifar handrit eða algo fyrir það.
- Hugleysi: Hugsar um að prófa, áhyggjur af álagi og kóðaáhrifum
- Gáleysi: Reynir stöðugt á nýju efni, setur af stað hugmyndir sama dag
Hugleysi er fín leið til að orða athygli á smáatriðum. Kembiforrit og prófanir eru 99 prósent af lífi verktaki sem enginn minntist á þegar þeir lentu á W3Schools eða hófu tölvunámskeiðið.
Hæfileikinn til að laga forrit krefst framúrskarandi færni til að leysa vandamál, en ekki bara kembiforrit. Stundum er lausnin við því að notendur geti ekki hlaðið niður reikningum sínum að gera síðuna prentanlega, frekar en að eyða degi í að búa til PDF skjöl. Stundum getur hlekkur komið í stað viku þróunar, en sú glæsilega lausn mun ekki gerast ef devs eru að leysa vandamál eingöngu með því að skrifa fullt af línum af kóða.
Prófun er dásamlegur blindur blettur fyrir marga devs, þrátt fyrir mörg verkfæri þarna úti. Notaðu einingapróf, selen, álagsprófun og prófílverkfæri eins og xhprof. Greining á hlutum eins og New Relic til að halda fótspori forritsins litlu. Og íhugaðu þetta allt hluti af starfi dev: það er kóðinn þinn, vertu viss um að hann vinni eins og hann er ætlaður frekar en að vona að hann geri það.
Villuleit
Kembiforrit er líka sár punktur. Ekki hvernig á að nota aflúsara heldur hvernig á að kemba vandamál - svo ég myndi bæta við lista Michael Greer:
- Óþolinmæði: hunsar árásarlaust óviðkomandi upplýsingar til að finna og leysa raunverulegt vandamál
Þetta er hornsteinn allrar kembiforritstækni. Hunsa hið óviðkomandi og finna merkingu í viðkomandi. Því miður eru margir tilhneigðir til að hamra hina óviðkomandi í þrælskum tíma eða dögum og laga vandamál með því að reyna það sama 10 sinnum.
Það eru margar bækur (því miður, ekki sú sem ég lagði fyrir útgefandann sem ég nefni ekki) um kembiforrit og hver verktaki ætti að lesa þær allar. Mjög mikill dev getur kembt vandamál á kerfi án þess að sjá línu af kóða.
07. Hvað notendur vilja
Skilja hvað fólkið í kringum þig er að reyna að gera. Njóttu kóðans - elskaðu listina að inndra CSS skrár fullkomlega eða fínstilla teina app - en mundu að það er allt í tilgangi.
Hönnuðir þurfa að skilja viðskipti, rekstur og viðskiptaferla vegna þess að hlutirnir þeirra hjálpa til við að stjórna þeim. Devs með þessa þekkingu geta byggt upp hugbúnað og forrit sem hjálpa notendum, en þau virðast oft óvenju afkastamikil. Þetta gæti verið vegna þess að þeir eru fljótir að skrifa eða ótrúleg þekking á staflinum, en það er líklegra vegna þekkingar þeirra á því hvað notendur vilja.
Samkeppnismarkaður
Þegar ég snýr aftur að upphaflegu atriðum mínum, þá er þróunin að verða auðveldari og markaðurinn fyrir frábæra verktaki er samkeppnishæfari hver verktaki sem er fær um að skilja kröfur fyrirtækisins og koma með eitthvað framúrskarandi til að mæta þeim mun hafa forskot. Skilja markaðinn, viðskiptavini og hvers vegna þeir skilja við peninga hjálpar allt.
Kynntu þér gögnin og hvernig þau breytast með tímanum. Í huga verktakans ættu þeir að stilla upp nýrri tækni með þeim áskorunum sem þú hefur í dag eða sjá koma. Með þessum hætti, þegar þú leggur til hugmynd að lækninum eða viðskiptavininum, nýja hugmynd, byggist það á því sem viðskiptavinirnir raunverulega vilja og þú færð fjárhagsáætlun / tíma í það. (Aftur á móti er það versta sem maður verður vitni að því að verktaki er að smala nýju uppáhaldstækninni sem lausn fyrir öll veikindi okkar.)
Hönnuðir hafa mikla stjórn - þurfa þeir að vita hvað hvert svið í gagnagrunninum þýðir fyrir endanotandann? Ef við breytum gögnum, hvað sjá notendur? Er til betri leið til að hjálpa notendum? Of oft er skoðun DB-stjórnenda að heimurinn sé slæm speglun á gagnagrunni þeirra frekar en gagnagrunnur þeirra sé slæm framsetning á raunverulegum heimi. Heimurinn er sóðalegur og furðu fullur af brúnmálum. Takast á við það, DB stjórnendur.
08. Teikning og skrift
Teikning er beinasta leiðin til að miðla því hvernig efni verður. Hönnuðir verða að geta teiknað hugmyndir sínar á töflu, pappír og bjórmottur.
Hönnuðir verða að geta frumgerð á pappír, prentað skjámyndir og krotað á þær bara til að koma ásetningi sínum á framfæri. Ekki treysta verktaki sem kinkar kolli, segist hafa skilið og opnar ritstjóra sinn.
Mistakst ódýrt: besta kóðunin byrjar með því að teikna sem hraðgerð. Mistakst oftar og vertu viss um að allir devs í kringum þig geri það sama þar sem þú ert líklegri til að ná árangri á þann hátt.
09. Njótið vel
Og hvað ef þú þarft að eyða 10 klukkustundum í að leysa vandamál með því að færa hlekk um? Njóttu þess - jafnvel þó það sé bara áskorunin að komast í gegnum verkið.
Mjög versta viðhorf verktaki (eða einhver) er áhugaleysi gagnvart því sem liðið er að reyna að ná. Því miður er þetta algengt vegna þess að verktaki lítur á sig sem utan þess sem liðið er að ná. (Ástríðufulli forritarinn varpar fram spurningunni „hversu miklu skemmtilegra gætirðu unnið starf þitt?“ - reyndu það.)
Og vertu tilbúinn að sýna verk þín eins og hið gagnstæða af þessu er: ekki stækka eftir að hafa prófað nokkur námskeið um Ruby í „Experience of Ruby“!
Vef- og appþróun er enn ung starfsgrein, en hæfileikinn sem raunverulega mikil þörf er á að þróast eykst. Allir ættu að búast við meira af forriturum því því fyrr sem við komum öll út úr viðbjóðslegu bakherberginu og tökum þátt í sköpunarferlinu því betri verður árangurinn.
10. Vertu skarpur
Til að koma þessu í fínan hring 10 bæti ég við einum loka hlut. Vertu skarpur. Finndu samkeppni. Versta tegund alls er eitt í einangrun.
"Vertu alltaf versti gaurinn í hverri hljómsveit sem þú ert í."
Verstu - raunverulega, mjög slæmu - forritarar, kóðarar, hönnuðir læra dótið sitt og hvíla sig á lógunum. Án gangráðs er of auðvelt að hægja á sér og án þess að sjá samkeppni verður það venja að sjá sjálfan sig yfir meðallagi.
Vertu því það versta sem þú getur með því að finna betra. Taktu þátt í verkefnum utan vinnu, leggðu þitt af mörkum og leitaðu eftir viðbrögðum og gagnrýni vegna þess að því meiri gagnrýni sem þú færð, því færri mun fólk veita þér í framtíðinni. Þegar þú ert að giska á hvað þeir vilja betri en þeir eru, þá ert þú ninja verktaki sem allir vilja.
Dan Frost er tæknistjóri vefþjónustufyrirtækisins 3EV, sem er opinber AWS samstarfsaðili. Hann hefur unnið í CMS og þróun vefforrita í sjö ár.
Líkaði þetta? Lestu þessar!
- Hvernig á að smíða app
- Bestu ókeypis leturgerðirnar fyrir hönnuði
- Uppgötvaðu hvað er næst fyrir aukinn veruleika
