Saturs
- 01. Kodēšana to vairs negriež
- Platums un dziļums
- 02. Lielais brīdinājums
- 03. Ko saka internets
- Izprotiet barotni
- 04. Lietas, ar kurām mēs būvējam
- 05. Devops
- Saprotiet kaudzi
- Noslēpumains darbs
- Ērti instrumenti
- 06. Dev to izlabos ... varbūt
- Atkļūdošana
- 07. Ko lietotāji vēlas
- Konkurētspējīgs tirgus
- 08. Zīmēšana un rakstīšana
- 09. Izbaudi sevi
- 10. Palieciet asi
- Patika tas? Izlasiet šos!
Izstrādātājiem ir jābūt vairāk nekā kodu ģenerējošiem grunt darbiniekiem. Mēs sagaidām vairāk savas digitālās dzīves, un to veido šie puiši, un kas tad jāzina labākajiem izstrādātājiem? Šīs ir lietas, kuras, manuprāt, trūkst pārāk daudziem izstrādātājiem. Tas nav pilnīgs, taču tieši šīs īpašības padara saprātīgu kodētāju par pārsteidzošu izstrādātāju.
Bet tā nav viena lieta, un jo īpaši tā nekad nav spēja parsēt XML vai optimizēt kodu. Tā ir pārsteidzoša prasmju kolekcija, kas netiek mācīta koda rakstīšanas grāmatās. Viņi ir mazliet kaut kas papildus.
Kāpēc šādi ventilēt? Tā kā attīstībai ir nozīme, taču izstrādātāji pārāk bieži tiek nosūtīti uz citu pasauli, ne vienmēr viņu pašu. Tas nekad nedarbojas. Izstrāde - kaut kas tehnisks - vienmēr plaukst, kad tie, kas zina, saprot vairāk nekā tikai kodu.
01. Kodēšana to vairs negriež
Mēs atrodamies pasaulē, kur kodēšana kļūst mazāk iespaidīga. Visi veido vietnes, dažas no tām kodē, bet jums tas nav jādara. Vietnes, lietotnes un funkcijas var izveidot ne tikai nerdy.
Kopš tīmekļa parādīšanās un cilvēki varēja mācīt sevi, ir bijuši pašmācīgi izstrādātāji. Bet pat absolventi ir apdraudēti. Es saņemu CV ar cilvēkiem ar datorzinātņu grādiem, AI kursiem, dažādiem medijiem un kodēšanu zem viņu jostas, taču kaut kā joprojām trūkst. Dažreiz daudz trūkst.
Es neesmu pirmais, kurš to saka. “Kodēšana to vairs negriež” ir 3. nodaļas nosaukums Kaislīgais programmētājs, kas kopā ar tādām grāmatām kā Pragmatiska domāšana un mācīšanās mudināt programmētājus pilnveidoties ārpus koda; kļūt par atbildīgiem un pilnīgi cilvēcīgiem komandas locekļiem.
Platums un dziļums
Izstrādātājiem jābūt labākiem divos veidos: platumā un dziļumā. Viņiem jāsaprot cilvēku mijiedarbības plašums savā komandā un ar tām lietām, kuras viņi veido. Viņiem ir jāsaprot sistēmas dziļums, ar kuru viņi strādā, līdz pat O / S.
Un šo saturu vajadzētu lasīt ne tikai izstrādātājiem. Ja jūs strādājat ar izstrādātājiem, es domāju, ka jums vajadzētu sagaidīt vairāk no viņiem. Lieciet viņiem ieskicēt, par ko viņi runā. Lieciet viņiem izskaidrot ar attēliem, priekšmetiem un (tas darbojas) cilvēku izgriezumiem, kāda tieši būs sistēma cilvēkiem, kuri to izmanto.
02. Lielais brīdinājums
Es runāšu negatīvi par izstrādātājiem, bet es domāju, ka man tas ir atļauts, jo es tāds esmu. Arī tāpēc, ka vismaz viena lieta, par kuru es šeit runāju, attiecas uz daudziem izstrādātājiem, kurus es satiku. Lai gan viņu darbs ir lielisks un viņi zina savu kodu, laiki ir konkurētspējīgi. Jums ir jābūt malai, un tas ir:
- esi gudrāks
un
- būt daudz cilvēcīgāks
03. Ko saka internets
Google meklēšana par “būtiskām tīmekļa izstrādes prasmēm” atklāj to, ko jūs varētu gaidīt. Sistēmas zināšanas, x-pārlūks, CSS un JS. Tajos ir uzskaitīti ietvari, kas jums jāzina, platformas, par kurām jums jāierakstās, un jaunas tendences, kuras jums vajadzētu sekot.
Tie ir mūsu mediji. Tās ir lietas, ar kurām mēs būvējam, taču tās nav tas, kas dod projekta panākumus. Izstrādātājs var saprast katru sistēmas detaļu, pateikt katru API un jaunas CSS tehnoloģijas iezīmi, bet tomēr radīt kaut ko neizmantojamu.
Izprotiet barotni
Izstrādātājiem, tāpat kā visiem, ir jāsaprot viņu nesējs, taču viņiem ir jāsaprot arī auditorija, neatkarīgi no tā, vai tie ir lietotāji, komanda vai citi izstrādātāji. Viņiem ir jāsaprot, kā viņu nesējs iekļaujas pasaulē (citiem vārdiem sakot, ražošanas vide) un kādu efektu tam ir (kā cilvēki to izmanto).
Esmu redzējis, ka tas tiek raksturots kā “plašs un dziļš” cilvēks. Plašs, jo jums ir jāsaprot pasaule kā cilvēks, kas strādā ar citiem cilvēkiem. Dziļi, jo jums ir nepieciešamas pamatīgas tehniskās zināšanas, kas ir zemākas par jūsu projekta daļu. Šie izstrādātāji piešķir jūsu projektam milzīgu impulsu un maina projekta tempu, bez kura jūs atradīsit netehnisko personālu, kas ir ieslīgts garlaicīgās detaļās, kas pārplūst no tehnoloģiju komandas.
04. Lietas, ar kurām mēs būvējam
Nesen es pierakstīju sarakstu ar visu, ko mēs izmantojam, lai izveidotu vietnes, pārvaldītu mitināšanu un paveiktu darbu, lai cilvēkiem, kas pievienojušies, pirmajās nedēļās būtu pieejama tehnoloģija, kas jāapgūst. Mēs to uzskatījām par lasītu, ka cilvēki zina šīs lietas, tāpēc, lai dotu jaunajiem darbiniekiem sākumu, mēs uzskaitīsim visu, ko katru dienu izmantojam.
Es gaidīju pusduci tehnoloģiju, bet beidzot ar daudz vairāk. Šajā sarakstā - ‘ko mēs izmantojam’ - ir parastās CMS, programmēšanas valodas un pārlūka tehnoloģijas, bet arī virkne rīku, kurus komanda pat neatcerējās, ka viņi būtu lietojuši. Tā bija visa muskuļu atmiņa. Ierakstot komandrindā ‘git’, ’phing’, ’thor’, mēs pat nedomājām, ka kāds to varētu nedarīt.
Veidot rīkus; CI; Git versiju kontrolei tika pieņemts kā pašsaprotams, taču, atskatoties uz CV, tie gandrīz neparādījās. Modernās parādīsies (un vai ir ciniski, ka, manuprāt, dažas aģentūras tos pievieno ?!), bet bieži vien bez konkrētas pieredzes.
Šie rīki ir svarīgi, lai paātrinātu projekta izstrādi, tāpēc pārliecinieties, ka jums ir daudz bagātāks rīku komplekts nekā jūsu valodā, CMS un pāris ietvari. Jums ir nepieciešama izvietošana, testēšana, CI, spēcīga versiju kontrole (komandās - nevis atsevišķi), un jums ir jāsaprot šo pamatjēdzieni, nevis tikai dažas apmācības.
05. Devops
Šie papildu rīki un triki glīti iekļaujas tajā, ko cilvēki sauc par “devopiem”. Devops lido, saskaroties ar diviem tradicionālajiem silosiem: ražošanu, kas uztur lietas darbībā, un attīstību, kas padara jaunu lietu (un bieži pārtrauc lietu darbību). Tvertņu rezultāts ir divas nometnes ar nelielu līdzjūtību vienam pret otru.
Izstrādātāji bez ražošanas zināšanām biežāk ražo kodu, kas nav piemērots ražošanai, izmantojot konfigurāciju vai funkcijas, kuras vēl nav ražošanas kaudzē. Tā kā viņi neapzinās ražošanas vides problēmas, viņi kodē, lai pabeigtu funkciju, nevis lai to izvietotu ražošanā.
Šīs mazās detaļas var izraisīt sāpīgu kavēšanos, ko pastiprina tendence sūtīt servera pārvaldību uz ārzemēm.
Saprotiet kaudzi
Devops pats par sevi ir milzīgs lauks, kas ietver nepārtrauktu izvietošanu un daudz automatizācijas. Šis ir plašs kopsavilkums, bet galvenais, kas izstrādātājiem jāsaprot, ir kaudze, kurā viņi darbojas. Nepietiek ar to deleģēšanu servera administratoram, jums ir jāsaprot platformas ietekme uz jūsu kodu.
Ja strādājat pie Rails, izlasiet Rails kodu un ziniet, kā Apache izpilda Rubīnu. Ja strādājat Java valodā, uzziniet par konfigurācijas iespējām. Ja izmantojat Perl, izmantojiet Perl moduļus un konfigurējiet tos.
Noslēpumains darbs
Sarakstā “ko mēs izmantojam” ir daudz šo lietu, un labi izstrādātāji to pārspēj, lai saprastu, kā tiek paveikts šis noslēpumainais darbs. Un, kad viņi to saņem, izvietošana notiek ātrāk, darbs tiek izvietots vienmērīgāk un visi ir tikai laimīgāki.
Devops nepārtraukta izvietošana un ar to saistītā prakse kļūst tik standarta, ka jebkurš izstrādātājs vai uzņēmums, kas to nemēģina, ir gatavs tikt apsteigts. Kāds cits sāks to darīt, un tad viņi būs ātrāki par jums.
Ērti instrumenti
Google meklēšana par “devops” sniedz priekšstatu par rīkiem, ko šie puiši izmanto. Tas nav par PHP un MySQL vai Rails. Tas ir par programmatūras piegādi un risku riskantu projektu daļu saglabāšanu bez riska. Viņi koncentrējas uz izvietošanu, automatizāciju un cauruļvada uzturēšanu no izstrādātāja līdz ražošanas videi pēc iespējas ātrāk.
Jūs atklāsiet, ka šis attīstības stils dod izstrādātājiem, kuri labāk sadarbojas savā starpā, kā arī ar citām nodaļām un uzņēmumiem. Ja viņi strādā ar trešās puses API, viņi sapratīs problēmas, kas varētu rasties otrā pusē. Strādājot ar servera administratoriem, viņi sapratīs, kas viņiem jāinstalē, un zinās, kā viņu programmatūras vietnes tiek izvietotas ražošanas serveros. Tas var būt sāpīgi ...
06. Dev to izlabos ... varbūt
Meklējot “būtiskas tīmekļa izstrādātāja prasmes”, Quora piedāvā Maikls Greers (The Onion's CTO) jauku atbildi:
- Slinkums: atsakās kaut ko darīt divreiz: raksta tam skriptu vai algo.
- Gļēvums: domā pārbaudīt, uztraucas par slodzi un koda ietekmi
- Pārgalvība: pastāvīgi izmēģina jaunas lietas, izlaiž idejas tajā pašā dienā
Gļēvulība ir jauks veids, kā formulēt “uzmanību detaļām”. Atkļūdošana un testēšana ir 99 procenti no izstrādātāja dzīves, kuru neviens neminēja, kad viņi nokļuva W3Schools vai sāka skaitļošanas 101 kursu.
Spējai labot lietotnes ir nepieciešamas izcilas problēmu risināšanas prasmes, bet ne tikai koda atkļūdošana. Dažreiz risinājums lietotājiem, kuri nevar lejupielādēt rēķinus, ir padarīt lapu izdrukājamu, nevis pavadīt dienu, veidojot PDF failus. Dažreiz saite var aizstāt izstrādes nedēļu, taču šis elegantais risinājums nenotiks, ja izstrādātāji risina problēmas, tikai rakstot daudzas koda rindas.
Pārbaude ir brīnišķīga neredzamā vieta daudziem izstrādātājiem, neskatoties uz daudzajiem tur esošajiem rīkiem. Izmantojiet vienības testus, selēnu, slodzes testēšanu un profilēšanas rīkus, piemēram, xhprof. Analīze no tādām lietām kā New Relic, lai jūsu lietotnes nospiedums būtu mazs. Uzskatiet to par visu izstrādātāja darba daļu: tas ir jūsu kods, pārliecinieties, ka zināt, ka tas darbojas kā paredzēts, nevis ceru, ka tas darbojas.
Atkļūdošana
Atkļūdošana ir sāpīgs punkts, kā arī. Ne kā izmantot atkļūdotāju, bet gan kā atkļūdot problēmu - tāpēc es papildinātu Maikla Greera sarakstu:
- Nepacietība: agresīvi ignorē neatbilstošu informāciju, lai atrastu un atrisinātu patieso problēmu
Tas ir visu atkļūdošanas paņēmienu stūrakmens. Ignorējot nebūtisko un atrodot jēgu attiecīgajā. Diemžēl daudzi ir pakļauti verdziskam stundu vai dienu kalšanai neatbilstošajam, novēršot problēmu, mēģinot to pašu 10 reizes.
Šīs ir daudzas grāmatas (diemžēl, nevis tās, kuras es nodevu izdevējam un kuras nenosaukšu) par atkļūdošanu, un katram izstrādātājam vajadzētu izlasīt tās visas. Patiesi lielisks izstrādātājs var atkļūdot sistēmas problēmas, neredzot koda rindiņu.
07. Ko lietotāji vēlas
Saprotiet, ko mēģina darīt apkārtējie cilvēki. Izbaudiet kodu - mīlēt mākslu perfekti ievilkt CSS failus vai optimizēt sliedes lietotni, taču atcerieties, ka tas viss ir paredzēts.
Izstrādātājiem ir jāsaprot bizness, operācijas un biznesa procesi, jo viņu lietas palīdz to vadīt. Izstrādātāji ar šīm zināšanām spēj izveidot programmatūru un lietotnes, kas palīdz lietotājiem, taču tās bieži šķiet neparasti produktīvas. Tas varētu būt saistīts ar to, ka viņi ātri drukā, vai ir pārsteidzošas zināšanas par skursteni, taču tas, visticamāk, ir saistīts ar viņu zināšanām par lietotāju vēlmēm.
Konkurētspējīgs tirgus
Atgriežoties pie sākotnējā viedokļa, attīstība kļūst vieglāka un lielisku izstrādātāju tirgus ir konkurētspējīgāks jebkuram izstrādātājam, kurš spēj izprast uzņēmējdarbības prasības un sniegt kaut ko izcilu, lai tās izpildītu, būs priekšrocība. Palīdz izprast tirgu, klientus un to, kāpēc cilvēki šķiras no naudas.
Izprotiet datus un to, kā tie laika gaitā mainīsies. Izstrādātāja prātā viņiem būtu jāizklāsta jaunās tehnoloģijas ar izaicinājumiem, kas jums šodien rodas vai kurus redzat. Tādā veidā, kad jūs MD vai klientam iesakāt jaunu iedomātu ideju, tā tiks balstīta uz to, ko klienti patiešām vēlas, un jūs saņemsiet tai paredzēto budžetu / laiku. (Turpretī vissliktākais liecinieks ir tas, ka izstrādātāji izmanto savu jauno iecienīto tehnoloģiju kā risinājumu visām mūsu nedienām.)
Izstrādātājiem ir liela kontrole - vai viņiem ir jāzina, ko katrs datu bāzes lauks nozīmē galalietotājam? Ja mēs mainīsim datus, ko lietotāji redzēs? Vai ir kāds labāks veids, kā palīdzēt lietotājiem? Pārāk bieži DB administratoru viedoklis ir tāds, ka pasaule slikti atspoguļo viņu datu bāzi, nevis viņu datu bāze ir slikta reālās pasaules attēlojums. Pasaule ir juceklīga un pārsteidzoši pilna ar malām. Nodarbojieties ar to, DB administratori.
08. Zīmēšana un rakstīšana
Zīmēšana ir vistiešākais saziņas veids, kāda būs. Izstrādātājiem jāspēj uzzīmēt savas idejas uz tāfeles, papīra un alus paklājiem.
Izstrādātājiem ir jāspēj prototipēt uz papīra, izdrukāt ekrānuzņēmumus un uz tiem uzskribelēt, lai tikai paziņotu par savu nodomu. Neuzticieties izstrādātājam, kurš pamāj ar galvu, saka, ka saprot un atver savu redaktoru.
Neveiksmīgi lēti: vislabākā kodēšana sākas ar zīmēšanu kā ātru prototipu. Neveiciet biežāk un pārliecinieties, ka visas apkārtējās devas rīkojas tāpat kā jūs, visticamāk, tādā veidā gūsiet panākumus.
09. Izbaudi sevi
Un ko tad, ja jums jāpavada 10 stundas problēmas risināšanai, pārvietojot saiti apkārt? Izbaudiet to - pat ja tas ir tikai izaicinājums iegūt darbu.
Vissliktākā izstrādātāju (vai jebkura cita) attieksme ir apātija pret to, ko komanda cenšas sasniegt. Diemžēl tas ir bieži, jo izstrādātāji uzskata sevi par ārpus komandas sasniegtajiem mērķiem. (Kaislīgais programmētājs uzdod jautājumu: “Cik daudz jautrāk jūs varētu padarīt savu darbu?” - izmēģiniet to.)
Esiet gatavs parādīt savu darbu, jo tas ir tieši otrādi: nepaplašiniet, izmēģinot pāris Ruby apmācības līdz ‘Ruby Experience’!
Tīmekļa un lietotņu izstrāde joprojām ir jauna profesija, taču prasmju kopums, kas patiešām ir ļoti vajadzīgs, tiek paplašināts. Ikvienam vajadzētu sagaidīt vairāk izstrādātāju, jo jo ātrāk mēs visi iznāksim no nepatīkamās aizmugures istabas un iesaistīsimies radošajā procesā, jo labāki būs rezultāti.
10. Palieciet asi
Lai to paveiktu jaukā kārtā 10, es pievienošu vēl vienu lietu. Palieciet asi. Atrodiet konkurenci. Vissliktākais veids ir izolēts.
"Vienmēr esi sliktākais puisis katrā grupā, kurā esi."
Sliktākie - tiešām, ļoti sliktie - programmētāji, kodētāji, dizaineri apgūst savas lietas un atpūšas uz lauriem. Bez elektrokardiostimulatora ir pārāk viegli palēnināt ātrumu, un, neredzot konkurenci, kļūst paradums redzēt sevi virs vidējā līmeņa.
Tāpēc esiet sliktākais, ko varat atrast, atrodot labāku. Pievienojieties projektiem ārpus darba, sniedziet ieguldījumu un meklējiet atsauksmes un kritiku, jo jo vairāk kritikas jūs saņemsiet, jo mazāk cilvēki jums sniegs nākotnē. Kad jūs uzminat, ko viņi vēlas labāk nekā viņi ir, tad jūs esat ninja izstrādātājs, ko visi vēlas.
Dens Frosts ir pilna servisa tīmekļa uzņēmuma 3EV tehniskais direktors, oficiāls AWS partneris. Viņš septiņus gadus strādā CMS un tīmekļa lietotņu izstrādē.
Patika tas? Izlasiet šos!
- Kā izveidot lietotni
- Labākie bezmaksas web fonti dizaineriem
- Atklājiet paplašinātās realitātes iespējas
