In JavaScript-ûntwikkelder wêze is cool, om't de needsaak foar goede JS-programmeurs konstant groeit op 'e arbeidsmerk. Tsjintwurdich binne d'r in protte kaders, biblioteken en oare dingen dy't brûkt wurde kinne yn it wurk - en foar in grut part moatte wy iepen boarne boarnen tankber wêze foar dit. Mar op in stuit begjint in ûntwikkelder tefolle tiid te besteegjen oan JS-projekten yn ferliking mei alle oare taken.
It is heul wierskynlik dat dit yn 'e takomst liede sil ta desastreuze gefolgen foar jo karriêre, mar jo realisearje it noch net. Ik sels haw makke guon fan de flaters beskreaun hjirûnder yn it ferline, en no wol ik jo beskermje derfan. Hjir binne acht JS-ûntwikkeldersflaters dy't jo takomst minder dan helder kinne meitsje.
Wy herinnerje: foar alle lêzers fan "Habr" - in koarting fan 10 roebel by it ynskriuwen fan in Skillbox-kursus mei de promoasjekoade "Habr".
Skillbox advisearret: Edukative online kursus .
Mei help fan jQuery
jQuery hat in enoarme rol spile yn 'e ûntwikkeling fan it heule JavaScript-ekosysteem. Yn it earstoan waard JS brûkt om diashows en ferskate soarten widgets, ôfbyldingsgaleryen foar websiden te meitsjen. jQuery makke it mooglik om te ferjitten oer problemen mei koade kompatibiliteit tusken ferskate browsers, standerdisearring fan it brûken fan abstraksje nivo en wurkjen mei de DOM. Op syn beurt holp dit AJAX en problemen mei cross-browser ferskillen te ferienfâldigjen.
Lykwols, hjoed dizze problemen binne net sa relevant as foarhinne. De measten fan harren waarden oplost troch standerdisearring - dit giet bygelyks om fetch- en API-selektors.
De oerbleaune problemen wurde oplost troch oare bibleteken lykas React. Biblioteken jouwe in protte oare funksjes dy't jQuery net hat.
As jo wurkje mei jQuery, begjinne jo op in stuit frjemde dingen te dwaan, lykas it brûken fan DOM-eleminten as aktuele steaten of gegevens, en it skriuwen fan ôfgryslike komplekse koade gewoan om út te finen wat der mis is mei de foarige, hjoeddeistige en takomstige steat fan 'e DOM , boppedat. om in goede oergong nei kommende steaten te garandearjen.
D'r is neat tsjin it brûken fan jQuery, mar nim de tiid om mear te learen oer de modernere alternativen - React, Vue en Angular - en har foardielen.
It foarkommen fan ienheidstesten
Ik sjoch faak dat minsken ienheidstests negearje foar har webapplikaasjes. Alles giet geweldich oant de applikaasje crasht mei in "ûnferwachte flater". En op dit stuit krije wy in grut probleem om't wy tiid en jild ferlieze.
Ja, as in applikaasje normaal kompilearret sûnder flaters te produsearjen, en ienris kompilearre wurket, betsjut dit net dat it klear is foar gebrûk.
Gebrek oan testen is noch mear of minder akseptabel foar lytse applikaasjes. Mar as programma's grut en kompleks binne, binne se lestich te ûnderhâlden. Dêrom wurde testen in ekstreem wichtich elemint fan ûntwikkeling. Op dizze manier sil it feroarjen fan ien applikaasjekomponint in oare net brekke.
Begjin te brûken .
Learkaders foardat JavaScript
Ik begryp perfekt dyjingen dy't, as se begjinne mei it ûntwikkeljen fan in webapplikaasje, fuortendaliks begjinne mei it brûken fan populêre bibleteken en kaders lykas React, Vue of Angular.
Ik sei eartiids dat jo earst JavaScript moatte leare en dan de kaders, mar no bin ik derfan oertsjûge dat jo it allegear tagelyk dwaan moatte. JS feroaret ekstreem fluch, dus jo moatte wat ûnderfining krije mei it brûken fan React, Vue of Angular tagelyk as it learen fan JavaScript.
Dit begjint te beynfloedzjen op 'e easken dy't steld wurde oan kandidaten foar de posysje fan ûntwikkelder. Dit is bygelyks wat ik fûn doe't ik socht nei "JavaScript" op Indeed.
De taakbeskriuwing seit dat se kennis nedich hawwe fan jQuery EN JavaScript. Dy. Foar dit bedriuw binne beide komponinten like wichtich.
Hjir is in oare beskriuwing dy't allinich de "basis" easken listet:
En dit bart yn sawat de helte fan 'e fakatueres wêr't ik nei seach. Ik leau lykwols dat de juste ferhâlding fan tiid om JS en kaders te learen sawat 65% oant 35% is, net 50 oant 50.
Unwilligens om bekend te wurden mei it konsept fan "skjinne koade"
Elke aspirant-ûntwikkelder moat leare skjinne koade te meitsjen as se in profesjoneel wolle wurde. It is de muoite wurdich om josels bekend te meitsjen mei it konsept fan "skjinne koade" oan it begjin fan jo karriêre. Hoe earder jo dit konsept begjinne te folgjen, hoe earder jo wend wurde oan it skriuwen fan skjinne koade dy't letter maklik te ûnderhâlden is.
Trouwens, om de foardielen fan goede en skjinne koade te begripen, hoege jo net te besykjen om sels minne koade te skriuwen. Jo feardichheden sille letter fan pas komme, op it wurk, as jo ôfgryslik binne troch de minne koade fan in oar.
Te betiid begjinne te wurkjen oan grutte projekten
Begjin yn myn karriêre makke ik in grutte flater: ik besocht in grut projekt op te nimmen doe't ik der noch net klear foar wie.
Jo kinne freegje wat der mis is hjir. Der is in antwurd. It feit is dat as jo gjin midden of senioaren binne, dan sille jo wierskynlik jo "grutte projekt" net kinne foltôgje. D'r sille tefolle eleminten en dingen wêze om te beskôgjen. En jo sille net kinne omgean as jo oan it begjin fan jo karriêre net de gewoante hawwe ûntwikkele om "skjinne koade" te skriuwen, mei tests, skalbere arsjitektuer, ensfh.
Litte wy sizze dat jo in protte tiid bestege oan dit projekt, hawwe it net foltôge, en no besykje jo nei it middennivo te gean. En dan ynienen realisearje jo dat jo dizze koade oan gjinien sjen kinne, om't it net heul goed is en refactoring nedich is. Jo hawwe lykwols in protte tiid bestege oan dit "projekt fan 'e ieu" en no hawwe jo gjin foarbylden fan goed wurk om jo portefúlje ta te foegjen. En jo ferlieze it iene ynterview nei it oare oan dy kandidaten dy't har wurk, al is net hiel grut, yn in portfolio sjen litte kinne.
Yn alle gefallen sille jo yn 'e takomst moatte refactor, om't de koade net heul goed is, en de technologyen dy't jo brûkt hawwe binne net krekt wat jo nedich binne. As resultaat realisearje jo dat it makliker is om alles fanôf it begjin te herskriuwen dan te besykjen it te reparearjen.
Fansels kin dit alles oan jo portefúlje tafoege wurde, mar in potinsjele wurkjouwer sil dêr in protte tekoarten sjen en ta konklúzjes komme dy't jo teloarstellend binne.
Unwilligens om gegevensstruktueren en algoritmen te learen
Jo kinne in lange tiid argumearje oer wannear't jo moatte begjinne te studearjen fan gegevensstruktuer en algoritmen. Guon minsken suggerearje dit te dwaan foardat jo JavaScript behearskje, oaren nei.
Ik leau dat it net nedich is om dit yn detail oan it begjin te learen, mar it is de muoite wurdich om de algoritmen te begripen, om't dit in basisbegryp sil jaan fan it wurk fan kompjûterprogramma's en berekkeningen.
Algoritmen binne in yntegraal diel fan alle berekkeningen en programma's. Eigentlik binne kompjûterprogramma's sels in kombinaasje fan in set fan algoritmen en gegevens strukturearre op in bepaalde manier, dat is alles.
Wegering fan fysike aktiviteit
It is tige wichtich foar in ûntwikkeler om te spyljen sports . Ik bin gjin trainer, mar ik haw sjoen hoe myn lichem feroaret, jier nei jier. Dêrom kin ik jo fertelle wêr't it gebrek oan fysike oefening ta liedt.
Myn earste baan wie om in oantal redenen frij problematysk, en ien fan 'e problemen wie dat ik yn mar in jier hast twa tsientallen kilograms oankaam. Doe haw ik JavaScript aktyf studearre.
As jo net oefenje, riskearje jo gewicht te krijen, en dit sil in protte negative gefolgen hawwe: obesitas, migraine (ynklusyf chronike), hege bloeddruk, ensfh. De list mei problemen is wirklik einleaze.
Sosjaal sels-isolaasje
Famylje en leafsten binne wichtich. Troch josels te ûnderdompeljen yn it learen fan JavaSkript en it belang fan jo mentale en emosjonele libben te ûnderskatten, rinst it risiko om depressyf te wurden, irritabel te wurden, net goed te sliepen, en folle mear.
befinings
Ik hoopje dat wat fan dit nuttich is foar jo. As jo hjoed foar josels soargje, hoege jo flaters letter net te korrigearjen.
Skillbox advisearret:
- Praktyske kursus .
- Oanfrege online kursus .
- Twa jier praktyske kursus .
Boarne: www.habr.com