Prevajalčev predgovor: Po branju tega članka boste morda presenečeni ali celo jezni. Da, tudi mi smo bili presenečeni: avtor menda nikoli ni slišal za hierarhijo v ekipi, za postavljanje nalog s statusom »naredi hitro in brez razmišljanja«. Ja, res je, malo čudno besedilo. Avtor namreč predlaga, da programer prevzame vlogo sistemskega arhitekta – zakaj potem potrebujete arhitekta? A vsi ti ugovori vas ne smejo zaslepiti pred glavnim – zakaj smo to besedilo vendarle vzeli in prevedli. Ne govori o vlogah. To besedilo govori o profesionalnem pristopu in ozaveščenosti. Resnica je, da dokler samo »delaš, kar ti rečejo«, ne da bi razmišljal o pomenu svojih dejanj, ne boš nikoli postal odličen programer.
Recite ne nepotrebni kodi. Vse kar morate storiti je, da sestavite tri črke in izgovorite besedo. Poskusimo to narediti skupaj: "Neeeee!"
Ampak počakaj. Zakaj to počnemo? Navsezadnje je glavna naloga programerja pisanje kode. Toda ali morate napisati kodo, ki se zahteva od vas? ne! "Razumevanje, kdaj ne pisati kode, je verjetno najpomembnejša veščina za programerja." .
Spomnimo: za vse bralce "Habr" - popust v višini 10 rubljev ob vpisu v kateri koli tečaj Skillbox s promocijsko kodo "Habr".
Skillbox priporoča: Praktični tečaj .
Programiranje je umetnost reševanja problemov. In vi ste mojstri te umetnosti.
Včasih v želji, da bi čim prej začeli z delom, ne razmišljamo o ničemer drugem kot o tem, da dokončamo zastavljeno nalogo. In to lahko povzroči še resnejše težave.
Na kaj si programerji zatiskajo oči?
Vsa koda, ki jo napišete, mora biti razumljiva drugim razvijalcem in mora biti preizkušena ter odpravljena napaka.
Vendar obstaja težava: kar koli napišete, bo zakompliciralo vašo programsko opremo in v prihodnosti verjetno povzročilo napake.
Po mnenju Richa Skrenta, . Evo, kaj piše:
»Koda je slaba, ker začne gniti in zahteva stalno vzdrževanje. Dodajanje novih funkcij pogosto zahteva spreminjanje stare kode. Večji kot je, večja je verjetnost, da bo prišlo do napake, in več časa traja prevajanje. Drugi razvijalec potrebuje več časa, da to ugotovi. In če je potrebno preoblikovanje, bodo zagotovo ostali fragmenti, ki jih je vredno spremeniti. Velika koda pogosto pomeni zmanjšano fleksibilnost in funkcionalnost projekta. Preprosta in elegantna rešitev je hitrejša od zapletene kode.«
Kako veste, kdaj ne smete pisati kode?
Težava je v tem, da programerji pogosto pretiravajo s številom funkcij, ki jih njihova aplikacija potrebuje. Zaradi tega veliko delov kode ostane nedokončanih ali pa jih nihče ne uporablja, vendar otežijo aplikacijo.
Jasno morate razumeti, kaj vaš projekt potrebuje in česa ne.
Primer je aplikacija, ki rešuje samo eno nalogo - upravljanje elektronske pošte. V ta namen sta uvedeni dve funkciji - pošiljanje in prejemanje pisem. Ne smete pričakovati, da bo upravitelj pošte hkrati postal upravitelj opravil.
Morate odločno reči "ne" predlogom za dodajanje funkcij, ki niso povezane z glavno nalogo aplikacije. To je ravno trenutek, ko postane jasno, da dodatna koda ni potrebna.
Nikoli ne izgubite fokusa svoje aplikacije.
Vedno se vprašajte:
— Katero funkcijo je treba uvesti zdaj?
— Kakšno kodo naj napišem?
Preizprašujte zamisli, ki vam pridejo na misel, in ocenite predloge, ki prihajajo od zunaj. V nasprotnem primeru lahko dodatna koda preprosto uniči projekt.
Če veste, kdaj ne smete dodajati nepotrebnih stvari, boste imeli svojo kodno bazo pod trdnim nadzorom.
Na samem začetku poti ima programer samo dve ali tri izvorne datoteke. Enostavno je. Prevajanje in zagon aplikacije zahteva najmanj časa; Vedno je jasno, kje in kaj iskati.
Ko se aplikacija širi, se pojavlja vedno več kodnih datotek. Polnijo katalog, vsak ima na stotine vrstic. Če želite vse to pravilno organizirati, boste morali ustvariti dodatne imenike. Hkrati postaja vse težje zapomniti, katere funkcije so odgovorne za kaj in katera dejanja jih povzročajo; tudi lovljenje hroščev vzame več časa. Vse bolj zapleteno postaja tudi vodenje projektov, ne enega, ampak več razvijalcev, ki morajo spremljati vse. Skladno s tem se povečajo stroški, tako denarni kot časovni, razvojni proces pa se upočasni.
Projekt sčasoma postane ogromen in dodajanje vsake nove funkcije zahteva vedno več truda. Tudi za nekaj zelo nepomembnega morate porabiti več ur. Popravljanje obstoječih napak vodi do pojava novih in zamude rokov za objavo aplikacij.
Zdaj se moramo boriti za življenje projekta. Zakaj?
Dejstvo je, da preprosto niste razumeli, kdaj ne smete dodati dodatne kode, in ste na vsak predlog in idejo odgovorili z "da". Bili ste slepi, želja po ustvarjanju novih stvari vas je prisilila, da ste zanemarili pomembna dejstva.
Sliši se kot scenarij grozljivke, kajne?
Točno to se bo zgodilo, če boste kar naprej govorili da. Poskusite razumeti, kdaj kode ne bi smeli dodati. Odstranite nepotrebne stvari iz projekta - to vam bo zelo olajšalo življenje in podaljšalo življenjsko dobo aplikacije.
"Eden mojih najbolj produktivnih dni je bil, ko sem izbrisal 1000 vrstic kode."
— Ken Thompson.
Težko se je naučiti, kdaj ne pisati kode. Ampak je nujno.
Ja, vem, da ste šele stopili na pot razvijalca in želite pisati kodo. Dobro je, ne izgubite tistega prvega vtisa, vendar ne pozabite pomembnih dejavnikov zaradi navdušenja. Vse smo spoznali s poskusi in napakami. Delali boste tudi napake in se iz njih učili. Če pa se iz zgoraj navedenega lahko kaj naučite, bo vaše delo postalo bolj zavestno.
Nadaljujte z ustvarjanjem, vendar vedite, kdaj reči ne.
Skillbox priporoča:
- Uporabni spletni tečaj .
- Spletni tečaj .
- Praktični enoletni tečaj .
Vir: www.habr.com