10 gjëra që zhvilluesit e internetit duhet të dinë për t'u bërë vërtet mahnitëse

Përmbajtje

• 01. Kodimi mos e prerë më
• Gjerësia dhe thellësia
• 02. Paralajmërimi i madh
• 03. Çfarë thotë interneti
• Kuptoni mediumin
• 04. Gjërat me të cilat ndërtojmë
• 05. Devops
• Kuptoni pirgun
• Punë misterioze
• Vegla praktike
• 06. Dev do ta rregullojë ... mbase
• Korrigjimi i gabimeve
• 07. Çfarë duan përdoruesit
• Tregu konkurrues
• 08. Vizatimi dhe shkrimi
• 09. Kënaquni
• 10. Qëndroni të mprehtë
• Te pelqen kjo? Lexoni këto!

Zhvilluesit duhet të jenë më shumë sesa punëtorë zhgënjyes që krijojnë kod. Ne jemi duke pritur më shumë nga jeta jonë dixhitale dhe janë këta njerëz që e ndërtojnë atë, kështu që çfarë duhet të dinë devs më të mirë? Këtu janë gjërat që unë shoh duke humbur nga shumë zhvillues. Kjo nuk është shteruese por janë këto cilësi që e kthejnë një kodues të arsyeshëm në një zhvillues të mahnitshëm.

Por nuk është një gjë, dhe sidomos nuk është kurrë aftësia për të analizuar XML ose për të optimizuar kodin. It’sshtë një koleksion i habitshëm aftësish që nuk mësohen në librat për të shkruar kodin. Ata janë pak diçka shtesë.

Pse shfryj kështu? Për shkak se zhvillimi ka rëndësi, por zhvilluesit shpesh dërgohen në një botë tjetër, jo gjithmonë të krijimit të tyre. Kjo nuk funksionon kurrë. Zhvillimi - çdo gjë teknike - gjithmonë lulëzon kur ata që dinë të kuptojnë më shumë sesa thjesht kodin.

01. Kodimi mos e prerë më

Jemi në një botë ku kodimi po bëhet më pak mbresëlënës. Të gjithë ndërtojnë faqe, disa prej tyre kodojnë por ju nuk keni pse. Nuk është më vetëm budallai që mund të krijojë faqe, aplikacione dhe veçori.

Që kur u krijua uebi dhe njerëzit mund të mësonin veten e tyre, ka pasur zhvillues të vetë-mësuar. Por edhe maturantët janë nën kërcënim. Unë marr CV me njerëz me diploma të shkencave kompjuterike, kurse AI, media të ndryshme dhe kodim nën rripat e tyre, por ende ka diçka që mungon. Ndonjëherë shumë mungon.

Unë nuk jam i pari që e them këtë. 'Kodimi mos e prit më' është titulli i kapitullit 3 nga Programuesi i Pasionuar, i cili së bashku me libra të tillë si Të menduarit dhe të mësuarit pragmatik nxisni programuesit të përmirësojnë veten përtej kodit; të bëhen anëtarë të përgjegjshëm dhe plotësisht njerëzorë të ekipit.

Gjerësia dhe thellësia

Zhvilluesit duhet të jenë më të mirë në dy mënyra: gjerësia dhe thellësia. Ata duhet të kuptojnë gjerësinë e ndërveprimeve njerëzore në ekipin e tyre dhe me gjërat që ndërtojnë. Ata duhet të kuptojnë thellësinë e sistemit me të cilin po punojnë, deri në O / S.

Dhe nuk janë vetëm zhvilluesit që duhet të lexojnë këto gjëra. Nëse jeni duke punuar me devs, mendoj se duhet të prisni më shumë prej tyre. Bëni të skicojnë atë për të cilën po flasin. Bëni që të shpjegojnë me fotografi, objekte dhe (funksionon) prerje njerëzish saktësisht se si do të jetë sistemi për njerëzit që e përdorin atë.

02. Paralajmërimi i madh

Unë do të flas negativisht për zhvilluesit, por mendoj se më lejohet sepse jam një. Gjithashtu sepse të paktën një gjë për të cilën flas këtu është e vërtetë për shumë nga zhvilluesit që takoj. Edhe pse puna e tyre është e shkëlqyeshme dhe ata e dinë kodin e tyre, kohët janë konkurruese. Ju duhet të keni një avantazh, dhe kjo është:

