Itzultzailearen hitzaurrea: Artikulu hau irakurri ondoren, harritu edo haserretu zaitezke. Bai, gu ere harrituta geratu ginen: egileak ez omen zuen inoiz entzun taldean dagoen hierarkiaren berri, “egin azkar eta arrazoitu gabe” egoerarekin zereginak ezartzeari buruz. Bai, hori da, testu arraro samarra da hau. Izan ere, egileak iradokitzen du programatzaileak sistema-arkitektu baten papera hartzea - zergatik behar duzu arkitekto bat? Baina objekzio horiek guztiek ez zaituzte gauza nagusiari itsutu behar: zergatik hartu eta itzuli genuen, hala ere, testu hau. Ez da rolez ari. Testu hau ikuspegi eta sentsibilizazio profesional bati buruzkoa da. Egia esan, zure ekintzen esanahia pentsatu gabe "egiten dizutena" besterik ez duzun bitartean, ez zarela sekula programatzaile handi bihurtuko.
Esan ezetz alferrikako kodeari. Hiru letra elkartu eta hitza esatea besterik ez duzu egin behar. Saia gaitezen elkarrekin hau egiten: "Nooooo!"
Baina itxaron. Zergatik ari gara hau? Azken finean, programatzaile baten zeregin nagusia kodea idaztea da. Baina eskatzen zaizun kodea idatzi behar al duzu? Ez! "Kodea noiz ez idatzi behar den ulertzea da ziurrenik programatzaile baten trebetasun garrantzitsuena". .
Gogoratzen dugu: "Habr" irakurle guztientzat - 10 errubloko deskontua "Habr" promozio-kodea erabiliz Skillbox-eko edozein ikastarotan izena ematean.
Skillbox-ek gomendatzen du: Ikastaro praktikoa .
Programazioa arazoak konpontzeko artea da. Eta arte honen maisuak zarete.
Batzuetan, lanean ahalik eta azkarren hasteko ahaleginean, esku artean dugun zeregina betetzea baino ez dugu pentsatzen. Eta horrek are arazo larriagoak sor ditzake.
Zertan ixten dute programatzaileek begiak?
Idazten duzun kode guztiak ulergarria izan behar du beste garatzaileentzat, eta probatu eta arazketa egin behar da.
Baina arazo bat dago: idazten duzun guztia, zure softwarea zaildu egingo du eta ziurrenik etorkizunean akatsak sartuko ditu.
Rich Skrent-en arabera, . Hona hemen berak idazten duena:
«Kodea txarra da, usteltzen hasten delako eta etengabeko mantentze-lanak behar dituelako. Funtzio berriak gehitzeak kode zaharra aldatzea eskatzen du askotan. Zenbat eta handiagoa izan, orduan eta handiagoa izango da errore bat gertatzeko probabilitatea eta orduan eta denbora gehiago behar da konpilatzeko. Beste garatzaile batek denbora gehiago behar du asmatzeko. Eta birfactorizazioa behar bada, aldatzea merezi duten zatiak egongo dira zalantzarik gabe. Kode handiak askotan proiektuaren malgutasuna eta funtzionaltasuna murriztea esan nahi du. Irtenbide sinple eta dotorea kode konplexua baino azkarragoa da».
Nola dakizu noiz ez idatzi kodea?
Arazoa da programatzaileek sarritan handitu egiten dutela beren aplikazioak behar dituen funtzio kopurua. Ondorioz, kodearen atal asko amaitu gabe geratzen dira edo inork ez ditu erabiltzen, baina aplikazioa zaildu egiten dute.
Argi ulertu behar duzu zure proiektuak zer behar duen eta zer ez.
Adibide bat zeregin bakarra konpontzen duen aplikazio bat da: posta elektronikoa kudeatzea. Horretarako, bi funtzio sartu dira: gutunak bidaltzea eta jasotzea. Ez zenuke posta-kudeatzailea aldi berean zeregin-kudeatzaile bihurtuko denik espero.
Aplikazioaren zeregin nagusiarekin zerikusirik ez duten ezaugarriak gehitzeko proposamenei "ez" irmo esan behar diezu. Hauxe da kode gehigarririk behar ez dela argi geratzen den unea.
Ez galdu inoiz zure aplikazioaren fokua.
Galdetu beti zeure buruari:
— Zein funtzio ezarri behar da orain?
— Zein kodea idatzi behar dut?
Burura etortzen diren ideiak zalantzan jarri eta kanpotik datozen iradokizunak ebaluatu. Bestela, kode gehigarriak proiektua akaba dezake.
Beharrezkoak ez diren gauzak noiz gehitu behar dituzun jakiteak zure kodearen oinarria kontrolpean mantentzen lagunduko dizu.
Bidearen hasieran, programatzaileak bizpahiru iturburu fitxategi baino ez ditu. Sinplea da. Aplikazioa konpilatu eta abiarazteko gutxieneko denbora behar da; Beti argi dago non eta zer bilatu.
Aplikazioa zabaldu ahala, gero eta kode fitxategi gehiago agertzen dira. Katalogoa betetzen dute, bakoitza ehunka lerroz. Hori guztia behar bezala antolatzeko, direktorio osagarriak sortu beharko dituzu. Aldi berean, gero eta zailagoa da zer funtzio arduratzen duten eta zein ekintzek eragiten dituzten gogoratzea; akatsak harrapatzea ere denbora gehiago behar da. Proiektuen kudeaketa ere gero eta konplexuagoa da; ez bat, baizik eta hainbat garatzaile behar dira guztiaren jarraipena egiteko. Horren arabera, kostuak, bai diruak bai denborak, handitu egiten dira, eta garapen prozesua moteldu egiten da.
Proiektua izugarria bihurtzen da azkenean, eta eginbide berri bakoitza gehitzeak gero eta esfortzu handiagoa eskatzen du. Nahiz eta oso hutsala den zerbaitetarako hainbat ordu eman behar dituzu. Dauden akatsak zuzentzeak berriak agertzea dakar, eta aplikazioak kaleratzeko epeak galtzen dira.
Orain proiektuaren bizitzaren alde borrokatu behar dugu. Zergatik?
Kontua da, besterik gabe, ez duzula ulertzen noiz ez zenituen kode gehigarririk gehitu behar, eta "bai" erantzun diozu iradokizun eta ideia guztiei. Itsua zinen, gauza berriak sortzeko gogoak gertakari garrantzitsuak alde batera utzi zizun.
Beldurrezko filmaren gidoia dirudi, ezta?
Horixe gertatuko da baietz esaten jarraitzen baduzu. Saiatu ulertzen noiz ez den kodea gehitu behar. Kendu proiektutik beharrezkoak ez diren gauzak - honek zure bizitza asko erraztuko du eta aplikazioaren bizitza luzatuko du.
"Nire egun emankorrenetako bat 1000 kode lerro ezabatu nituenean izan zen".
- Ken Thompson.
Koderik ez idazten ikastea zaila da. Baina beharrezkoa da.
Bai, badakit garatzaile baten bideari ekin berri zarela eta kodea idatzi nahi duzula. Ona da, ez galdu lehen inpresio hori, baina ez galdu faktore garrantzitsuak bistatik ilusioagatik. Proba eta akatsen bidez konturatu ginen dena. Akatsak ere egingo dituzu eta haietatik ikasiko duzu. Baina goikotik ikasiz gero, zure lana kontzienteagoa izango da.
Jarraitu sortzen, baina jakin noiz esan ezetz.
Skillbox-ek gomendatzen du:
- Lineako ikastaroa aplikatua .
- Lineako ikastaroa .
- Ikastaro praktikoa .
Iturria: www.habr.com