Ako sa hovorí, ak sa nehanbíte za svoj starý kód, potom nerastiete ako programátor – a ja s týmto názorom súhlasím. Začal som programovať pre zábavu pred viac ako 40 rokmi a profesionálne pred 30 rokmi, takže mám veľa chýb. veľmi veľa. Ako profesor informatiky učím svojich študentov učiť sa z chýb – ich, mojich a iných. Myslím, že je čas porozprávať sa o svojich chybách, aby som nestratil skromnosť. Dúfam, že budú niekomu užitočné.

Tretie miesto - kompilátor Microsoft C

Moja učiteľka v škole veril, že Rómea a Júlie nemožno považovať za tragédiu, pretože postavy nemali žiadnu tragickú vinu – jednoducho sa správali hlúpo, ako by sa na tínedžerov patrilo. Vtedy som s ním nesúhlasil, ale teraz v jeho názore vidím zrnko racionality, najmä v súvislosti s programovaním.

Keď som skončil druhý ročník na MIT, bol som mladý a neskúsený v živote aj v programovaní. V lete som stážoval v Microsofte, v tíme kompilátora C. Najprv som robil rutinné veci ako podpora profilovania a potom ma poverili prácou na najzábavnejšej časti kompilátora (ako som si myslel) – optimalizácii backendu. Najmä som musel vylepšiť x86 kód pre príkazy pobočiek.

Odhodlaný napísať optimálny strojový kód pre každý možný prípad som sa bezhlavo vrhol do bazéna. Ak bola hustota rozloženia hodnôt vysoká, zadal som ich prechodová tabuľka. Ak mali spoločného deliteľa, použil som ho na sprísnenie tabuľky (ale iba v prípade, že by sa delenie dalo urobiť pomocou bitový posun). Keď boli všetky hodnoty mocniny dvoch, urobil som ďalšiu optimalizáciu. Ak množina hodnôt nespĺňala moje podmienky, rozdelil som ju do niekoľkých optimalizovateľných prípadov a použil som už optimalizovaný kód.

Bola to nočná mora. O mnoho rokov neskôr mi povedali, že programátor, ktorý zdedil môj kód, ma nenávidel.

Ponaučenie

Ako píšu David Patterson a John Hennessy v Computer Architecture and Computer Systems Design, jedným z hlavných princípov architektúry a dizajnu je, že vo všeobecnosti by veci mali fungovať čo najrýchlejšie.

Zrýchlenie bežných prípadov zlepší výkon efektívnejšie ako optimalizácia zriedkavých prípadov. Je iróniou, že bežné prípady sú často jednoduchšie ako zriedkavé. Táto logická rada predpokladá, že viete, ktorý prípad sa považuje za bežný – a to je možné len prostredníctvom procesu starostlivého testovania a merania.

Na svoju obranu som sa snažil prísť na to, ako v praxi vyzerali výkazy pobočiek (napríklad koľko bolo vetiev a ako boli rozdelené konštanty), ale v roku 1988 tieto informácie neboli dostupné. Nemal som však pridávať špeciálne prípady vždy, keď súčasný kompilátor nedokázal vygenerovať optimálny kód pre umelý príklad, s ktorým som prišiel.

Potreboval som zavolať skúsenému vývojárovi a spolu s ním porozmýšľať, aké sú bežné prípady a konkrétne ich riešiť. Napísal by som menej kódu, ale to je dobrá vec. Ako napísal zakladateľ Stack Overflow Jeff Atwood, najväčším nepriateľom programátora je samotný programátor:

Viem, že máte tie najlepšie úmysly, rovnako ako my všetci. Vytvárame programy a radi píšeme kód. Takí sme stvorení. Myslíme si, že každý problém sa dá vyriešiť lepiacou páskou, domácou barlou a štipkou kódu. Aj keď kódátorov bolí to priznať, najlepší kód je kód, ktorý neexistuje. Každý nový riadok potrebuje ladenie a podporu, treba mu porozumieť. Keď pridáte nový kód, mali by ste to urobiť s odporom a znechutením, pretože všetky ostatné možnosti boli vyčerpané. Mnoho programátorov píše príliš veľa kódu, čo z neho robí nášho nepriateľa.

Ak by som napísal jednoduchší kód, ktorý by pokrýval bežné prípady, v prípade potreby by bolo oveľa jednoduchšie aktualizovať. Zanechal som po sebe neporiadok, ktorý nikto nechcel riešiť.

Druhé miesto: reklama na sociálnych sieťach

Keď som v Google pracoval na reklame na sociálnych sieťach (pamätáte si Myspace?), napísal som niečo takéto v 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)) {
  }
}

Programátori môžu okamžite vidieť chybu: posledný argument by mal byť j, nie i. Testovanie jednotky neodhalilo chybu a ani môj recenzent. Spustenie bolo uskutočnené a raz v noci sa môj kód dostal na server a zrútil všetky počítače v dátovom centre.