• të jetë më teknik

dhe

• të jetë shumë me njerezore

03. Çfarë thotë interneti

Googling për 'aftësitë thelbësore të zhvillimit të uebit' sjell atë që prisni. Njohuri kornizë, x-browser, CSS dhe JS. Ata rendisin kornizat që duhet të njihni, platformat për të cilat duhet të shkruani dhe tendencat e reja që duhet të vëzhgoni.

Këto janë mediat tona. Ato janë gjërat me të cilat ndërtojmë, por nuk janë ato që i japin sukses një projekti. Një zhvillues mund të kuptojë çdo detaj të sistemit, t'ju tregojë çdo tipar të një API dhe një teknologjie të re CSS, por përsëri prodhon diçka të papërdorshme.

Kuptoni mediumin

Zhvilluesit, si të gjithë, duhet të kuptojnë mediumin e tyre - por ata gjithashtu duhet të kuptojnë audiencën, qoftë nga përdoruesit, ekipi ose zhvilluesit e tjerë. Ata duhet të kuptojnë se si mediumi i tyre përshtatet në botë (me fjalë të tjera, mjedisi i prodhimit) dhe çfarë efekti ka (si e përdorin njerëzit).

Unë e kam parë këtë të përshkruar si personin 'e gjerë dhe e thellë'. E gjerë, sepse duhet ta kuptoni botën si një njeri që punon me njerëz të tjerë. Thellë sepse keni nevojë për njohuri teknike të plota nën nivelin e pjesës suaj të projektit. Këta zhvillues i japin projektit tuaj një nxitje të madhe dhe ndryshojnë ritmin e projektit, pa të cilin do të gjeni staf jo-teknik të zhytur në detaje të lodhshme që vërshojnë nga ekipi i teknologjisë.

04. Gjërat me të cilat ndërtojmë

Kohët e fundit kam shkruar një listë të gjithçkaje që ne përdorim për të ndërtuar faqe, për të menaxhuar hostimin dhe për të bërë gjëra në mënyrë që njerëzit që bashkohen të kenë një fletë mashtrimi teknologjish për të mësuar në javët e para. Ne po e kuptonim si të lexuar që njerëzit i dinin këto gjëra, kështu që për t'u dhënë fillimin rekrutëve të rinj do të rendisnim gjithçka që përdorim çdo ditë.

Unë prisja gjysmë duzinë teknologjish por përfundova me shumë më tepër. Kjo listë - 'ajo që ne përdorim' - përfshin CMS-et e zakonshme, gjuhët e programimit dhe teknologjitë e shfletuesit, por gjithashtu një bandë mjetesh që ekipi as nuk i mbante mend vetë duke përdorur. Ishte e gjithë kujtesa e muskujve. Shtypja 'git', 'phing', 'thor' në rreshtin e komandës, ne as nuk mendonim se dikush mund të mos e bënte.

Mjete ndërtimi; CI; git për kontrollin e versionit u mor si e mirëqenë, por duke parë pas CV-ve këto vështirë se dukeshin. Do të shfaqeshin ato të modës (dhe a është cinike që unë mendoj se agjenci të caktuara i shtojnë ato brenda ?!) por shpesh pa përvojë konkrete.

Këto mjete janë të rëndësishme për përshpejtimin e zhvillimit të projektit, prandaj sigurohuni që të keni një mjet shumë më të pasur se sa gjuha juaj, CMS dhe disa korniza. Keni nevojë për vendosje, testim, CI, kontroll të fortë të versionit (në ekipe - jo vetë), dhe duhet të kuptoni konceptet thelbësore të këtyre sesa vetëm disa udhëzime.

05. Devops

Këto mjete dhe marifete shtesë përshtaten mjeshtërisht në atë që njerëzit po e quajnë "devops". Devops fluturon përballë dy kapanoneve tradicionale: prodhimi, i cili i mban gjërat në punë dhe zhvillimi, i cili bën gjëra të reja (dhe shpesh i ndalon gjërat të funksionojnë). Silot rezultojnë në dy kampe me pak simpati për njëri-tjetrin.

