Kako kažu, ako se ne sramite svog starog koda, onda ne napredujete kao programer - i ja se slažem s tim mišljenjem. Počeo sam programirati iz zabave prije više od 40 godina, a profesionalno prije 30 godina, tako da imam puno grešaka. puno. Kao profesor informatike, učim svoje studente da uče iz grešaka – njihovih, mojih i tuđih. Mislim da je vrijeme da progovorim o svojim greškama kako ne bih izgubio skromnost. Nadam se da će nekome biti od koristi.

Treće mjesto - Microsoft C kompajler

Moja učiteljica smatrala je da se Romeo i Julija ne mogu smatrati tragedijom jer likovi nemaju tragičnu krivnju – jednostavno su se ponašali glupo, kako bi tinejdžeri i trebali. Tada se nisam slagao s njim, ali sada vidim zrnce racionalnosti u njegovom mišljenju, pogotovo u vezi s programiranjem.

Kad sam završio drugu godinu na MIT-u, bio sam mlad i neiskusan, kako u životu tako iu programiranju. Ljeti sam stažirao u Microsoftu, u timu za kompajlere C. Prvo sam radio rutinske stvari poput podrške za profiliranje, a onda mi je povjeren rad na najzabavnijem dijelu kompilatora (kako sam mislio) – backend optimizaciji. Konkretno, morao sam poboljšati x86 kod za izjave grananja.

Odlučan da napišem optimalan strojni kod za svaki mogući slučaj, bezglavo sam se bacio u bazen. Ako je gustoća distribucije vrijednosti bila velika, unio sam ih prijelazni stol. Ako su imali zajednički djelitelj, koristio sam ga da tablicu učinim čvršćom (ali samo ako se dijeljenje može izvesti pomoću bitni pomak). Kada su sve vrijednosti bile potencije broja dva, napravio sam još jednu optimizaciju. Ako skup vrijednosti nije zadovoljio moje uvjete, podijelio sam ga u nekoliko optimiziranih slučajeva i koristio već optimizirani kod.

Bila je to noćna mora. Mnogo godina kasnije rečeno mi je da me programer koji je naslijedio moj kod mrzio.

Lekcija naučena

Kao što David Patterson i John Hennessy pišu u Računalnoj arhitekturi i dizajnu računalnih sustava, jedno od glavnih načela arhitekture i dizajna je općenito učiniti da stvari rade što je brže moguće.

Ubrzavanje uobičajenih slučajeva poboljšat će performanse učinkovitije od optimizacije rijetkih slučajeva. Ironično, uobičajeni slučajevi često su jednostavniji od rijetkih. Ovaj logičan savjet pretpostavlja da znate koji se slučaj smatra uobičajenim - a to je moguće samo kroz proces pažljivog testiranja i mjerenja.

U svoju obranu, pokušao sam dokučiti kako izjave o granama izgledaju u praksi (kao što je koliko je grana bilo i kako su konstante bile raspoređene), ali 1988. ove informacije nisu bile dostupne. Međutim, nisam trebao dodavati posebne slučajeve kad god trenutni prevodilac nije mogao generirati optimalan kod za umjetni primjer koji sam smislio.

Morao sam pozvati iskusnog programera i zajedno s njim razmisliti koji su uobičajeni slučajevi i konkretno ih riješiti. Napisao bih manje koda, ali to je dobra stvar. Kao što je osnivač Stack Overflowa Jeff Atwood napisao, programerov najgori neprijatelj je sam programer:

Znam da imaš najbolje namjere, kao i svi mi. Mi stvaramo programe i volimo pisati kod. Takvi smo stvoreni. Mislimo da se svaki problem može riješiti ljepljivom trakom, kućnom štakom i prstohvatom koda. Koliko god kodere boli to priznati, najbolji kod je kod koji ne postoji. Svaka nova linija treba otklanjanje pogrešaka i podršku, treba je razumjeti. Kada dodate novi kôd, trebali biste to učiniti s nevoljkošću i gađenjem jer su sve druge mogućnosti iscrpljene. Mnogi programeri pišu previše koda, što ga čini našim neprijateljem.

Da sam napisao jednostavniji kôd koji pokriva uobičajene slučajeve, bilo bi ga mnogo lakše ažurirati ako je potrebno. Iza sebe sam ostavio nered s kojim se nitko nije htio pozabaviti.

Drugo mjesto: oglašavanje na društvenim mrežama

Dok sam radio u Googleu na oglašavanju na društvenim mrežama (sjećate se Myspacea?), napisao sam nešto poput ovoga u C++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

