Tijekom posljednjih 17 godina radio sam na preko 90 projekata s mnogim timovima. Ali tek kad sam naišao na Gitovu blameznačajku, saznao sam o "rukopisu" svakog kodera. Ta jednostavna znatiželja ubrzo je postala navika. Kad god bih vidio novi kod, pokušao sam pogoditi tko ga je napisao. Tada bih pretpostavku potvrdio s git blame.
(Usput, ako još niste upoznati s gitom, to je popularan način da programeri surađuju na kodu, a njegova značajka "krivnje" pokazuje vam tko je autor određenog izvornog koda.)
Nakon nekoliko godina počeo sam vidjeti obrasce, baš kao što bi rukopisac mogao otkriti sociopata iz načina na koji crtaju svoja W-a. Rukopis kodova otkriva mnogo o programeru koji ga je napisao.
Iz rukopisa kodova programera možete naučiti gotovo sve: koliko iskustva imaju, koliko im je stalo do čitljivosti koda (i nadalje, koliko im je stalo do suigrača).
Kodni razgovori. Loš kod vrišti! Dakle, je li kod koji čitate kod kaligrafije ili je to ogrebotina?
Brza izjava o odricanju odgovornosti: ono što ćete pročitati temelji se isključivo na mojoj subjektivnoj intuiciji. Koliko znam, nije bilo recenziranih akademskih studija. Moje vještine analize rukopisa kodova dobro su mi služile u prošlosti i možda će vam pomoći, ali - kao i kod svega što čitate na internetu - vaša kilometraža može varirati.
Uvid # 1: Napuhnuti kod = borba
Obično kad otkrijem kod koji je postao napuhan i puno veći nego što treba biti, prikazuje programera koji se borio da završi zadatak koji je bio izvan njihovih mogućnosti. Ili nisu imali znanja ni vremena da posao pravilno završe.
U stvarnom životu ljudi koji rade manje, teže više razgovarati . Isto je i u zemlji s kodovima: oni koji ne mogu posao obaviti elegantno, uglavnom pišu puno koda.
Nažalost, bugovi se hrane kodom, a što je više odredbi o kodeksu, stanište je veće stanište.
"Mrzim kôd i želim ga što manje u našem proizvodu" - Jack Diederich
Uvid # 2: Mrtvi kod = aljkavost
Jeste li ikad vidjeli ogromne blokove komentiranog koda predane repo-u? Ili još gore: kod koji ne čini ništa posebno, ali postoji li iz povijesnih razloga?
Zanimljivo je da ovo ima izravnu korelaciju s neurednošću radnog stola programera koji ga je napisao. Jeste li ikad vidjeli zastarjele komentare ili testove? Da, našli ste neopreznog programera.
3. Složeni kod = glupost ili pohlepa
Volim ovaj Schumacherov citat:
“Svaka inteligentna budala može stvari učiniti većima, složenijima i nasilnijima. Potreban je dašak genija - i puno hrabrosti da se krene u suprotnom smjeru. " - Fritz SchumacherAko ste pronašli kôd koji je teško slijediti ili razumjeti, budite sigurni da ga je napisao netko tko nema pojma što radi ili netko tko traži sigurnost posla preuzimanjem "vlasništva" nad tim dijelom koda.
Uvid # 4: Komentari = timski igrač (osim ako ...)
Svi jezici visoke razine omogućuju pisanje koda koji je dovoljno čitljiv da vam ne trebaju komentari. Ali ponekad je složenost neizbježna zbog nedostatka znanja, vremena ili elegantnog okvira.
Zaista volim kad programeri stave vezu na API referencu ili odgovarajuće pitanje prelijevanja steka kad shvate da će njihovi vršnjaci (ili njihovo buduće ja) preispitivati određeni redak koda.
To je rečeno, pretjerano korištenje komentara pokazuje nedostatak samopoštovanja (ili kao što sam već spomenuo, pokušavajući objasniti "nadut kod").
Uvid br. 5: Imena = komunikacijska vještina
Imena varijabli, imena funkcija, imena parametara, imena klasa. To su osnovna razina komunikacije s održavateljima koda.
Ako naiđete na imena s jednim slovom (osim onih ikoja su zadana u forpetljama), pronašli ste programera s nedostatkom komunikacijskih vještina ili empatijom prema drugima.
Ako se ne radi o privremenom projektu koji se neće pokazati nikome drugome ili održavati, svaka sekunda odabira odgovarajućeg imena rezultira dobrom karmom.
A ako se funkcionalnost entiteta promijeni, važno je u skladu s tim refaktorizirati njegovo ime.
Neki programeri tvrde da imena nisu važna, jer strojeve nije briga. Pa, osim ako kod ne pišete doslovno u nulama i jedinicama, pišete i kod za ljude!
Uvid # 6: Loša čitljivost = nedostatak tečnosti
Ponekad programeri tečno govore jedan jezik, ali pokušavaju izvrnuti i saviti drugi jezik kako bi se ponašali kao njihov omiljeni jezik.
JavaScript je jedan od onih loših ciljnih jezika.
Većina back-end programera ima luksuz odabrati svoj "maternji jezik". A mnogi su dovoljno hrabri da udruže nekoliko redaka prednjeg koda. No budući da je većina preglednika uglavnom JavaScript (što je fleksibilan jezik), oni pokušavaju oponašati ono što im je ikada poznato iz njihovog "maternjeg jezika".
Ovo je sve dobro i dobro dok stvarni programer JavaScript ne vidi kôd i ne počupa im kosu!
Uvid # 7: Hakiranje = plitka osobnost ili nedostatak discipline
Jeste li ikad proveli puno vremena sređujući bazu koda samo da biste bili svjedoci kako vaš vršnjak prelijeva vaš benzin lijepim kôdom koristeći ga kao platformu za brze i prljave popravke?
Čestitamo: upoznali ste hakera!
Hakeri su izvrsni u brzom rješavanju problema, ne trudeći se cjelovito razumjeti arhitekturu (obično gužvom s programom za ispravljanje pogrešaka ili pokušajima i pogreškama).
Pa u čemu je kvaka? Oni riješe jedan problem, a stvore 10 drugih.
Savjetnici imaju tendenciju pokazati ovo ponašanje (budući da je njihovo vrijeme skupo i neće živjeti s posljedicama svojih promjena). Osim toga, mogu biti plaćeni za rješavanje tih 10 drugih problema i zasijavanje sigurnosti posla tako što će napraviti 100 novih.
Unatoč tome, svjedočio sam internim programerima koji čak i najskromnije savjetnike čine poput rock zvijezda. Jeste li ikad procijenili da problem traje 8 sati, ali neki voditelj proizvoda smanjuje vašu procjenu na samo 1 sat? To je obično kad se hakeri rode.
To je rečeno, ponekad vam treba brza isporuka (kao tijekom faze izrade prototipa u start-u kako biste potvrdili ideju) i prihvaćeno je smanjivanje zbog ograničenih resursa. Nikoga nije briga za lijep kod koji ne rješava nijedan problem. Ali ipak postoji razlika između rezanja škarama ili sjeckanja mačetom!
Uvid br. 8: Nedosljednost = ponos i fanatizam
Kad ste u Rimu, radite kao što to čine Rimljani. - poslovicaPostoji toliko mnogo pravila kodiranja. Nije zapravo važno koji je odabran. Ali nakon što vaš tim odabere neke konvencije, presudno je da ih se pridržava.
Ako suradnici ignoriraju neke ili sve konvencije, hakiraju ih ili su previše ponosni da promijene svoj stil kako bi odgovarao vašoj osnovi koda.
Najgore je od svega kada se zalažu za vlastite konvencije. To je čisti fanatizam. Možete biti sigurni da je programer uskogrud i u drugim stvarima.
Uvid # 9 WET kod = loša memorija
Suprotno od Dry („Ne ponavljaj se“) je WET („Uživamo u tipkanju“ ili „Dvaput napiši sve“).
Pa, greške se reproduciraju kroz neuredan postupak nazvan "kopiraj" i "zalijepi".
Iznenađujuće je mnogo vrsta WET koda. Na primjer:
- Funkcija ili klasa napisana dva puta, samo s manjim razlikama
- Varijabla koja sadrži vrijednost druge varijable
- Skup ponavljajućih uputa koji mogu biti u funkciji
To se razlikuje od napuhanog koda, jer se WET kôd, umjesto da bude samo složen ili uvijen, doslovno ponavlja.
Obično je ponavljajući kôd znak da se programer ne može sjetiti (ili još gore, nije vidio) drugog sličnog koda. Jedan od glavnih zadataka ljudskog mozga je otkrivanje obrazaca. Kad programer ne može uočiti sličan kod, to je znak neiskustva ili nepažnje prema detaljima.
Uvid # 10. Privremena zaobilaženja = nedostatak discipline
Ponekad će programeri ubrizgati brzo i prljavo rješenje kao privremeno rješenje, nadajući se da će ga jednog dana moći refaktorirati. To se obično događa zbog krajnjeg roka ili nedostatka znanja. Ali kao što svi znamo, privremena zaobilazna rješenja ostaju tu.
Privremena zaobilazna rješenja ukazuju na pragmatičnog inženjera kojem nedostaje ukusa ili ponosa u njihovom radu. Oni također mogu biti znak niskog samopoštovanja, jer ne žele razočarati nekoga drugog (šefa, kupca itd.).
Privremeno zaobilazno rješenje jedino je prihvatljivo za projekt učenja ili izradu prototipa (dokaz o konceptu). Pa čak je i u tim slučajevima najbolje izvršiti refaktorizaciju čim to znate učiniti na pravi način.
Uvid # 11: Mnogo ovisnosti = nepažnja za budućnost projekta
Ovisnosti treba redovito ažurirati. Kad projekt ima previše ovisnosti, to je znak aljkavosti.
Teško je reći što je "previše", ali osnovno je pravilo: ako projekt lako može preživjeti bez ovisnosti, suvišan je.
Druga je mjera da, ako za osnovni problem koji ovisnost rješava ne postoji potreban zahtjev, to je vjerojatno nepotrebno.
Tri su motivacije za nepotrebne ovisnosti:
Razlog br. 1: Programer previše želi naučiti nove stvari.
Uvozom novih ovisnosti, oni dobivaju priliku to učenje u stvarnom projektu.
Znatiželja je dobra, ali trebale bi postojati i druge platforme za učenje, poput sporednih projekata, kratkoročnih zadataka ili hackathona.
Ne želite izgubiti dobrog programera jer oni misle da ne mogu rasti na svom poslu, ali ne želite ni da se prema vašem proizvodu ponašaju kao prema projektu kućnih ljubimaca.
Razlog br. 2: To radi preambiciozni mlađi programer.
Pridošlice u bilo kojem području obično su preplavljene svim novim modnim riječima, a iz frustracije ili neznanja (ili preporuke "profesionalca") mogu odlučiti "skočiti u bazen" i naučiti sve odjednom. Ne dopustite im. Odaberite svoju tehnologiju.
Razlog br. 3: Programer ima prtljagu s drugog posla (ili sporednog projekta)
Žele imati prednost nad svojim vršnjacima unoseći nešto što samo oni vrlo dobro znaju.
Nažalost, ovo jednostavno rješenje nije jednostavno, ali meke vještine: tim mora dovesti u pitanje odabir svake ovisnosti, a ako postoji odgovarajući postupak pregleda i objedinjavanja koda, teško će se ušuljati užasan kôd, a da ga netko ne primijeti.
Ponekad dotični kaubojski koder može napraviti masovnu refaktorizaciju, a zatim dovesti tim u situaciju da prihvati cijelu promjenu jer je to već učinjeno. Pa nemoj! Zamolite ih da svoj zahtjev za povlačenjem podijele na manje dijelove i budite skeptični oko donošenja novih ovisnosti. Da, to je više posla, ali dugoročno će uštedjeti puno više vremena i energije.
Dobrim programerima je stalo do budućnosti njihovog projekta jer su potrošili svoj krajnji i najdragocjeniji resurs za njegovo stvaranje: svoje vrijeme!
Usput, puno ovisnosti i modernih modnih riječi također mogu biti znak da programer sastavlja životopis i da se već priprema za svoj sljedeći posao.
Šifra kaligrafije
Sad kad smo razgovarali o ogrebotinama kodova, razgovarajmo o drugoj strani: kodu koji je apsolutno zadovoljstvo čitati.
Neki čak kažu "kod je poezija".
Izvorni kod za jQuery ili lodash izvrsni su primjeri, ali gotovo sve popularne knjižnice na Githubu da će se mnogi suradnici na kraju približiti ljepoti. Ovo su moji prijatelji čudesna kaligrafija .
U osnovi je sjajan kod:
- Lako se čita, prati i uklanja pogreške
- Fleksibilno, podesivo i proširivo
- Pametno s korištenjem resursa
- Visoke performanse
Imajte na umu da neki projekti zahtijevaju drugačiji redoslijed. Na primjer, izvorni kôd Linuxa možda neće biti lako pročitati jer je izvedba važnija za operativni sustav. Ili skromni ugrađeni IoT program može žrtvovati konfiguraciju u korist optimizacije resursa.
U svakom slučaju, puno više možete saznati o svojim vršnjacima samo analizom njihovog koda. Kod govori više od riječi! Dakle, sljedeći put kada budete čitali neki kôd, isprobajte git blamenaredbu i počnite prepoznavati rukopis koda.
⚡ ️ Svidjelo vam se što ste pročitali? Slijedite me da budem obaviješten kad napišem nešto novo.
Također možete provjeriti zašto je programiranje najbolji posao ikad.