Zhvilluesit pa njohuri prodhimi prodhojnë më shpesh kod që nuk është i përshtatshëm për prodhim, duke përdorur konfigurimin ose tiparet që nuk janë ende në stekun e prodhimit. Për shkak se ata nuk janë të vetëdijshëm për problemet e mjedisit të prodhimit, ata kodojnë për të kompletuar tiparin sesa për ta vendosur atë në prodhim.

Këto detaje të vogla mund të krijojnë vonesa të dhimbshme, të përkeqësuara nga tendenca për dërgimin e menaxhimit të serverit jashtë vendit.

Kuptoni pirgun

Devops është një fushë e madhe në vetvete, që përfshin vendosjen e vazhdueshme dhe shumë automatizime. Kjo është një përmbledhje gjithëpërfshirëse, por gjëja kryesore që zhvilluesit duhet të kuptojnë është pirgja në të cilën po ekzekutojnë. Nuk mjafton ta delegosh këtë te administratori i serverit, duhet të kuptosh implikimet që ka platforma në kodin tënd.

Nëse punoni në Rails, lexoni kodin Rails dhe dini se si Ruby ekzekutohet nga Apache. Nëse punoni në Java, dini rreth opsioneve të konfigurimit. Nëse është Perl që ju përdorni, kuptoni se si të instaloni modulet Perl dhe t'i konfiguroni ato.

Punë misterioze

Lista e 'asaj që ne përdorim' përmban shumë nga këto gjëra, dhe zhvilluesit e mirë kapërcejnë atë për të kuptuar se si bëhet e gjithë kjo punë misterioze. Dhe sapo ta marrin atë, vendosjet shkojnë më shpejt, puna vendoset më mirë dhe të gjithë janë më të lumtur.

Vendosja e vazhdueshme dhe praktikat e ndërlidhura të devops po bëhen aq standarde saqë çdo zhvillues ose kompani që nuk e praktikon këtë po vendos që të kapërcehet. Dikush tjetër do të fillojë ta bëjë atë dhe atëherë ata do të jenë më të shpejtë se ju.

Vegla praktike

Googling për 'devops' ju jep një ide të mjeteve që përdorin këta njerëz. Nuk ka të bëjë me PHP dhe MySQL, ose Rails. Bëhet fjalë për transportimin e programeve dhe mbajtjen e pjesëve të rrezikshme të projekteve pa rrezik. Ato përqendrohen në vendosjen, automatizimin dhe mbajtjen e tubacionit nga zhvilluesi në mjedisin e prodhimit që funksionon sa më shpejt që të jetë e mundur.

Do të zbuloni se ky stil i zhvillimit ju jep zhvillues që punojnë më mirë me njëri-tjetrin dhe me departamente dhe kompani të tjera. Nëse ata janë duke punuar me një API nga një palë e tretë, ata do të kuptojnë problemet që mund të shfaqen në anën tjetër. Kur punojnë me administratorët e serverit ata do të kuptojnë se çfarë u duhet të instalojnë dhe të dinë se si faqet e tyre të softuerit në serverat e prodhimit. E kundërta e kësaj mund të jetë e dhimbshme ...

06. Dev do ta rregullojë ... mbase

Ky kërkim për 'aftësitë thelbësore të krijuesit të uebit' sjell një përgjigje të këndshme nga Michael Greer (CTO e Qepës) në Quora:

• Përtacia: Refuzon të bëjë diçka dy herë: shkruan një skenar ose algo për të.
• Frikacak: Mendon për të provuar, shqetësime për ngarkesën dhe ndikimin e kodit
• Pakujdesia: Provon gjëra të reja vazhdimisht, lëshon ide të së njëjtës ditë

Frikacia është një mënyrë e mirë për të shprehur 'vëmendjen në detaje'. Korrigjimi i gabimeve dhe testimi është 99 përqind e jetës së një zhvilluesi, askush nuk përmend kur ata goditën W3Schools ose filluan kursin e llogaritjes 101.

