Kao što se kaže, ako se ne sramite svog starog koda, ne napredujete kao programer - i slažem se. Počeo sam programirati iz zabave prije više od 40 godina, a profesionalno prije 30 godina, tako da sam napravio dosta grešaka. punoKao profesor informatike, učim svoje studente da uče iz grešaka - svojih, mojih i tuđih. Mislim da je vrijeme da podijelim svoje, kako ne bih izgubio skromnost. Nadam se da će nekome biti od pomoći.
Treće mjesto zauzima Microsoftov C kompajler.
Moj učitelj je vjerovao da se Romeo i Julija ne mogu smatrati tragedijom jer likovi nisu tragično krivi - jednostavno su se ponašali glupo, kao što to tinejdžeri rade. Tada se nisam slagao s njim, ali sada vidim zrnce istine u njegovom mišljenju - posebno u vezi s programiranjem.
Do završetka druge godine na MIT-u, bio sam mlad i neiskusan, i u životu i u programiranju. Tog ljeta sam stažirao u Microsoftu, u timu za C kompajler. Isprva sam radio rutinske poslove poput podrške za profiliranje, ali onda sam dobio zadatak da radim na onome što sam smatrao najzabavnijim dijelom kompajlera - optimizaciji pozadine. Konkretno, bio sam zadužen za poboljšanje x86 koda za naredbe grananja.
Odlučan napisati optimalni strojni kod za svaki mogući slučaj, zaronio sam glavom naprijed. Ako je gustoća raspodjele vrijednosti bila visoka, unosio sam ih u Ako su imali zajedničkog djelitelja, koristio sam ga da tablicu učinim gušćom (ali samo ako se dijeljenje moglo izvršiti pomoću ). Kada su sve vrijednosti bile potencije broja dva, izvršio sam još jednu optimizaciju. Ako skup vrijednosti nije zadovoljavao moje uvjete, podijelio sam ga u nekoliko optimiziranih slučajeva i koristio optimizirani kod.
Bila je to noćna mora. Godinama kasnije, rečeno mi je da me programer koji je naslijedio moj kod mrzi.
Naučena lekcija
Kao što David Patterson i John Hennessy pišu u knjizi Računalna arhitektura i dizajn 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 su često jednostavniji od rijetkih slučajeva. Ovaj logičan savjet pretpostavlja da znate koji se slučaj smatra uobičajenim - a to je moguće samo pažljivim testiranjem i mjerenjem.
U svoju obranu, pokušao sam shvatiti kako naredbe grananja izgledaju u praksi (na primjer, koliko grana ima i kako su konstante raspoređene), ali te informacije nisu bile dostupne 1988. Međutim, nisam trebao dodavati posebne slučajeve svaki put kada stvarni kompajler nije mogao generirati optimalni kod za moj umjetni primjer.
Trebao sam pozvati iskusnog programera i surađivati s njim kako bismo otkrili uobičajene slučajeve upotrebe i konkretno ih riješili. Napisao bih manje koda, ali to je zapravo dobra stvar. Kao što je napisao osnivač Stack Overflowa Jeff Atwood, programer je najgori neprijatelj sam sebi:
Znam da imaš najbolje namjere, kao i svi mi. Stvaramo programe i volimo pisati kod. Takvi smo jednostavno. Mislimo da se svaki problem može riješiti ljepljivom trakom, domaćim trikom i prstohvatom koda. Koliko god programerima bilo bolno priznati, najbolji kod je onaj koji ne postoji. Svaki novi redak treba otklanjanje pogrešaka i održavanje; treba ga razumjeti. Kada dodajete novi kod, trebali biste to činiti s nevoljkošću i gađenjem, jer su sve druge mogućnosti iscrpljene. Mnogi programeri pišu previše koda, čineći ga našim neprijateljem.
Da sam napisao jednostavniji kod koji pokriva uobičajene slučajeve, bilo bi ga puno lakše ažurirati ako je potrebno. Ali ostavio sam za sobom nered s kojim se nitko nije htio baviti.
Drugo mjesto: oglašavanje na društvenim mrežama
Kad 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 bi mogli odmah uočiti grešku: posljednji argument trebao bi biti j, a ne i. Jedinično testiranje nije otkrilo grešku, a ni moj recenzent je nije primijetio. Izvršeno je pokretanje i jedne noći moj kod je udario u poslužitelj i srušio sva računala u podatkovnom centru.
Ništa strašno se nije dogodilo. Nitko nije ništa pokvario jer je kod testiran unutar jednog podatkovnog centra prije globalnog lansiranja. SRE inženjeri su nakratko prestali igrati biljar i napravili mali povratak na prethodnu verziju. Sljedeće jutro primio sam e-poruku s izvješćima o rušenju sustava, ispravio kod i dodao jedinične testove koji bi otkrili grešku. Budući da sam slijedio protokol - inače se moj kod jednostavno ne bi pokrenuo - nisu se pojavili nikakvi drugi problemi.
Naučena lekcija
Mnogi ljudi vjeruju da će takva velika pogreška neizbježno dovesti do otkaza odgovorne osobe, ali to nije istina: prvo, svi programeri griješe, a drugo, rijetko naprave istu pogrešku dvaput.
Zapravo, poznajem programera - briljantnog inženjera - koji je dobio otkaz zbog jedne jedine pogreške. Nakon toga je zaposlen u Googleu (i ubrzo unaprijeđen) - bio je iskren o pogrešci na razgovoru za posao i nije se smatrala kobnom.
To je što o Thomasu Watsonu, legendarnom šefu IBM-a:
Objavljen je vladin ugovor vrijedan otprilike milijun dolara. IBM - ili bolje rečeno, osobno Thomas Watson stariji - želio je dobiti ga. Nažalost, prodajni predstavnik to nije uspio učiniti, te je IBM izgubio natječaj. Sljedećeg dana, zaposlenik je došao u ured gospodina Watsona i stavio omotnicu na njegov stol. Gospodin Watson nije je ni pogledao - očekivao je zaposlenika i znao je da je to pismo o ostavci.
Watson je pitao što je pošlo po zlu.
Prodajni predstavnik detaljno je opisao postupak natječaja. Istaknuo je učinjene pogreške i one koje su se mogle izbjeći. Na kraju je rekao: „Gospodine Watson, hvala vam što ste mi dopustili da objasnim. Znam koliko nam je bila potrebna ova narudžba. Znam koliko je bila važna“, i okrenuo se da ode.
Watson mu je prišao na vratima, pogledao ga u oči i vratio mu omotnicu rekavši: „Kako te mogu pustiti? Upravo sam uložio milijun dolara u tvoje obrazovanje.“
Imam majicu na kojoj piše: "Ako se stvarno učiš iz grešaka, onda sam već magisterij." Zapravo, što se tiče grešaka, ja sam doktor znanosti.
Prvo mjesto: App Inventor API
Uistinu katastrofalne pogreške utječu na ogroman broj korisnika, postaju javno poznate, dugo se ispravljaju i čine ih oni koji su ih mogli izbjeći. Moja najveća pogreška ispunjava sve te kriterije.
Što gore, to bolje
Čitao/la sam O ovom pristupu sam pisao 1990-ih kao poslijediplomski student i toliko mi se sviđa da ga zadajem svojim studentima. Ako se ne sjećate dobro, osvježite pamćenje; kratak je. U ovom eseju, želja da se "to napravi kako treba" i pristup "gore je bolje" suprotstavljaju se na mnogim razinama, uključujući jednostavnost.
Pravi način: dizajn bi trebao biti jednostavan za implementaciju i jednostavan za korištenje. Jednostavnost sučelja je važnija od jednostavnosti implementacije.
Što gore, to bolje: dizajn bi trebao biti jednostavan za implementaciju i lak za korištenje. Jednostavnost implementacije je važnija od jednostavnosti korištenja.
Zaboravimo na to na trenutak. Nažalost, ja sam to zaboravio dugi niz godina.
Izumitelj aplikacija
Dok sam radio u Googleu, bio sam dio tima , online razvojno okruženje za početnike s metodom "povuci i ispusti" Android-developere. Bila je 2009. godina i žurili smo s objavljivanjem alfa verzije na vrijeme kako bismo mogli održati radionice za učitelje tijekom ljeta, koji bi potom mogli koristiti okruženje u svojim učionicama na jesen. Volontirao sam za implementaciju spriteova, nostalgičan za svojim vremenom pisanja igara na TI-99/4. Za one koji nisu upoznati, sprite je dvodimenzionalni grafički objekt koji se može pomicati i komunicirati s drugim softverskim elementima. Primjeri spriteova uključuju svemirske brodove, asteroide, lopte i vesla.
Implementirali smo objektno orijentirani App Inventor u Javi, tako da je bilo mnoštvo objekata. Budući da su se lopte i spriteovi ponašali vrlo slično, stvorio sam apstraktnu klasu spriteova sa svojstvima (poljima) za X, Y, brzinu i smjer. Dijelili su iste metode za otkrivanje sudara, odbijanja od ruba ekrana i tako dalje.
Glavna razlika između lopte i spritea je ono što se zapravo crta - ispunjeni krug ili rasterski oblik. Budući da sam prvo implementirao spriteove, imalo je smisla odrediti x i y koordinate gornjeg lijevog kuta lokacije slike.
Nakon što su spriteovi proradili, odlučio sam da mogu implementirati objekte lopte s vrlo malo koda. Jedini problem je bio što sam odabrao najlakši put (iz perspektive implementatora) određivanjem x i y koordinata gornjeg lijevog kuta obrisa koji uokviruje loptu.
Zapravo, bilo je potrebno naznačiti x- i y-koordinate središta kruga, kako se uči u bilo kojem udžbeniku matematike i bilo kojem drugom izvoru koji spominje krugove.
Za razliku od mojih prethodnih pogrešaka, ova je utjecala ne samo na moje kolege već i na milijune korisnika App Inventora. Mnogi od njih bili su djeca ili potpuni početnici u programiranju. Morali su izvršiti mnogo nepotrebnih koraka pri radu na svakoj aplikaciji koja je uključivala sferu. Dok se smijem svojim drugim pogreškama, ova me i danas tjera na znoj.
Konačno sam nedavno, deset godina kasnije, zakrpao ovu grešku. "Zakrpao", a ne "popravio", 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 bi se prirodno mogli pitati tko je ikada pomislio postaviti izvor bilo gdje drugdje osim u središte. Tko? Jedan programer koji je bio previše lijen da stvori pravi API prije deset godina.
Naučene lekcije
Prilikom rada na API-jima (što gotovo svaki programer mora raditi u nekom trenutku), trebali biste slijediti najbolje savjete navedene u videu Joshue Blocha "„ili :
- API vam može donijeti i veliku korist i veliku štetu.Dobar API stvara lojalne kupce. Loš postaje vaša stalna noćna mora.
- Javni API-ji, poput dijamanata, su vječni.Daj sve od sebe: nećeš imati drugu priliku da to napraviš kako treba.
- API nacrti trebaju biti sažeti — jedna stranica s potpisima i opisima klasa i metoda, od kojih svaki zauzima najviše jedan redak. To će vam omogućiti jednostavno restrukturiranje API-ja ako prvi put nije savršen.
- Opišite slučajeve upotrebePrije implementacije API-ja ili čak rada na njegovoj specifikaciji, izbjeći ćete implementaciju i specificiranje potpuno nefunkcionalnog API-ja.
Da sam napisao čak i kratki nacrt sa simuliranim scenarijem, vjerojatno bih uočio grešku i ispravio je. Ako ne, netko od mojih kolega bi sigurno to učinio. Svaka odluka s dalekosežnim posljedicama zahtijeva barem dan razmišljanja (ovo se ne odnosi samo na programiranje).
Naslov eseja Richarda Gabriela, "Što gore to bolje", aludira na prednost koju donosi biti prvi na tržištu - čak i s nesavršenim proizvodom - dok netko drugi provodi vječnost jureći savršenstvo. Razmišljajući o sprite kodu, shvaćam da nisam čak ni trebao napisati više koda da bih ga ispravno napravio. U konačnici, bio sam u krivu.
Zaključak
Programeri griješe svaki dan - bilo da se radi o pisanju grešaka u kodu ili neisprobavanju nečega što bi poboljšalo njihove vještine i produktivnost. Naravno, možete biti programer bez ozbiljnih pogrešaka poput onih koje sam ja napravio. Ali postati dobar programer bez prepoznavanja vlastitih pogrešaka i učenja iz njih je nemoguće.
Stalno susrećem studente koji osjećaju da rade previše greš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 najvažniju: svi griješe - neugodno, smiješno i strašno. Bit ću iznenađen i razočaran ako ne budem imao dovoljno materijala za nastavak ovog članka u budućnosti.
Izvor: www.habr.com