Programeri mogu odmah vidjeti grešku: zadnji argument bi trebao biti j, a ne i. Jedinično testiranje nije otkrilo pogrešku, kao ni moj recenzent. Lansiranje je izvršeno i jedne noći moj je kod otišao na poslužitelj i srušio sva računala u podatkovnom centru.

Ništa se loše nije dogodilo. Nikome se ništa nije pokvarilo jer je kod prije globalnog lansiranja testiran unutar jednog podatkovnog centra. Osim ako inženjeri SRE-a nisu na neko vrijeme prestali igrati biljar i napravili mali povrat. Sljedećeg sam jutra primio e-poruku s crash dumpom, ispravio kod i dodao jedinične testove koji bi otkrili pogrešku. Budući da sam slijedio protokol - inače se moj kod jednostavno ne bi uspio pokrenuti - nije bilo drugih problema.

Lekcija naučena

Mnogi su uvjereni da će tako velika pogreška sigurno koštati krivca otkaza, ali to nije tako: prvo, svi programeri griješe, a drugo, rijetko čine istu pogrešku dva puta.

Zapravo, imam prijatelja programera koji je bio briljantan inženjer i otpušten je zbog jedne jedine pogreške. Nakon toga se zaposlio u Googleu (i ubrzo unaprijedio) - u jednom intervjuu iskreno je progovorio o pogrešci koju je napravio, a nije ocijenjena kobnom.

To je što reći o Thomasu Watsonu, legendarnom šefu IBM-a:

Objavljena je državna narudžba vrijedna oko milijun dolara. IBM Corporation - ili bolje rečeno, Thomas Watson stariji osobno - stvarno ga je želio dobiti. Nažalost, prodajni predstavnik to nije mogao učiniti i IBM je izgubio ponudu. Sljedeći dan, ovaj je zaposlenik došao u ured gospodina Watsona i stavio omotnicu na njegov stol. G. Watson se nije ni potrudio pogledati - čekao je zaposlenika i znao je da je to pismo otkaza.

Watson je pitao što je pošlo po zlu.

Predstavnik prodaje detaljno je govorio o tijeku natječaja. Naveo je učinjene pogreške koje su se mogle izbjeći. Na kraju je rekao: “Gospodine Watson, hvala što ste mi dopustili da vam objasnim. Znam koliko nam je trebala ova narudžba. Znam koliko je bio važan”, i spremio se za odlazak.

Watson mu je prišao na vratima, pogledao ga u oči i vratio mu omotnicu uz riječi: “Kako da te pustim? Upravo sam uložio milijun dolara u tvoje obrazovanje.

Imam majicu na kojoj piše: “Ako stvarno učiš na greškama, ja sam već majstor.” Zapravo, kad je riječ o greškama, ja sam doktor znanosti.

Prvo mjesto: App Inventor API

Uistinu strašne pogreške pogađaju ogroman broj korisnika, postaju javno poznate, dugo se ispravljaju, a čine ih oni koji ih nisu mogli napraviti. Moja najveća greška odgovara svim ovim kriterijima.

Što gore to bolje

čitam esej Richarda Gabriela o tom pristupu devedesetih godina kao diplomirani student, i toliko mi se sviđa da ga postavljam svojim studentima. Ako se ne sjećate dobro, osvježite pamćenje, malo je. Ovaj esej suprotstavlja želju da se "ispravi" i pristup "što gore to bolje" na mnoge načine, uključujući jednostavnost.

Kako bi trebalo biti: dizajn bi trebao biti jednostavan u implementaciji i sučelju. Jednostavnost sučelja važnija je od jednostavnosti implementacije.

Što gore, to bolje: dizajn bi trebao biti jednostavan u implementaciji i sučelju. Jednostavnost implementacije važnija je od jednostavnosti sučelja.

Zaboravimo to na trenutak. Nažalost, godinama sam to zaboravio.

Izumitelj aplikacija

Dok sam radio u Googleu, bio sam dio tima Izumitelj aplikacija, povuci i ispusti online razvojno okruženje za ambiciozne Android programere. Bila je 2009. godina i žurili smo da na vrijeme pustimo alfa verziju kako bismo ljeti mogli održavati majstorske tečajeve za nastavnike koji bi mogli koristiti okruženje za jesensku nastavu. Dobrovoljno sam implementirao spriteove, nostalgičan za načinom na koji sam nekada pisao igre na TI-99/4. Za one koji ne znaju, sprite je dvodimenzionalni grafički objekt koji se može kretati i komunicirati s drugim softverskim elementima. Primjeri duhova uključuju svemirske brodove, asteroide, kuglice i rekete.