Aftësia për të rregulluar aplikacionet kërkon aftësi të shkëlqyera për zgjidhjen e problemeve, por jo vetëm për korrigjimin e kodit. Ndonjëherë zgjidhja për përdoruesit që nuk janë në gjendje të shkarkojnë faturat e tyre është ta bëjnë faqen të shtypshme, në vend se të kalojnë një ditë duke gjeneruar PDF. Ndonjëherë një lidhje mund të zëvendësojë një javë zhvillimi, por ajo zgjidhje elegante nuk do të ndodhë nëse devs po zgjidhin problemet thjesht duke shkruar shumë rreshta kodi.

Testimi është një njollë e mrekullueshme për shumë devs, pavarësisht nga mjetet e shumta atje. Përdorni testet e njësive, selenin, testimin e ngarkesës dhe mjetet e profilizimit siç është xhprof. Analizë nga gjëra të tilla si New Relic për të mbajtur gjurmën e aplikacionit tuaj të vogël. Dhe konsiderojeni këtë të gjithë pjesë të punës së dev-it: është kodi juaj, sigurohuni që e dini se funksionon siç është menduar, sesa të shpresoni se do të funksionojë.

Korrigjimi i gabimeve

Debuging është gjithashtu një pikë e lënduar. Jo si të përdorësh një korrigjues, por si të korrigjosh një problem - kështu që unë do të shtoja në listën e Michael Greer:

• Padurimi: në mënyrë agresive injoron informacione të parëndësishme për të gjetur dhe zgjidhur problemin e vërtetë

Ky është themeli i të gjitha teknikave të korrigjimit të gabimeve. Injorimi i pavend dhe gjetja e kuptimit në atë përkatëse. Fatkeqësisht, shumë janë të prirur të godasin me skllavëri të parëndësishme për orë ose ditë, duke rregulluar një problem duke provuar të njëjtën gjë 10 herë.

Janë shumë libra (fatkeqësisht, jo ai që i dhashë botuesit që nuk do ta përmend) për korrigjimin e gabimeve dhe çdo zhvillues duhet t'i lexojë të gjithë. Një dev me të vërtetë i shkëlqyeshëm mund të korrigjojë problemet në një sistem pa parë një linjë kodi.

07. Çfarë duan përdoruesit

Kuptoni se çfarë po përpiqen të bëjnë njerëzit përreth jush. Shijoni kodin - dashuroni artin e prerjes së skedarëve CSS në mënyrë të përsosur, ose optimizimin e një aplikacioni binarë - por mos harroni se e gjitha është për një qëllim.

Zhvilluesit duhet të kuptojnë biznesin, operacionet dhe proceset e biznesit sepse gjërat e tyre ndihmojnë në drejtimin e tij. Dev-et me këtë njohuri janë në gjendje të ndërtojnë softuer dhe aplikacione që ndihmojnë përdoruesit, por ato shpesh duken jashtëzakonisht produktive. Kjo mund të jetë për shkak të ndriçimit të tyre të shtypur shpejt ose njohurive të mahnitshme të pirgut, por ka më shumë të ngjarë të jetë për shkak të njohurive të tyre për atë që përdoruesit duan.

Tregu konkurrues

Kthimi në pikën time origjinale, se zhvillimi po bëhet më i lehtë dhe tregu për zhvilluesit e mëdhenj është më konkurrues çdo zhvillues që është në gjendje të kuptojë kërkesat e biznesit dhe të sjellë diçka të shkëlqyeshme për t'i përmbushur ato, do të ketë një avantazh. Kuptoni tregun, klientët dhe pse ata njerëz që ndahen me para, të gjitha ndihmojnë.

Kuptoni të dhënat dhe si ato do të ndryshojnë me kalimin e kohës. Në mendjen e zhvilluesit, ata duhet të rreshtojnë teknologjitë e reja me sfidat që keni sot ose shihni që vijnë. Në këtë mënyrë, kur i sugjeroni një ide të re zbukuruese MD ose një klienti, ajo do të bazohet në atë që klientët me të vërtetë duan dhe ju do të merrni buxhetin / kohën mbi të. (Në të kundërt, gjëja më e keqe për të parë është zhvilluesit që kërkojnë teknologjinë e tyre të re të preferuar si zgjidhja për të gjitha sëmundjet tona.)

