Dit is gaaf om 'n JavaScript-ontwikkelaar te wees, want die behoefte aan goeie JS-programmeerders groei voortdurend in die arbeidsmark. Daar is deesdae baie raamwerke, biblioteke en ander dinge wat in die werk gebruik kan word – en tot 'n groot mate moet ons oopbronbronne daarvoor dankbaar wees. Maar op 'n stadium begin 'n ontwikkelaar te veel tyd aan JS-projekte spandeer in vergelyking met alle ander take.
Dit is baie waarskynlik dat dit in die toekoms tot rampspoedige gevolge vir jou loopbaan sal lei, maar jy besef dit nog nie. Ek het self van die foute wat hieronder beskryf word in die verlede gemaak, en nou wil ek jou daarteen beskerm. Hier is agt JS-ontwikkelaarfoute wat jou toekoms minder as blink kan maak.
Ons herinner: vir alle lesers van "Habr" - 'n afslag van 10 000 roebels wanneer u inskryf vir enige Skillbox-kursus met behulp van die "Habr"-promosiekode.
Skillbox beveel aan: Opvoedkundige aanlyn kursus .
Gebruik jQuery
jQuery het 'n groot rol gespeel in die ontwikkeling van die hele JavaScript-ekosisteem. Aanvanklik is JS gebruik om skyfievertonings en verskillende soorte widgets, beeldgalerye vir webwerwe te skep. jQuery het dit moontlik gemaak om van probleme met kodeversoenbaarheid tussen verskillende blaaiers te vergeet, die gebruik van abstraksievlakke te standaardiseer en met die DOM te werk. Op sy beurt het dit gehelp om AJAX en probleme met kruisblaaierverskille te vereenvoudig.
Vandag is hierdie probleme egter nie so relevant soos voorheen nie. Die meeste daarvan is opgelos deur standaardisering – dit gaan byvoorbeeld om haal- en API-keurders.
Die oorblywende probleme word deur ander biblioteke soos React opgelos. Biblioteke bied baie ander kenmerke wat jQuery nie het nie.
Wanneer jy met jQuery werk, begin jy op 'n stadium vreemde dinge doen, soos die gebruik van DOM-elemente as huidige toestande of data, en die skryf van verskriklike komplekse kode net om uit te vind wat fout is met die vorige, huidige en toekomstige toestand van die DOM. om behoorlike oorgang na komende state te verseker.
Daar is niks teen die gebruik van jQuery nie, maar neem die tyd om meer te wete te kom oor die meer moderne alternatiewe—React, Vue en Angular—en hul voordele.
Vermy eenheidstoetsing
Ek sien dikwels dat mense eenheidstoetse vir hul webtoepassings ignoreer. Alles gaan goed totdat die toepassing ineenstort met 'n "onverwagte fout". En op hierdie oomblik kry ons 'n groot probleem omdat ons tyd en geld verloor.
Ja, as 'n toepassing normaal saamstel sonder om foute te produseer, en sodra dit saamgestel is, werk dit, beteken dit nie dat dit gereed is vir gebruik nie.
Gebrek aan toetsing is selfs min of meer aanvaarbaar vir klein toepassings. Maar wanneer programme groot en kompleks is, is dit moeilik om te onderhou. Daarom word toetse 'n uiters belangrike element van ontwikkeling. Op hierdie manier sal die verandering van een toepassingskomponent nie 'n ander breek nie.
Begin gebruik .
Leerraamwerke voor JavaScript
Ek verstaan volkome diegene wat, wanneer hulle 'n webtoepassing begin ontwikkel, dadelik gewilde biblioteke en raamwerke soos React, Vue of Angular begin gebruik.
Ek het vroeër gesê dat jy eers JavaScript moet leer en dan die raamwerke, maar nou is ek oortuig dat jy dit alles op dieselfde tyd moet doen. JS verander uiters vinnig, so jy moet ervaring opdoen met React, Vue of Angular op dieselfde tyd as om JavaScript te leer.
Dit begin die vereistes wat aan kandidate vir die pos van ontwikkelaar gestel word, beïnvloed. Dit is byvoorbeeld wat ek gevind het toe ek na “JavaScript” op Indeed gesoek het.
Die posbeskrywing sê hulle benodig kennis van jQuery EN JavaScript. Dié. Vir hierdie maatskappy is albei komponente ewe belangrik.
Hier is nog 'n beskrywing wat slegs die "basiese" vereistes lys:
En dit gebeur in omtrent die helfte van die vakatures waarna ek gekyk het. Ek glo egter dat die korrekte verhouding van tyd om JS en raamwerke te leer ongeveer 65% tot 35% is, nie 50 tot 50 nie.
Onwilligheid om vertroud te raak met die konsep van "skoon kode"
Elke aspirant-ontwikkelaar moet leer om skoon kode te skep as hulle 'n professionele persoon wil word. Dit is die moeite werd om jouself te vergewis van die konsep van "skoon kode" aan die begin van jou loopbaan. Hoe gouer jy hierdie konsep begin volg, hoe gouer sal jy gewoond raak daaraan om skoon kode te skryf wat later maklik is om te onderhou.
Terloops, om die voordele van goeie en skoon kode te verstaan, hoef jy nie self slegte kode te probeer skryf nie. Jou vaardighede sal later handig te pas kom, by die werk, wanneer jy verskrik is oor iemand anders se slegte kode.
Begin te vroeg werk aan groot projekte
Vroeg in my loopbaan het ek ’n groot fout gemaak: Ek het probeer om ’n groot projek aan te pak toe ek nog nie gereed was daarvoor nie.
Jy kan vra wat hier fout is. Daar is 'n antwoord. Die feit is dat as jy nie 'n middel of senior is nie, dan sal jy heel waarskynlik nie jou "groot projek" kan voltooi nie. Daar sal te veel elemente en dinge wees om te oorweeg. En jy sal nie kan klaarkom as jy aan die begin van jou loopbaan nie die gewoonte ontwikkel het om "skoon kode" te skryf nie, toetse, skaalbare argitektuur, ens.
Kom ons sê jy het baie tyd aan hierdie projek bestee, dit nie voltooi nie en probeer nou na die middelvlak beweeg. En dan besef jy skielik dat jy hierdie kode aan niemand kan wys nie, want dit is nie baie goed nie en moet herfaktoreer word. Jy het egter baie tyd aan hierdie “projek van die eeu” bestee en nou het jy geen voorbeelde van goeie werk om by jou portefeulje te voeg nie. En jy verloor die een onderhoud ná die ander vir daardie kandidate wat hul werk, al is dit nie baie groot nie, in 'n portefeulje kan wys.
In elk geval, in die toekoms sal jy moet herfaktor, aangesien die kode nie baie goed is nie, en die tegnologieë wat jy gebruik het, is nie presies wat jy nodig het nie. Gevolglik besef jy dat dit makliker is om alles van nuuts af te herskryf as om dit te probeer regmaak.
Dit alles kan natuurlik by jou portefeulje gevoeg word, maar ’n potensiële werkgewer sal baie tekortkominge daar sien en tot gevolgtrekkings kom wat vir jou teleurstellend is.
Onwilligheid om datastrukture en algoritmes te leer
Jy kan lank stry oor wanneer jy datastruktuur en algoritmes moet begin bestudeer. Sommige mense stel voor om dit te doen voordat hulle JavaScript bemeester, ander daarna.
Ek glo dat dit nie nodig is om dit aan die begin in detail te leer nie, maar dit is die moeite werd om die algoritmes te verstaan, aangesien dit 'n basiese begrip van die werk van rekenaarprogramme en berekeninge sal gee.
Algoritmes is 'n integrale deel van enige berekeninge en programme. Eintlik is rekenaarprogramme self 'n kombinasie van 'n stel algoritmes en data wat op 'n sekere manier gestruktureer is, dit is al.
Weiering van fisiese aktiwiteit
Dit is baie belangrik vir 'n ontwikkelaar om sport te speel. Ek is nie 'n afrigter nie, maar ek het jaar na jaar gesien hoe my liggaam verander. Daarom kan ek jou vertel waartoe die gebrek aan fisiese oefening lei.
My eerste werk was om verskeie redes nogal problematies, en een van die probleme was dat ek in net 'n jaar amper twee dosyn kilogram opgetel het. Toe het ek JavaScript aktief bestudeer.
As jy nie oefen nie, loop jy die risiko om gewig op te tel, en dit sal baie negatiewe gevolge hê: vetsug, migraine (insluitend chroniese), hoë bloeddruk, ens. Die lys van probleme is werklik eindeloos.
Sosiale self-isolasie
Familie en geliefdes is belangrik. Deur jouself te verdiep in die aanleer van JavaScript en die belangrikheid van jou geestelike en emosionele lewe te onderskat, loop jy die risiko om depressief te raak, prikkelbaar te raak, nie lekker te slaap nie, en nog baie meer.
Bevindinge
Ek hoop van hierdie is nuttig vir jou. As jy vandag vir jouself sorg, hoef jy nie later foute reg te stel nie.
Skillbox beveel aan:
- Praktiese kursus .
- Toegepaste aanlyn kursus .
- Twee-jaar praktiese kursus .
Bron: will.com