Kot pravijo, če se ne sramujete svoje stare kode, potem ne rastete kot programer - in strinjam se s tem mnenjem. Za zabavo sem začel programirati pred več kot 40 leti, profesionalno pa pred 30 leti, zato imam veliko napak. zelo veliko. Kot profesor računalništva svoje študente učim, naj se učijo iz napak – njihovih, mojih in drugih. Mislim, da je čas, da spregovorim o svojih napakah, da ne izgubim skromnosti. Upam, da bodo komu koristile.

Tretje mesto - prevajalnik Microsoft C

Moja učiteljica je menila, da Romea in Julije ne moremo šteti za tragedijo, ker lika nista imela tragične krivde - preprosto sta se obnašala neumno, kot bi se najstniki morali. Takrat se z njim nisem strinjal, zdaj pa v njegovem mnenju vidim zrno racionalnosti, predvsem v povezavi s programiranjem.

Ko sem končal drugi letnik na MIT, sem bil mlad in neizkušen, tako v življenju kot v programiranju. Poleti sem stažiral pri Microsoftu, v ekipi prevajalnika C. Sprva sem delal rutinske stvari, kot je podpora za profiliranje, nato pa mi je bilo zaupano delo na najbolj zabavnem delu prevajalnika (kot sem mislil) – optimizaciji zaledja. Zlasti sem moral izboljšati kodo x86 za izjave veje.

Odločen, da bom za vse možne primere napisal optimalno strojno kodo, sem se brezglavo vrgel v bazen. Če je bila gostota porazdelitve vrednosti visoka, sem jih vnesel prehodna miza. Če so imeli skupni delilnik, sem ga uporabil, da sem naredil tabelo bolj tesno (vendar le, če je bilo mogoče deliti z bitni premik). Ko so bile vse vrednosti potence dveh, sem naredil še eno optimizacijo. Če nabor vrednosti ni izpolnjeval mojih pogojev, sem ga razdelil na več optimiziranih primerov in uporabil že optimizirano kodo.

Bila je nočna mora. Mnogo let pozneje so mi povedali, da me programer, ki je podedoval mojo kodo, sovraži.

Lekcija naučena

Kot pišeta David Patterson in John Hennessy v računalniški arhitekturi in oblikovanju računalniških sistemov, je eno od glavnih načel arhitekture in oblikovanja, da stvari na splošno delujejo čim hitreje.

Pospešitev pogostih primerov bo učinkoviteje izboljšala delovanje kot optimizacija redkih primerov. Ironično je, da so običajni primeri pogosto enostavnejši od redkih. Ta logični nasvet predvideva, da veste, kateri primer velja za običajnega – to pa je mogoče le s postopkom skrbnega testiranja in merjenja.

V svojo obrambo sem poskušal ugotoviti, kako so izjave o vejah izgledale v praksi (na primer, koliko vej je bilo in kako so bile porazdeljene konstante), vendar leta 1988 te informacije niso bile na voljo. Vendar pa ne bi smel dodati posebnih primerov, ko trenutni prevajalnik ni mogel ustvariti optimalne kode za umetni primer, ki sem ga iznašel.

Moral sem poklicati izkušenega razvijalca in skupaj z njim razmisliti, kateri so pogosti primeri in se jih konkretno lotiti. Napisal bi manj kode, vendar je to dobra stvar. Kot je zapisal ustanovitelj Stack Overflow Jeff Atwood, je programerjev najhujši sovražnik programer sam:

Vem, da imaš najboljše namene, tako kot vsi mi. Ustvarjamo programe in radi pišemo kodo. Tako smo ustvarjeni. Menimo, da je vsako težavo mogoče rešiti z lepilnim trakom, doma narejeno berglo in ščepcem kode. Ne glede na to, kako koderje boli priznati, najboljša koda je koda, ki ne obstaja. Vsaka nova vrstica potrebuje odpravljanje napak in podporo, treba jo je razumeti. Ko dodate novo kodo, morate to storiti z odporom in gnusom, ker so bile vse druge možnosti izčrpane. Mnogi programerji napišejo preveč kode, zaradi česar je naš sovražnik.

Če bi napisal enostavnejšo kodo, ki bi zajemala pogoste primere, bi jo bilo veliko lažje posodobiti, če bi bilo potrebno. Za seboj sem pustil nered, s katerim se nihče ni hotel ukvarjati.

Drugo mesto: oglaševanje na družbenih omrežjih

Ko sem pri Googlu delal na oglaševanju v družabnih medijih (se spomnite Myspace?), sem v C++ napisal nekaj takega:

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)) {
  }
}