Nič zlé sa nestalo. Nikomu sa nič nezlomilo, pretože pred globálnym spustením bol kód testovaný v rámci jedného dátového centra. Pokiaľ inžinieri SRE na chvíľu neprestanú hrať biliard a neurobia malý rollback. Nasledujúce ráno som dostal e-mail s výpisom z havárie, opravil kód a pridal testy jednotiek, ktoré by odhalili chybu. Keďže som postupoval podľa protokolu – inak by sa môj kód jednoducho nespustil – nevyskytli sa žiadne ďalšie problémy.

Ponaučenie

Mnohí sú si istí, že takáto závažná chyba bude určite stáť vinníka prepustenie, ale nie je to tak: po prvé, všetci programátori robia chyby a po druhé, zriedka urobia rovnakú chybu dvakrát.

V skutočnosti mám kamaráta programátora, ktorý bol skvelý inžinier a vyhodili ho za jedinú chybu. Potom bol prijatý do spoločnosti Google (a čoskoro povýšený) - úprimne hovoril o chybe, ktorú urobil v rozhovore, a nepovažovalo sa to za smrteľné.

To je čo povedať o Thomasovi Watsonovi, legendárnom šéfovi IBM:

Bola vyhlásená vládna objednávka v hodnote asi milión dolárov. IBM Corporation – alebo skôr osobne Thomas Watson starší – to naozaj chcela získať. Bohužiaľ, obchodný zástupca to nedokázal a IBM ponuku prehrala. Nasledujúci deň prišiel tento zamestnanec do kancelárie pána Watsona a položil mu na stôl obálku. Pán Watson sa na to ani neobťažoval pozrieť – čakal na zamestnanca a vedel, že ide o rezignáciu.

Watson sa spýtal, čo sa stalo.

O priebehu výberového konania podrobne hovoril obchodný zástupca. Pomenoval urobené chyby, ktorým sa dalo predísť. Nakoniec povedal: „Pán Watson, ďakujem, že ste ma nechali vysvetliť. Viem, ako veľmi sme potrebovali túto objednávku. Viem, aký bol dôležitý,“ a pripravil sa na odchod.

Watson k nemu pristúpil pri dverách, pozrel mu do očí a vrátil obálku so slovami: „Ako ťa môžem pustiť? Práve som investoval milión dolárov do vášho vzdelania.

Mám tričko s nápisom: "Ak sa naozaj učíš z chýb, tak som už majster." V skutočnosti, pokiaľ ide o chyby, som doktor vied.

Prvé miesto: App Inventor API

Skutočne hrozné chyby ovplyvňujú obrovské množstvo používateľov, stávajú sa verejne známymi, ich oprava trvá dlho a robia ich tí, ktorí ich nemohli urobiť. Moja najväčšia chyba spĺňa všetky tieto kritériá.

Čím horšie, tým lepšie

čítam esej Richarda Gabriela o tomto prístupe v deväťdesiatych rokoch ako postgraduálnemu študentovi a páči sa mi to natoľko, že to žiadam od svojich študentov. Ak si to nepamätáte dobre, osviežte si pamäť, je to málo. Táto esej v mnohých ohľadoch, vrátane jednoduchosti, kontrastuje s túžbou „urobiť to správne“ a prístupom „čo je horšie, tým lepšie“.

Ako by to malo byť: dizajn by mal byť jednoduchý v implementácii a rozhraní. Jednoduchosť rozhrania je dôležitejšia ako jednoduchosť implementácie.

Čím horšie, tým lepšie: dizajn by mal byť jednoduchý v implementácii a rozhraní. Jednoduchosť implementácie je dôležitejšia ako jednoduchosť rozhrania.

Zabudnime na to na chvíľu. Bohužiaľ som na to dlhé roky zabudol.

Aplikácia Inventor

Počas práce v Google som bol súčasťou tímu Aplikácia Inventor, online vývojové prostredie typu drag-and-drop pre začínajúcich vývojárov Androidu. Písal sa rok 2009 a ponáhľali sme sa, aby sme včas vydali alfa verziu, aby sme v lete mohli uskutočniť majstrovské kurzy pre učiteľov, ktorí by mohli využiť prostredie pri vyučovaní na jeseň. Dobrovoľne som sa prihlásil k implementácii spritov, nostalgicky za tým, ako som kedysi písal hry na TI-99/4. Pre tých, ktorí nevedia, sprite je dvojrozmerný grafický objekt, ktorý sa môže pohybovať a interagovať s inými softvérovými prvkami. Príklady škriatok zahŕňajú vesmírne lode, asteroidy, guľôčky a rakety.

Implementovali sme objektovo orientovaný App Inventor v jazyku Java, takže je tam len veľa objektov. Keďže sa gule a sprite správajú veľmi podobne, vytvoril som abstraktnú triedu sprite s vlastnosťami (polia) X, Y, Speed ​​​​(rýchlosť) a Heading (smer). Mali rovnaké metódy na detekciu kolízií, odrazu od okraja obrazovky atď.

