Vertaler se voorwoord: Nadat jy hierdie artikel gelees het, kan jy verbaas of selfs kwaad wees. Ja, ons was ook verbaas: die skrywer het kwansuis nog nooit gehoor van die hiërargie in die span nie, van die opstel van take met die status "doen dit vinnig en sonder redenasie." Ja, dit is reg, dit is 'n bietjie van 'n vreemde teks. Inderdaad, die skrywer stel voor dat die programmeerder die rol van 'n stelselargitek aanneem - hoekom het jy dan 'n argitek nodig? Maar al hierdie besware moet jou nie verblind vir die hoofsaak nie – hoekom ons tog hierdie teks geneem en vertaal het. Hy praat nie van rolle nie. Hierdie teks handel oor 'n professionele benadering en bewustheid. Die waarheid is dat solank jy net "doen wat vir jou gesê word" sonder om aan die betekenis van jou aksies te dink, sal jy nooit 'n goeie programmeerder word nie.
Sê nee vir onnodige kode. Al wat jy hoef te doen is om drie letters bymekaar te sit en die woord te sê. Kom ons probeer dit saam doen: "Neeee!"
Maar wag. Hoekom doen ons dit? Die hooftaak van 'n programmeerder is immers om kode te skryf. Maar moet jy enige kode skryf wat van jou gevra word? Geen! "Om te verstaan wanneer om nie kode te skryf nie, is waarskynlik die belangrikste vaardigheid vir 'n programmeerder." .
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: Praktiese kursus .
Programmering is die kuns van probleemoplossing. En julle is meesters van hierdie kuns.
Soms, in 'n poging om so vinnig as moontlik te begin werk, dink ons aan niks anders as om die taak op hande te voltooi nie. En dit kan selfs meer ernstige probleme veroorsaak.
Waarvoor draai programmeerders 'n blinde oog?
Alle kode wat jy skryf moet verstaanbaar wees vir ander ontwikkelaars, en moet getoets en ontfout word.
Maar daar is 'n probleem: wat jy ook al skryf, dit sal jou sagteware kompliseer en waarskynlik in die toekoms foute bekendstel.
Volgens Rich Skrent, . Hier is wat hy skryf:
“Die kode is sleg, want dit begin vrot en vereis konstante instandhouding. Om nuwe kenmerke by te voeg, vereis dikwels die wysiging van ou kode. Hoe groter dit is, hoe groter is die waarskynlikheid dat 'n fout sal voorkom en hoe meer tyd neem dit om saam te stel. Dit neem 'n ander ontwikkelaar meer tyd om dit uit te vind. En as herfaktorering nodig is, sal daar beslis fragmente wees wat die moeite werd is om te verander. Groot kode beteken dikwels verminderde buigsaamheid en funksionaliteit van die projek. ’n Eenvoudige en elegante oplossing is vinniger as komplekse kode.”
Hoe weet jy wanneer om nie kode te skryf nie?
Die probleem is dat programmeerders dikwels die aantal kenmerke wat hul toepassing benodig, oordryf. As gevolg hiervan bly baie dele van die kode onvoltooid of niemand gebruik dit nie, maar dit bemoeilik die toepassing.
Jy moet duidelik verstaan wat jou projek benodig en wat nie.
'n Voorbeeld is 'n toepassing wat net een taak oplos - die bestuur van e-pos. Vir hierdie doel is twee funksies ingestel – die stuur en ontvang van briewe. U moet nie verwag dat die posbestuurder terselfdertyd 'n taakbestuurder moet word nie.
U moet beslis "nee" sê vir voorstelle om kenmerke by te voeg wat nie verband hou met die hooftaak van die toepassing nie. Dit is presies die oomblik wanneer dit duidelik word dat addisionele kode nie nodig is nie.
Moet nooit die fokus van jou aansoek verloor nie.
Vra jouself altyd af:
— Watter funksie moet nou geïmplementeer word?
— Watter kode moet ek skryf?
Bevraagteken die idees wat by jou opkom en evalueer voorstelle wat van buite kom. Andersins kan ekstra kode eenvoudig die projek doodmaak.
Om te weet wanneer om nie onnodige dinge by te voeg nie, sal jou help om jou kodebasis onder ferm beheer te hou.
Heel aan die begin van die pad het die programmeerder slegs twee of drie bronlêers. Dis eenvoudig. Die samestelling en bekendstelling van die toepassing verg 'n minimum tyd; Dit is altyd duidelik waar en waarna om te soek.
Soos die toepassing uitbrei, verskyn meer en meer kodelêers. Hulle vul die katalogus, elk met honderde reëls. Om dit alles korrek te organiseer, sal jy bykomende gidse moet skep. Terselfdertyd word dit al hoe moeiliker om te onthou watter funksies waarvoor verantwoordelik is en watter handelinge dit veroorsaak; om goggas te vang neem ook meer tyd. Projekbestuur word ook meer kompleks; nie een nie, maar verskeie ontwikkelaars word vereis om alles dop te hou. Gevolglik neem koste, beide geldelik en tyd, toe, en die ontwikkelingsproses vertraag.
Die projek word uiteindelik groot, en om elke nuwe kenmerk by te voeg, verg meer en meer moeite. Selfs vir iets baie onbeduidend moet jy etlike ure spandeer. Die regstelling van bestaande foute lei tot die verskyning van nuwes, en aansoekvrystellingspertye word gemis.
Nou moet ons veg vir die lewe van die projek. Hoekom?
Die feit is dat jy eenvoudig nie verstaan het wanneer jy nie ekstra kode moet byvoeg nie, en “ja” op elke voorstel en idee geantwoord het. Jy was blind, die begeerte om nuwe dinge te skep het jou belangrike feite laat ignoreer.
Klink soos 'n gruwelfliekdraaiboek, reg?
Dit is presies wat sal gebeur as jy aanhou ja sê. Probeer om te verstaan wanneer kode nie bygevoeg moet word nie. Verwyder onnodige goed uit die projek - dit sal jou lewe baie makliker maak en die lewe van die toepassing verleng.
"Een van my mees produktiewe dae was toe ek 1000 XNUMX reëls kode uitgevee het."
- Ken Thompson.
Dit is moeilik om te leer wanneer om nie kode te skryf nie. Maar dit is nodig.
Ja, ek weet dat jy pas die pad van 'n ontwikkelaar aangepak het en kode wil skryf. Dit is goed, moenie daardie eerste indruk verloor nie, maar moenie belangrike faktore uit die oog verloor as gevolg van entoesiasme nie. Ons het alles deur beproewing en fout besef. Jy sal ook foute maak en daaruit leer. Maar as jy uit bogenoemde kan leer, sal jou werk meer bewus word.
Hou aan skep, maar weet wanneer om nee te sê.
Skillbox beveel aan:
- Toegepaste aanlyn kursus .
- Aanlyn kursus .
- Praktiese jaarkursus .
Bron: will.com