Programerji lahko takoj vidijo napako: zadnji argument bi moral biti j, ne i. Testiranje enote ni razkrilo napake, prav tako ne moj pregledovalec. Zagon je bil izveden in neke noči je moja koda šla na strežnik in zrušila vse računalnike v podatkovnem centru.

Nič hudega se ni zgodilo. Nikomur se ni nič zalomilo, saj je bila koda pred globalnim lansiranjem testirana v enem podatkovnem centru. Razen če inženirji SRE niso za nekaj časa prenehali igrati biljard in naredili majhen rollback. Naslednje jutro sem prejel e-poštno sporočilo z izpisom zrušitve, popravil kodo in dodal teste enote, ki bi ujeli napako. Ker sem sledil protokolu - drugače se moja koda preprosto ne bi zagnala - drugih težav ni bilo.

Lekcija naučena

Mnogi so prepričani, da bo tako velika napaka krivca zagotovo stala odpust, vendar ni tako: prvič, vsi programerji delajo napake, in drugič, le redko naredijo isto napako dvakrat.

Pravzaprav imam prijatelja programerja, ki je bil sijajen inženir in so ga odpustili zaradi ene same napake. Po tem so ga zaposlili pri Googlu (in kmalu napredovali) - o napaki, ki jo je naredil, je iskreno spregovoril v intervjuju in ni veljal za usodno.

Tukaj je kaj povej o Thomasu Watsonu, legendarnem šefu IBM-a:

Objavljeno je bilo vladno naročilo v vrednosti približno milijon dolarjev. IBM Corporation - ali bolje rečeno, Thomas Watson starejši osebno - ga je res želel dobiti. Na žalost prodajni predstavnik tega ni mogel storiti in IBM je izgubil ponudbo. Naslednji dan je ta uslužbenec prišel v pisarno gospoda Watsona in mu na mizo položil ovojnico. G. Watson se tega sploh ni potrudil pogledati – čakal je na zaposlenega in vedel je, da gre za odstopno pismo.

Watson je vprašal, kaj je šlo narobe.

Komercialist je podrobneje spregovoril o poteku razpisa. Imenoval je storjene napake, ki bi se jim lahko izognili. Nazadnje je rekel: »Gospod Watson, hvala, da ste mi dovolili razložiti. Vem, kako zelo smo potrebovali to naročilo. Vem, kako pomemben je bil,« in se pripravila na odhod.

Watson se mu je na vratih približal, ga pogledal v oči in mu vrnil kuverto z besedami: »Kako naj te izpustim? Pravkar sem vložil milijon dolarjev v tvoje izobraževanje.

Imam majico z napisom: "Če se res učiš na napakah, potem sem že mojster." Pravzaprav sem, ko gre za napake, doktor znanosti.

Prvo mesto: App Inventor API

Resnično grozljive napake prizadenejo ogromno uporabnikov, postanejo znane javnosti, popravljanje traja dolgo časa in jih naredijo tisti, ki jih ne bi mogli narediti. Moja največja napaka ustreza vsem tem kriterijem.

Čim slabše, tem bolje

berem esej Richarda Gabriela o tem pristopu v devetdesetih kot podiplomskem študentu in mi je tako všeč, da ga vprašam svoje študente. Če se ga ne spomniš dobro, si osveži spomin, majhen je. Ta esej na več načinov, vključno s preprostostjo, nasprotuje želji, da bi "dobilo vse prav" in pristopu "slabše je bolje".

Kako bi moralo biti: zasnova mora biti preprosta v izvedbi in vmesniku. Preprostost vmesnika je pomembnejša od preprostosti implementacije.

Čim slabše, tem bolje: zasnova mora biti preprosta v izvedbi in vmesniku. Enostavnost izvedbe je pomembnejša od preprostosti vmesnika.

Pozabimo na to za trenutek. Na žalost sem za dolga leta pozabil na to.

Izumitelj aplikacij

Med delom pri Googlu sem bil del ekipe Izumitelj aplikacij, spletno razvojno okolje povleci in spusti za ambiciozne razvijalce Android. Pisalo se je leto 2009 in hiteli smo izdati alfa verzijo pravočasno, da bi poleti lahko izvajali mojstrske tečaje za učitelje, ki bi okolje lahko uporabljali pri jesenskem poučevanju. Prostovoljno sem implementiral sprite, nostalgičen po tem, kako sem včasih pisal igre na TI-99/4. Za tiste, ki ne vedo, je sprite dvodimenzionalni grafični objekt, ki se lahko premika in deluje z drugimi elementi programske opreme. Primeri duhov vključujejo vesoljske ladje, asteroide, frnikole in loparje.