Hlavným rozdielom medzi loptou a spritom je to, čo presne je nakreslené - vyplnený kruh alebo raster. Keďže som najskôr implementoval sprity, bolo logické určiť súradnice x a y ľavého horného rohu miesta, kde sa obrázok nachádzal.

Keď už škriatkovia fungovali, rozhodol som sa, že môžem implementovať guľôčkové objekty s veľmi malým kódom. Jediný problém bol v tom, že som zvolil najjednoduchšiu cestu (z pohľadu realizátora) s vyznačením x-ových a y-ových súradníc ľavého horného rohu obrysu orámujúceho guľu.

V skutočnosti bolo potrebné uviesť súradnice x a y stredu kruhu, ako sa to učí v akejkoľvek učebnici matematiky a akomkoľvek inom zdroji, kde sa spomínajú kruhy.

Na rozdiel od mojich minulých chýb sa táto dotkla nielen mojich kolegov, ale aj miliónov používateľov App Inventor. Mnohí z nich boli deti alebo úplne nováčikovia v programovaní. Pri práci na každej aplikácii, v ktorej bola loptička, museli vykonať množstvo zbytočných krokov. Ak si so smiechom spomeniem na svoje ďalšie chyby, tak pri tejto sa zapotím aj dnes.

Túto chybu som konečne opravil len nedávno, o desať rokov neskôr. „Opravené“, nie „opravené“, pretože ako hovorí Joshua Bloch, API sú večné. Keďže sme nemohli vykonať zmeny, ktoré by ovplyvnili existujúce programy, pridali sme vlastnosť OriginAtCenter s hodnotou false v starých programoch a true vo všetkých budúcich. Používatelia si môžu položiť logickú otázku: koho vôbec napadlo umiestniť východiskový bod niekam inam ako do stredu. komu? Jednému programátorovi, ktorý bol pred desiatimi rokmi príliš lenivý na vytvorenie normálneho API.

Ponaučenie

Pri práci na rozhraniach API (čo musí niekedy urobiť takmer každý programátor) by ste sa mali riadiť najlepšími radami uvedenými vo videu Joshuu Blocha “Ako vytvoriť dobré API a prečo je to také dôležité"alebo v tomto krátkom zozname:

• Rozhranie API vám môže priniesť veľké výhody aj veľké škody.. Dobré API vytvára opakovaných zákazníkov. Ten zlý sa stane vašou večnou nočnou morou.
• Verejné API, ako diamanty, trvajú večne. Daj do toho všetko: už nikdy nebude šanca urobiť všetko správne.
• Náčrt API by mal byť stručný — jedna strana s podpismi a popismi tried a metód, ktoré nezaberajú viac ako riadok. Umožní vám to jednoducho reštrukturalizovať API, ak nebude na prvý raz dokonalé.
• Opíšte prípady použitiapred implementáciou API alebo dokonca prácou na jeho špecifikácii. Vyhnete sa tak implementácii a špecifikácii úplne nefunkčného API.

Keby som napísal čo i len krátku synopsu umelým scenárom, s najväčšou pravdepodobnosťou by som chybu identifikoval a opravil. Ak nie, potom by to určite urobil niekto z mojich kolegov. Každé rozhodnutie, ktoré má ďalekosiahle dôsledky, je potrebné premyslieť aspoň deň (to platí nielen pre programovanie).

Názov eseje Richarda Gabriela „Horšie je lepšie“ odkazuje na výhodu, ktorú má byť prvým na trhu – dokonca aj s nedokonalým produktom –, zatiaľ čo niekto iný strávi večnosť hľadaním dokonalého produktu. Keď sa zamyslím nad kódom sprite, uvedomím si, že som ani nemusel písať ďalší kód, aby som to mal správne. Čokoľvek môže niekto povedať, hlboko som sa mýlil.

Záver

Programátori robia chyby každý deň, či už ide o písanie chybného kódu alebo o to, že nechcú vyskúšať niečo, čo zlepší ich zručnosti a produktivitu. Samozrejme, môžete byť programátorom bez toho, aby ste urobili také vážne chyby ako ja. Ale je nemožné stať sa dobrým programátorom bez toho, aby ste si uvedomili svoje chyby a poučili sa z nich.

Neustále sa stretávam so študentmi, ktorí majú pocit, že robia príliš veľa chýb, a preto nie sú stvorení na programovanie. Viem, aký častý je syndróm podvodníka v IT. Dúfam, že sa naučíte lekcie, ktoré som vymenoval - ale pamätajte na to hlavné: každý z nás robí chyby - trápne, vtipné, hrozné. Budem prekvapený a naštvaný, ak v budúcnosti nebudem mať dostatok materiálu na pokračovanie článku.

Zdroj: hab.com