De essensjele feardigens foar ûntwikkelders dy't jo koade better sil meitsje

De essensjele feardigens foar ûntwikkelders dy't jo koade better sil meitsje

Foarwurd fan de oersetter: Nei it lêzen fan dit artikel, kinne jo wêze ferrast of sels lilk. Ja, wy wiene ek ferrast: de skriuwer soe nea heard hawwe oer de hiërargy yn it team, oer it ynstellen fan taken mei de status "do it fluch en sûnder reden." Ja, dat is krekt, dit is in bytsje in nuvere tekst. Yndied suggerearret de auteur dat de programmeur de rol fan in systeemarsjitekt nimt - wêrom hawwe jo dan in arsjitekt nedich? Mar al dizze beswieren moatte jo net blyn meitsje foar it wichtichste ding - wêrom hawwe wy dizze tekst dochs nommen en oerset. Hy hat it net oer rollen. Dizze tekst giet oer in profesjonele oanpak en bewustwêzen. De wierheid is dat sa lang as jo gewoan "dwaan wat jo ferteld binne" sûnder te tinken oer de betsjutting fan jo aksjes, sille jo noait in geweldige programmeur wurde.

Sis nee tsjin ûnnedige koade. Alles wat jo hoege te dwaan is trije letters byinoar te setten en it wurd te sizzen. Litte wy dit tegearre besykje: "Neeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!"

Mar wachtsje. Wêrom dogge wy dit? Ommers, de wichtichste taak fan in programmeur is it skriuwen fan koade. Mar moatte jo in koade skriuwe dy't fan jo frege wurdt? Nee! "Begryp wannear't net koade te skriuwen is wierskynlik de wichtichste feardigens foar in programmeur." The Art Of Readable Code.

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: Praktyske kursus "Mobiele ûntwikkelder PRO".

Programmearje is de keunst fan it oplossen fan problemen. En do bist masters fan dizze keunst.
Soms, yn in poging om sa rap mooglik te begjinnen mei it wurk, tinke wy oan neat oars as it foltôgjen fan de taak by de hân. En dit kin noch mear serieuze problemen feroarsaakje.

Wat dogge programmeurs in blyn each foar?

Alle koade dy't jo skriuwe moatte begryplik wêze foar oare ûntwikkelders, en moatte wurde hifke en debuggen.

Mar d'r is in probleem: wat jo ek skriuwe, it sil jo software komplisearje en wierskynlik bugs yn 'e takomst ynfiere.

Neffens Rich Skrent, koade is ús fijân. Hjir is wat hy skriuwt:

“De koade is min, om't it begjint te rotten en konstant ûnderhâld freget. It tafoegjen fan nije funksjes fereasket faak it wizigjen fan âlde koade. Hoe grutter it is, hoe heger de kâns dat in flater optreedt en hoe mear tiid it nimt om te kompilearjen. It duorret in oare ûntwikkelder mear tiid om it út te finen. En as refactoring nedich is, dan sille der grif fragminten wêze dy't it wurdich binne te feroarjen. Grutte koade betsjut faaks fermindere fleksibiliteit en funksjonaliteit fan it projekt. In ienfâldige en elegante oplossing is rapper dan komplekse koade.

Hoe kinne jo witte wannear't jo gjin koade moatte skriuwe?

It probleem is dat programmeurs faaks it oantal funksjes oerdriuwe dy't har applikaasje nedich is. As gefolch, in protte seksjes fan koade bliuwe ûnfoltôge of gjinien brûkt se, mar se komplisearje de applikaasje.

Jo moatte dúdlik begripe wat jo projekt nedich is en wat it net docht.

In foarbyld is in applikaasje dy't mar ien taak oplost - e-post beheare. Foar dit doel binne twa funksjes ynfierd - brieven ferstjoere en ûntfange. Jo moatte net ferwachtsje dat de e-postbehearder tagelyk in taakbehearder wurdt.

Jo moatte stevich "nee" sizze tsjin foarstellen om funksjes ta te foegjen dy't net relatearre binne oan de haadtaak fan 'e applikaasje. Dit is krekt it momint dat dúdlik wurdt dat ekstra koade net nedich is.

Ferlieze nea de fokus fan jo applikaasje.

Freegje dysels altyd ôf:

- Hokker funksje moat no ynfierd wurde?
- Hokker koade moat ik skriuwe?

Stel fragen oer de ideeën dy't yn 't sin komme en evaluearje suggestjes dy't fan bûten komme. Oars, ekstra koade kin gewoan deadzje it projekt.

Wisten wannear't jo gjin ûnnedige dingen moatte tafoegje sil jo helpe om jo koadebasis ûnder stevige kontrôle te hâlden.

De essensjele feardigens foar ûntwikkelders dy't jo koade better sil meitsje

Oan it begjin fan it paad hat de programmeur mar twa of trije boarnebestannen. It is ienfâldich. It kompilearjen en starten fan 'e applikaasje fereasket in minimum fan tiid; It is altyd dúdlik wêr en wat te sykjen.

As de applikaasje útwreidet, ferskine mear en mear koadebestannen. Se folje de katalogus, elk mei hûnderten rigels. Om dit alles goed te organisearjen, moatte jo ekstra mappen oanmeitsje. Tagelyk wurdt it hieltyd dreger om te ûnthâlden hokker funksjes ferantwurdlik binne foar wat en hokker aksjes dy feroarsaakje; it fangen fan bugs nimt ek mear tiid. Projektbehear wurdt ek komplekser; net ien, mar ferskate ûntwikkelders binne ferplicht om alles by te hâlden. Dêrnjonken ferheegje de kosten, sawol monetêr as tiid, en it ûntwikkelingsproses fertraget.

It projekt wurdt úteinlik enoarm, en it tafoegjen fan elke nije funksje nimt mear en mear ynspanning. Sels foar wat heul ûnbelangryk moatte jo ferskate oeren trochbringe. Korrizjearje fan besteande flaters liedt ta it ferskinen fan nije, en deadlines foar frijlitting fan applikaasjes wurde mist.

No moatte wy stride foar it libben fan it projekt. Wêrom?

It feit is dat jo gewoan net begrepen as jo gjin ekstra koade moatte tafoegje, en "ja" antwurde op elke suggestje en idee. Jo wiene blyn, de winsk om nije dingen te meitsjen makke jo wichtige feiten te negearjen.

Klinkt as in horrorfilmskript, krekt?

Dit is krekt wat der sil barre as jo bliuw ja sizze. Besykje te begripen wannear't koade net tafoege wurde moat. Ferwiderje ûnnedige dingen út it projekt - dit sil jo libben in stik makliker meitsje en it libben fan 'e applikaasje ferlingje.

"Ien fan myn meast produktive dagen wie doe't ik 1000 rigels koade wiske."
- Ken Thompson.

Learje wannear net koade te skriuwen is lestich. Mar it is nedich.

Ja, ik wit dat jo krekt it paad fan in ûntwikkelder binne begûn en koade wolle skriuwe. It is goed, ferlies dy earste yndruk net, mar ferliest wichtige faktoaren net út it each fanwegen entûsjasme. Wy realisearre alles troch trial and error. Jo sille ek flaters meitsje en derfan leare. Mar as jo fan it boppesteande learje kinne, sil jo wurk bewuster wurde.

Bliuw meitsje, mar wit wannear't jo nee moatte sizze.

Skillbox advisearret:

Boarne: www.habr.com

Add a comment