Implementirali smo objektno usmerjen App Inventor v Javi, tako da je tam samo kup predmetov. Ker se žoge in sprite obnašajo zelo podobno, sem ustvaril abstraktni razred sprite z lastnostmi (polja) X, Y, Speed ​​​​(hitrost) in Heading (smer). Imeli so enake metode za zaznavanje trkov, odbijanja od roba zaslona itd.

Glavna razlika med kroglo in spriteom je, kaj točno je narisano - zapolnjen krog ali raster. Ker sem najprej implementiral sprite, je bilo logično, da določim koordinate x in y zgornjega levega kota, kjer se nahaja slika.

Ko so sprite začeli delovati, sem se odločil, da lahko implementiram kroglične predmete z zelo malo kode. Edina težava je bila, da sem ubral najenostavnejšo pot (z vidika izvajalca), ki je označila x in y koordinate zgornjega levega kota konture, ki uokvirja kroglo.

Pravzaprav je bilo treba navesti x- in y-koordinati središča kroga, kot se uči v vseh matematičnih učbenikih in drugih virih, ki omenjajo kroge.

Za razliko od mojih preteklih napak ta ni prizadela le mojih kolegov, ampak tudi milijone uporabnikov App Inventorja. Mnogi od njih so bili otroci ali popolnoma novi v programiranju. Pri vsaki aplikaciji, v kateri je bila prisotna žoga, so morali opraviti veliko nepotrebnih korakov. Če se s smehom spominjam svojih drugih napak, me ta še danes kar poti.

To napako sem končno popravil šele pred kratkim, deset let kasneje. »Popravljeno«, ne »popravljeno«, ker kot pravi Joshua Bloch, so API-ji večni. Ker nismo mogli izvesti sprememb, ki bi vplivale na obstoječe programe, smo dodali lastnost OriginAtCenter z vrednostjo false v starih programih in true v vseh prihodnjih. Uporabniki si lahko zastavijo logično vprašanje: komu je sploh prišlo na misel postaviti izhodišče kje drugje kot središče. Komu? Enemu programerju, ki je bil pred desetimi leti prelen, da bi ustvaril normalen API.

Naučena lekcija

Ko delate na API-jih (kar mora včasih početi skoraj vsak programer), bi morali upoštevati najboljše nasvete, opisane v videu Joshue Blocha "Kako ustvariti dober API in zakaj je tako pomemben"Or na tem kratkem seznamu:

• API vam lahko prinese tako veliko korist kot veliko škodo.. Dober API ustvarja ponavljajoče se stranke. Slaba postane vaša večna nočna mora.
• Javni API-ji, tako kot diamanti, trajajo večno. Dajte vse od sebe: nikoli več ne bo priložnosti, da naredite vse prav.
• Orisi API-ja morajo biti kratki — ena stran s podpisi in opisi razredov in metod, ki ne zavzemajo več kot vrstico. To vam bo omogočilo preprosto prestrukturiranje API-ja, če se prvič ne izkaže popolno.
• Opišite primere uporabepreden implementirate API ali celo delate na njegovi specifikaciji. Tako se boste izognili implementaciji in podajanju popolnoma nedelujočega API-ja.

Če bi napisal celo kratek sinopsis z umetnim scenarijem, bi najverjetneje ugotovil napako in jo popravil. Če ne, bi to zagotovo naredil kdo od mojih kolegov. O vsaki odločitvi, ki ima daljnosežne posledice, je treba vsaj en dan premisliti (to ne velja le za programiranje).

Naslov eseja Richarda Gabriela, »Slabše je boljše«, se nanaša na prednost, ki jo prinaša biti prvi na trgu – tudi z nepopolnim izdelkom –, medtem ko nekdo drug preživi večnost v lovu za popolnim. Ko razmišljam o kodi sprite, se zavedam, da mi niti ni bilo treba napisati več kode, da bi jo naredil pravilno. Karkoli že kdo reče, sem se krepko zmotil.

Zaključek

Programerji vsak dan delajo napake, ne glede na to, ali pišejo kodo z napakami ali nočejo poskusiti nečesa, kar bi izboljšalo njihovo spretnost in produktivnost. Seveda si lahko programer, ne da bi delal tako hude napake, kot sem jih jaz. Toda nemogoče je postati dober programer, ne da bi prepoznali svoje napake in se iz njih učili.

Nenehno srečujem študente, ki menijo, da delajo preveč napak in zato niso narejeni za programiranje. Vem, kako pogost je sindrom prevarantov v IT. Upam, da se boste naučili lekcij, ki sem jih naštel - vendar si zapomnite glavno: vsak od nas dela napake - neprijetne, smešne, grozne. Presenečen in razburjen bom, če v prihodnje ne bom imel dovolj gradiva za nadaljevanje članka.

Vir: www.habr.com