Owen Little
0 
5108
1008
Svatko može napisati kod. Ali dobar kod? To je mjesto gdje postaje teško.
Svi smo čuli horor priče o kodu špageta, masivnim trgovačkim lancima, cijelim programima koji se mogu slomiti samo promjenom jedne varijable, funkcija koje izgledaju kao da su zamagljeni i tako dalje. To se događa kada pokušate napraviti proizvod koji se može isporučiti sa samo semestrom iskustva u programiranju ispod vašeg pojasa.
Nemojte se slagati sa pisanjem tog koda djela. Cilj je napisati kôd koji može biti održavan - ne samo vi, već i svi drugi koji će možda u nekom trenutku u budućnosti završiti s radom na softveru. U tu svrhu, evo nekoliko principa koji će vam pomoći da očistite svoj čin.
1. KISS
“neka bude jednostavno glupane” načelo odnosi se na skoro cijeli život, ali posebno je to potrebno u programskim projektima srednjih i velikih.
Sve počinje na početku kada definirate opseg onoga što želite stvoriti. Samo zato što ste strastveni u razvoju igara, ne znači da možete stvoriti sljedeću World of Warcraft ili Grand Theft Auto. Kad mislite da ste dovoljno pojednostavili, pojednostavite ga još jednu razinu - puzanje značajki je neizbježno, pa počnite s malim.
Ali čak i nakon započinjanja kodiranja, nastavite jednostavno. Kompleksni kôd traje dulje za dizajn i pisanje, skloniji je pogreškama i pogreškama i teže je modificirati kasnije na putu. Mudrim riječima Antoinea de Saint-Exuperyja, “Savršenstvo se postiže, ne kad se nema što dodati, nego kad ne preostaje ništa drugo što vam je potrebno za oduzeti.”
2. SUHE
“ne ponavljaj se” načelo je ključno za čist i lako izmijeniti kod. Prilikom pisanja koda želite izbjeći dupliciranje podataka i duplikaciju logike. Ako primijetite da se isti i niz koda pišu iznova i iznova, probijate taj princip.
Suprotnost DRY kodu je WET kod: “napisati sve dvaput” (ili “gubite svako vrijeme”). Jedan od najboljih načina dijagnosticiranja WET koda jest zapitati se: kako biste na neki način promijenili ponašanje programa, koliko područja koda trebate izmijeniti?
Pretpostavimo da pišete aplikaciju za podcast. Na stranici za pretraživanje imate kôd za dohvaćanje podataka o podcastu. Na stranici podcasta imate kôd za dohvaćanje detalja tog podcasta. Na stranici favorita isti kod za dohvaćanje. Razmislite o apstrahiranju svega toga u funkciji, tako da ako trebate kasnije urediti to možete učiniti na jednom mjestu.
3. Otvoreno / zatvoreno
Bilo da pišete objekte Što je objektno orijentirano programiranje? Osnove pojašnjene u laičkim uvjetima Što je objektno orijentirano programiranje? Osnove pojašnjene u laičkim uvjetima Većina modernih programskih jezika podržava paradigmu "objektno orijentirano programiranje" (OOP). Ali što je to točno OOP i zašto je toliko koristan? u Javi ili modulima na Pythonu, trebali biste nastojati napraviti svoj kod otvoren za proširenje, ali zatvoren za preinake. Ovo se odnosi na sve vrste projekata, ali je posebno važno pri puštanju knjižnice ili okvira namijenjenog drugima.
Na primjer, pretpostavimo da održavate GUI okvir. Možete ga objaviti takvog kakav jest, očekujući da će krajnji korisnici izravno izmijeniti i integrirati objavljeni kôd. Ali što se događa kada objavite glavni update četiri mjeseca kasnije? Kako implementiraju sve vaše dodatke, a da ne bacaju sav posao koji su obavili?
Umjesto toga, pustite taj kod sprječava izravna izmjena i potiče proširenje. Ovo odvaja osnovno ponašanje od modificiranog ponašanja. Povlastice? Veća stabilnost (korisnici ne mogu slučajno prekršiti osnovno ponašanje) i veća održivost (korisnici se brinu samo zbog proširenog koda). Otvoreno / zatvoreno načelo ključno je za stvaranje dobrog API-ja Što su API-i i kako otvoreni API-i mijenjaju internet što su API-ji i kako otvoreni API-i mijenjaju internet. Jeste li se ikad zapitali kako programi na vašem računalu i web stranice koje posjetite "razgovarati" jedni s drugima? .
4. Sastav> Nasljeđivanje
“sastav nad nasljeđivanjem” načelo kaže da bi objekti s kompleksnim ponašanjem trebali to činiti sadržavanjem instanci objekata sa ponašanjem pojedinaca, a ne nasljeđivanjem klase i dodavanjem novih ponašanja.
Prevelika ovisnost o nasljeđivanju može dovesti do dva glavna problema. Prvo, hijerarhija nasljeđivanja može postati neuredna u tren oka. Drugo, imate manju fleksibilnost za definiranje ponašanja u posebnim slučajevima, posebno kada želite implementirati ponašanje iz jedne grane nasljeđivanja u drugu granu nasljeđivanja:
Sastav je mnogo čistiji za pisanje, lakši je za održavanje i omogućuje gotovo beskonačnu fleksibilnost što se tiče vrsta ponašanja koje možete definirati. Svako pojedinačno ponašanje predstavlja svoju klasu, a vi stvarate složena ponašanja kombinirajući pojedinačna ponašanja.
5. Pojedinačna odgovornost
načelo jedinstvene odgovornosti kaže da bi se svaka klasa ili modul u programu trebao odnositi samo na pružanje jednog bita određene funkcionalnosti. Kako to navodi Robert C. Martin, “Razred bi trebao imati samo jedan razlog za promjenu.”
Klase i moduli često započinju na ovaj način, ali dodavanjem značajki i novih ponašanja lako je evoluirati u Božje klase i Božje module koji zauzimaju stotine ili čak tisuće redaka koda. U ovom trenutku trebali biste ih raščlaniti na manje klase i module.
6. Razdvajanje briga
načelo razdvajanja zabrinutosti nalik je načelu jedinstvene odgovornosti, ali na apstraktnijoj razini. U osnovi, program treba biti dizajniran tako da ima mnogo različitih enklapsulacija koje se ne preklapaju, a te kapsule ne bi trebale znati jedna o drugoj..
Dobro poznat primjer je paradigma model-view-controller (MVC), koja program razdvaja na tri različita područja: podaci (“model”), logika (“kontrolor”) i što vidi krajnji korisnik (“pogled”). Varijacije MVC-a uobičajene su u današnjim najpopularnijim mrežnim okvirima.
Kreditna slika: Wikimedia
Na primjer, kôd koji vrši učitavanje i spremanje podataka u bazu podataka ne mora znati kako te podatke prikazati na webu. Kôd za iscrtavanje može preuzeti unos od krajnjeg korisnika, ali ga tada prosljeđuje u logički kod radi obrade. Svaki dio rukuje sam.
To rezultira modularnim kodom što znatno olakšava održavanje. I ubuduće, ako ćete ikada trebati ponovo napisati sav kôd za prikazivanje, možete to učiniti bez brige o tome kako će se podaci spremiti ili se logika obraditi.
7. YAGNI
“neće ti trebati” načelo je ideja koja nikad ne treba kodirati za funkcionalnost koju ste svibanj potreba u budućnosti. Vjerojatno ste vi navika trebate ga i gubit ćete vrijeme - i ne samo to, već će bespotrebno povećavati složenost vašeg koda.
To biste mogli vidjeti kao specifičnu primjenu načela KISS i odgovor na one koji princip sušenja uzimaju previše ozbiljno. Često neiskusni programeri pokušavaju napisati najopstraniji i općenitiji kôd kako bi izbjegli WET kod, ali previše apstrakcije završi u nabujalom kodu koji se ne može održavati.
Trik je primijeniti DRY princip samo kada to trebate. Ako primijetite da komadi koda pišu iznova i iznova, apstraktite ih - ali nikad kad vi razmišljati komad koda pisat će se iznova i iznova. Više puta nego ne, neće biti.
8. Izbjegavajte preranu optimizaciju
nema načela preuranjene optimizacije slično je YAGNI principu. Razlika je u tome što se YAGNI bavi tendencijom provoditi ponašanja prije nego što su potrebni dok se ovaj princip bavi tendencijom da ubrzati algoritme prije nego što je potrebno.
Problem s preuranjenom optimizacijom je taj što zapravo nikada ne možete znati gdje će uska grla programa biti tek nakon činjenice. Možete pogoditi, naravno, a ponekad ste možda i u pravu. Ali češće nego ne, gubit ćete dragocjeno vrijeme pokušavajući ubrzati funkciju koja nije tako spora kao što mislite ili se ne zove tako često koliko biste očekivali.
Tada dosegnite svoje najvažnije korake profil vašeg koda utvrditi istinska uska grla.
9. Refactor, Refactor, Refactor
Jedna od najtežih istina koju treba prihvatiti kao neiskusan programer je ta kôd rijetko izlazi točno prvi put. Može osjećati kada implementirate tu sjajnu novu značajku, ali kako vaš program raste u složenosti, buduće značajke mogu ometati kako ste to rano napisali.
Baza podataka se neprestano razvija. Potpuno je normalno pregledati, prepisati ili čak redizajnirati čitave dijelove koda - i to ne samo normalno, već i zdravo za to. Znate više o potrebama vašeg projekta sada nego kada si radio u početak, i trebali biste redovito koristiti ovo novo stečeno znanje za ponovno postavljanje starog koda.
Imajte na umu da to ne mora uvijek biti veliki proces. Pogledajte stranicu izviđača iz Amerike, koji žive ovim riječima: “Ostavite kamp puno čistijim nego što ste ga pronašli.” Ako ikad trebate provjeriti ili izmijeniti stari kod, uvijek ga očistite i ostavite u boljem stanju.
10. Očistite kod> Pametni kod
Govoreći o čistom kodu, ostavite svoj ego na vratima i zaboravite na pisanje pametnog koda. Znate o čemu govorim: vrsta koda koja više liči na zagonetku nego na rješenje i postoji isključivo zato da pokaže koliko ste pametni. Istina je da nikoga zapravo nije briga.
Jedan primjer pametnog koda je spakiranje što više logike u jednu liniju. Drugi je primjer iskorištavanje jezičnih sitnica za pisanje čudnih, ali funkcionalnih izjava. Sve što bi moglo natjerati nekoga da kaže “Čekaj, što?” prilikom slanja koda.
Dobri programeri i čitljiv kôd idu ruku pod ruku. Po potrebi ostavljajte komentare. Pridržavajte se stilskih vodiča, bilo da diktiraju jezik (poput Pythona) ili tvrtka (poput Googlea). Pridržavajte se jezičnih idioma i prestanite pisati Java kôd na Python-u ili obrnuto. Pogledajte naš članak o savjetima za pisanje koda čistije 10 Savjeti za pisanje čistije i bolji kod 10 Savjeti za pisanje čistije i bolji kod Pisanje čistog koda izgleda lakše nego što zapravo jest, ali prednosti su vrijedne toga. Evo kako danas možete početi pisati čistiji kod. .
Što je dobar programer?
Pitajte pet ljudi i dobit ćete 10 različitih odgovora. Za mene je dobar programer onaj koji razumije da kodiranje u konačnici treba poslužiti krajnjem korisniku, s kojim je lako raditi u timu i koji svoje projekte dovršava prema specifikaciji i na vrijeme.
Ako ste zaglavili, pogledajte naš članak o prevladavanju bloka programera. A ako jednostavno niste zadovoljni s pisanjem koda, pročitajte naš članak o znakovima za koje niste namijenjeni programeru.
Ako tek počinjete, usredotočite se na učenje kodiranja bez stresa. Niste sigurni u koji programski jezik prvo zaroniti? C # je dobro mjesto za započeti iz praktičnih razloga. 7 Praktični razlozi za učenje Programiranje C # 7 Praktični razlozi za učenje Programiranje C # Postoji mnogo programskih jezika, pa koji bi trebao odabrati jedan koji treba naučiti? Evo nekoliko razloga za učenje C #. , A ako ga odaberete, uzmite u obzir i savjete za programiranje C. 5 C Savjeti za programiranje koje morate naučiti kako započeti 5 Savjeti za programiranje C C Morate naučiti kako započeti C programski jezik C ima čvrstu reputaciju. Ali ako se s time suočite, možete programirati bilo što, kao što pokazuju ovi savjeti. .