Zhvilluesit kanë shumë kontroll - a duhet të dinë ata se çfarë do të thotë secila fushë në bazën e të dhënave për përdoruesin përfundimtar? Nëse i ndryshojmë të dhënat, çfarë do të shohin përdoruesit? A ka ndonjë mënyrë më të mirë për të ndihmuar përdoruesit? Shumë shpesh pikëpamja e administratorëve të DB është se bota është një reflektim i keq i bazës së të dhënave se sa baza e të dhënave të tyre është një përfaqësim i keq i botës reale. Bota është rrëmujë dhe çuditërisht e mbushur me raste. Merreni me të, administratorët e DB.

08. Vizatimi dhe shkrimi

Vizatimi është mënyra më e drejtpërdrejtë e komunikimit se si do të jenë gjërat. Zhvilluesit duhet të jenë në gjendje të tërheqin idetë e tyre në dërrasat e bardha, letrat dhe birrat.

Zhvilluesit duhet të jenë në gjendje të prototipojnë në letër, të shtypin pamje nga ekrani dhe të shkarraviten mbi to vetëm për të komunikuar qëllimin e tyre. Mos i beso zhvilluesit që tund kokën, thotë se ata e kanë kuptuar dhe hap redaktorin e tyre.

Dështoni me lehtësi: kodimi më i mirë fillon me vizatimin si një prototip i shpejtë. Dështoni më shpesh dhe sigurohuni që të gjitha devot përreth jush të bëjnë të njëjtën gjë pasi ka më shumë të ngjarë të keni sukses në atë mënyrë.

09. Kënaquni

Dhe çka nëse duhet të kaloni 10 orë duke zgjidhur një problem duke lëvizur një lidhje? Shijojeni atë - edhe nëse është vetëm sfida për të kaluar punën.

Qëndrimi më i keq nga zhvilluesit (ose kushdo) është apatia ndaj asaj që ekipi po përpiqet të arrijë. Për fat të keq kjo është e zakonshme, sepse zhvilluesit e shohin veten e tyre si jashtë asaj që ekipi po arrin. (Programuesi i Pasionuar shtron pyetjen, 'sa më shumë argëtim mund ta bëni punën tuaj?' - provojeni.)
Dhe jini të gatshëm të tregoni punën tuaj pasi e kundërta e kësaj është: mos u zgjeroni duke provuar disa udhëzime për Ruby në 'Experience of Ruby'!

Zhvillimi i faqeve në internet dhe aplikacioneve është akoma një profesion i ri, por aftësia që ka nevojë për devs shumë të mëdha po zgjerohet. Të gjithë duhet të presin më shumë nga zhvilluesit sepse sa më shpejt që të gjithë të dalim nga dhoma e pasme e keqe dhe të përfshihemi në procesin krijues aq më të mira do të jenë rezultatet.

10. Qëndroni të mprehtë

Për ta sjellë këtë në një raund të bukur 10, unë do të shtoj një gjë të fundit. Qëndro i mprehtë. Gjeni konkurrencën. Lloji më i keq i gjithçkaje është ai në izolim.

"Gjithmonë jini djali më i keq në çdo bandë në të cilën jeni".

Më e keqja - me të vërtetë, shumë e keqe - programuesit, koduesit, dizajnerët mësojnë gjërat e tyre dhe pushojnë në dafinat e tyre. Pa një stimulues kardiak, është shumë e lehtë të ngadalësosh dhe pa parë konkurrencën bëhet zakon të shohësh veten mbi mesataren.

Pra, ji më i keq që mundesh duke gjetur më mirë. Bashkohuni me projekte jashtë punës, kontribuoni dhe kërkoni reagime dhe kritika sepse sa më shumë kritikë të merrni, aq më pak njerëz do t'ju japin në të ardhmen. Kur po mendoni se çfarë duan më mirë sesa janë, atëherë ju jeni zhvilluesi i ninja që të gjithë duan.

Dan Frost është drejtor teknik i ndërmarrjes me shërbim të plotë 3EV, një partner zyrtar i AWS. Ai ka punuar në CMS dhe zhvillimin e aplikacioneve në internet për shtatë vjet.

Te pelqen kjo? Lexoni këto!

• Si të krijoni një aplikacion
• Fontet më të mira falas në internet për dizajnerët
• Zbuloni se çfarë është më tej për Realitetin e Zgjeruar