Implementirali smo objektno orijentirani App Inventor u Javi, tako da postoji samo hrpa objekata unutra. Budući da se lopte i spriteovi ponašaju vrlo slično, stvorio sam apstraktnu klasu spriteova sa svojstvima (poljima) X, Y, Speed ​​​​(brzina) i Heading (smjer). Imali su iste metode za otkrivanje sudara, odbijanja od ruba zaslona itd.

Glavna razlika između kuglice i spritea je što je točno nacrtano - ispunjeni krug ili raster. Budući da sam prvi implementirao spriteove, bilo je logično odrediti x- i y-koordinate gornjeg lijevog kuta gdje se nalazi slika.

Nakon što su spriteovi radili, odlučio sam da mogu implementirati kuglaste objekte s vrlo malo koda. Jedini problem je bio što sam išao najjednostavnijim putem (sa stajališta implementatora), označavajući x- i y-koordinate gornjeg lijevog kuta konture koja uokviruje loptu.

Zapravo, bilo je potrebno naznačiti x- i y-koordinate središta kruga, kao što se uči u svakom udžbeniku matematike i bilo kojem drugom izvoru koji spominje krugove.

Za razliku od mojih prošlih pogrešaka, ova nije utjecala samo na moje kolege, već i na milijune korisnika App Inventora. Mnogi od njih bili su djeca ili potpuno novi u programiranju. Morali su izvesti puno nepotrebnih koraka pri radu na svakoj aplikaciji u kojoj je bila prisutna lopta. Ako se ostalih svojih grešaka sjetim sa smijehom, onda me ova i danas oznoji.

Napokon sam zakrpao ovu grešku tek nedavno, deset godina kasnije. “Zakrpan”, a ne “popravljen”, jer kako kaže Joshua Bloch, API-ji su vječni. Budući da nismo mogli napraviti promjene koje bi utjecale na postojeće programe, dodali smo svojstvo OriginAtCenter s vrijednošću false u starim programima i true u svim budućim. Korisnici mogu postaviti logično pitanje: kome je uopće palo na pamet postaviti početnu točku negdje drugdje osim u središte. Kome? Jednom programeru koji je prije deset godina bio previše lijen da napravi normalan API.

Naučene lekcije

Kada radite na API-jima (što gotovo svaki programer ponekad mora raditi), trebali biste slijediti najbolje savjete navedene u videu Joshue Blocha "Kako stvoriti dobar API i zašto je to toliko važno„ili u ovom kratkom popisu:

• API vam može donijeti i veliku korist i veliku štetu.. Dobar API stvara stalne kupce. Onaj loš postaje tvoja vječna noćna mora.
• Javni API-ji, poput dijamanata, traju vječno. Dajte sve od sebe: nikada više neće biti prilike da sve napravite kako treba.
• Opis API-ja trebao bi biti kratak — jedna stranica s potpisima i opisima klasa i metoda, ne zauzimajući više od retka. To će vam omogućiti jednostavno restrukturiranje API-ja ako prvi put ne ispadne savršeno.
• Opišite slučajeve uporabeprije implementacije API-ja ili čak rada na njegovoj specifikaciji. Na taj ćete način izbjeći implementaciju i specificiranje potpuno nefunkcionalnog API-ja.

Da sam napisao čak i kratki sinopsis s umjetnim scenarijem, najvjerojatnije bih identificirao grešku i ispravio je. Ako ne, onda bi to sigurno napravio netko od mojih kolega. O svakoj odluci koja ima dalekosežne posljedice potrebno je razmisliti barem jedan dan (ovo se ne odnosi samo na programiranje).

Naslov eseja Richarda Gabriela, "Što gore je bolje", odnosi se na prednost koju donosi biti prvi na tržištu - čak i s nesavršenim proizvodom - dok netko drugi provodi cijelu vječnost u potrazi za savršenim. Razmišljajući o sprite kodu, shvaćam da nisam ni morao napisati više koda da bih ga ispravio. Što god netko rekao, grdno sam se prevario.

Zaključak

Programeri griješe svaki dan, bilo da pišu pogrešan kod ili ne žele isprobati nešto što će poboljšati njihovu vještinu i produktivnost. Naravno, možete biti programer, a da ne napravite tako ozbiljne greške kao što sam ja napravio. Ali nemoguće je postati dobar programer bez prepoznavanja svojih grešaka i učenja iz njih.

Stalno susrećem studente koji osjećaju da rade previše pogrešaka i stoga nisu stvoreni za programiranje. Znam koliko je sindrom varalice čest u IT-u. Nadam se da ćete naučiti lekcije koje sam naveo - ali zapamtite onu glavnu: svatko od nas čini greške - neugodne, smiješne, užasne. Bit ću iznenađen i uzrujan ako u budućnosti ne budem imao dovoljno materijala za nastavak članka.

Izvor: www.habr.com