Nagu öeldakse, kui te ei häbene oma vana koodi, siis te ei kasva programmeerijaks - ja ma nõustun selle arvamusega. Alustasin programmeerimist oma lõbuks üle 40 aasta tagasi ja professionaalselt 30 aastat tagasi, nii et mul on palju vigu. väga palju. Arvutiteaduse professorina õpetan ma oma õpilasi õppima vigadest – nende, minu ja teiste vigadest. Ma arvan, et on aeg rääkida oma vigadest, et mitte kaotada oma tagasihoidlikkust. Loodan, et neist on kellelegi kasu.
Kolmas koht – Microsoft C kompilaator
Minu kooliõpetaja uskus, et Romeot ja Juliat ei saa pidada tragöödiaks, sest tegelastel polnud traagilist süüd – nad lihtsalt käitusid rumalalt, nagu teismelised peavad. Siis ei olnud ma temaga nõus, kuid nüüd näen temas ratsionaalsuse tera, eriti seoses programmeerimisega.
Selleks ajaks, kui ma MIT-i teise kursuse lõpetasin, olin noor ja kogenematu nii elus kui ka programmeerimises. Suvel käisin Microsoftis C-kompilaatorite meeskonnas praktikal.Algul tegin rutiinseid asju nagu profileerimise tugi ja siis usaldati mulle kompilaatori kõige lõbusam osa (nagu ma arvasin) - backend optimeerimine. Eelkõige pidin parandama harulausete x86 koodi.
Otsustasin kirjutada igaks võimalikuks juhtumiks optimaalse masinkoodi, heitsin end ülepeakaela basseini. Kui väärtuste jaotustihedus oli kõrge, sisestasin need . Kui neil oli ühine jagaja, kasutasin seda tabeli tihedamaks muutmiseks (aga ainult siis, kui jagamist sai teha kasutades ). Kui kõik väärtused olid kahe astmed, tegin veel ühe optimeerimise. Kui väärtuste komplekt ei vastanud minu tingimustele, jagasin selle mitmeks optimeeritavaks juhtumiks ja kasutasin juba optimeeritud koodi.
See oli õudusunenägu. Palju aastaid hiljem öeldi mulle, et programmeerija, kes mu koodi päris, vihkas mind.
Õppetund
Nagu David Patterson ja John Hennessy ajakirjas Computer Architecture and Computer Systems Design kirjutavad, on arhitektuuri ja disaini üks peamisi põhimõtteid panna asjad üldiselt tööle võimalikult kiiresti.
Tavaliste juhtumite kiirendamine parandab jõudlust tõhusamalt kui harvade juhtumite optimeerimine. Irooniline, et tavalised juhtumid on sageli lihtsamad kui haruldased. See loogiline nõuanne eeldab, et teate, millist juhtumit peetakse tavaliseks – ja see on võimalik ainult hoolika testimise ja mõõtmise käigus.
Oma kaitseks püüdsin välja mõelda, kuidas harulaused praktikas välja näevad (näiteks mitu haru oli ja kuidas konstandid jaotusid), kuid 1988. aastal seda teavet ei olnud. Siiski poleks ma pidanud lisama erijuhtumeid, kui praegune kompilaator ei suutnud genereerida optimaalset koodi minu pakutud tehisnäite jaoks.
Mul oli vaja helistada kogenud arendajale ja temaga koos mõelda, millised on levinud juhtumid ja nendega konkreetselt tegeleda. Kirjutaksin vähem koodi, aga see on hea. Nagu Stack Overflow asutaja Jeff Atwood kirjutas, on programmeerija halvim vaenlane programmeerija ise:
Ma tean, et teil on parimad kavatsused, nagu ka meil kõigil. Loome programme ja armastame koodi kirjutada. Nii me oleme tehtud. Arvame, et iga probleemi saab lahendada kleeplindi, isetehtud kargu ja näputäie koodiga. Nii palju kui kodeerijatel on valus seda tunnistada, on parim kood kood, mida pole olemas. Iga uus rida vajab silumist ja tuge, sellest tuleb aru saada. Uue koodi lisamisel peaksite seda tegema vastumeelselt ja tülgastusega, sest kõik muud võimalused on ammendatud. Paljud programmeerijad kirjutavad liiga palju koodi, muutes selle meie vaenlaseks.
Kui oleksin kirjutanud lihtsama koodi, mis hõlmaks levinud juhtumeid, oleks seda olnud palju lihtsam vajadusel uuendada. Jätsin endast maha segaduse, millega keegi tegeleda ei tahtnud.
Teine koht: reklaam sotsiaalvõrgustikes
Kui töötasin Google'is sotsiaalmeedia reklaamide kallal (mäletate Myspace'i?), kirjutasin C++ keeles midagi sellist:
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)) {
}
}Programmeerijad võivad kohe viga näha: viimane argument peaks olema j, mitte i. Üksuse testimine ei näidanud viga ega ka minu ülevaataja. Käivitamine viidi läbi ja ühel õhtul läks mu kood serverisse ja jooksis kõik andmekeskuse arvutid kokku.
Midagi hullu ei juhtunud. Kellegi jaoks ei läinud midagi katki, sest enne ülemaailmset turuletoomist testiti koodi ühes andmekeskuses. Välja arvatud juhul, kui SRE insenerid mõneks ajaks piljardi mängimise lõpetasid ja veidi tagasi ei tõmba. Järgmisel hommikul sain e-kirja krahhiga, parandasin koodi ja lisasin seadmetestid, mis vea tuvastaksid. Kuna järgisin protokolli – vastasel juhul ei töötaks mu kood lihtsalt käima –, siis muid probleeme polnud.
Õppetund
Paljud on kindlad, et selline suur viga maksab süüdlasele kindlasti vallandamise, kuid see pole nii: esiteks teevad kõik programmeerijad vigu ja teiseks teevad nad harva sama viga kaks korda.
Tegelikult on mul programmeerijast sõber, kes oli suurepärane insener ja vallandati üheainsa vea eest. Pärast seda võeti ta tööle Google'isse (ja peagi edutati) – ta rääkis ausalt ühes intervjuus tehtud veast ja seda ei peetud saatuslikuks.
See on mis IBMi legendaarse juhi Thomas Watsoni kohta:
Teatati umbes miljoni dollari väärtuses valitsuse korraldusest. IBM Corporation – õigemini Thomas Watson Sr isiklikult – tahtis seda väga saada. Kahjuks ei saanud müügiesindaja seda teha ja IBM kaotas pakkumise. Järgmisel päeval tuli see töötaja härra Watsoni kabinetti ja asetas tema lauale ümbriku. Härra Watson ei viitsinud seda isegi vaadata – ta ootas töötajat ja teadis, et see on lahkumisavaldus.
Watson küsis, mis valesti läks.
Müügiesindaja rääkis üksikasjalikult hanke käigust. Ta nimetas tehtud vigu, mida oleks saanud vältida. Lõpuks ütles ta: "Härra Watson, tänan teid, et lubasite mul selgitada. Ma tean, kui väga me seda tellimust vajasime. Ma tean, kui tähtis ta oli,” ja valmistus lahkuma.
Watson lähenes talle uksel, vaatas talle silma ja tagastas ümbriku sõnadega: „Kuidas ma saan sind lahti lasta? Investeerisin just miljon dollarit teie haridusse.
Mul on T-särk, millel on kirjas: "Kui sa tõesti õpid vigadest, siis ma olen juba meister." Tegelikult, mis puudutab vigu, siis ma olen teaduste doktor.
Esimene koht: App Inventori API
Tõeliselt kohutavad vead mõjutavad suurt hulka kasutajaid, muutuvad avalikuks, nende parandamine võtab kaua aega ja neid teevad need, kes poleks saanud neid teha. Minu suurim viga vastab kõigile neile kriteeriumidele.
Mida hullem, seda parem
ma loen selle lähenemise kohta üheksakümnendatel kraadiõppurina ja mulle meeldib see nii väga, et küsin seda oma õpilastelt. Kui te seda hästi ei mäleta, värskendage oma mälu, see on väike. See essee vastandab mitmel viisil, sealhulgas lihtsuses, soovi "asi saada õigesti" ja "halvem, seda parem".
Kuidas see peaks olema: disain peaks olema nii teostuses kui ka liideses lihtne. Liidese lihtsus on olulisem kui rakendamise lihtsus.
Mida hullem, seda parem: disain peaks olema nii teostuses kui ka liideses lihtne. Rakenduse lihtsus on olulisem kui liidese lihtsus.
Unustame selle hetkeks. Kahjuks unustasin selle paljudeks aastateks.
Rakenduse leiutaja
Google'is töötades kuulusin ma meeskonda , pukseeritav veebiarenduskeskkond ambitsioonikatele Androidi arendajatele. Oli 2009. aastal ja kiirustasime alfaversiooni õigel ajal välja andmisega, et saaksime suvel läbi viia meistrikursusi õpetajatele, kes saaksid sügisel õppetöös keskkonda kasutada. Võtsin vabatahtlikult kasutusele spraite, tundes nostalgiat selle järele, kuidas ma TI-99/4-ga mänge kirjutasin. Neile, kes ei tea, on sprite kahemõõtmeline graafiline objekt, mis suudab liikuda ja suhelda teiste tarkvaraelementidega. Spraitide näideteks on kosmoselaevad, asteroidid, marmorid ja reketid.
Rakendasime Javas objektorienteeritud App Inventori, nii et seal on vaid hulk objekte. Kuna pallid ja spraidid käituvad väga sarnaselt, lõin abstraktse spraitide klassi omadustega (väljad) X, Y, kiirus (kiirus) ja Heading (suund). Neil olid samad meetodid kokkupõrgete tuvastamiseks, ekraani servast põrkamiseks jne.
Peamine erinevus palli ja spraitide vahel on see, mis täpselt joonistatakse – täidetud ring või raster. Kuna ma juurutasin esmalt spraite, siis oli loogiline määrata pildi asukoha vasaku ülanurga x- ja y-koordinaadid.
Kui spraidid töötasid, otsustasin, et saan rakendada palliobjekte väga väikese koodiga. Ainus probleem oli selles, et võtsin ette kõige lihtsama marsruudi (rakendaja seisukohalt), näidates ära palli raamiva kontuuri vasaku ülanurga x- ja y-koordinaadid.
Tegelikult oli vaja märkida ringi keskpunkti x- ja y-koordinaadid, nagu õpetatakse igas matemaatikaõpikus ja mis tahes muus ringe mainivas allikas.
Erinevalt minu varasematest vigadest mõjutas see mitte ainult minu kolleege, vaid ka miljoneid App Inventori kasutajaid. Paljud neist olid lapsed või programmeerimises täiesti uued. Nad pidid tegema palju tarbetuid samme iga rakenduse kallal, kus pall oli. Kui ma oma muid vigu naerdes meenutan, siis see ajab mind tänagi higistama.
Lõpuks parandasin selle vea alles hiljuti, kümme aastat hiljem. "Paigutatud", mitte "parandatud", sest nagu Joshua Bloch ütleb, on API-d igavesed. Kuna me ei saa teha muudatusi, mis võiksid mõjutada olemasolevaid programme, lisasime atribuudi OriginAtCenter väärtusega false vanades programmides ja tõene kõigis tulevastes. Kasutajad võivad esitada loogilise küsimuse: kes üldse mõtles alguspunkti asetada mujale kui keskpunkti. Kellele? Ühele programmeerijale, kes oli kümme aastat tagasi liiga laisk, et normaalset API-d luua.
Õppetunnid
API-dega töötades (mida peaaegu iga programmeerija peab mõnikord tegema), peaksite järgima Joshua Blochi videos toodud parimaid nõuandeid."või :
- API võib tuua teile nii suurt kasu kui ka suurt kahju.. Hea API loob korduvaid kliente. Halbast saab sinu igavene õudusunenägu.
- Avalikud API-d, nagu teemandid, kestavad igavesti. Andke endast kõik: kunagi pole enam võimalust kõike õigesti teha.
- API ülevaade peaks olema lühike — üks lehekülg klasside ja meetodite allkirjade ja kirjeldustega, mis ei hõlma rohkem kui rida. See võimaldab teil API-d hõlpsalt ümber struktureerida, kui see ei osutu esimesel korral täiuslikuks.
- Kirjeldage kasutusjuhtumeidenne API juurutamist või isegi selle spetsifikatsiooni kallal töötamist. Nii väldite täiesti mittefunktsionaalse API juurutamist ja määramist.
Kui ma oleksin tehiskirjaga kirjutanud kasvõi lühikese kokkuvõtte, oleksin tõenäoliselt vea tuvastanud ja selle parandanud. Kui ei, siis üks mu kolleegidest teeks seda kindlasti. Iga otsus, millel on kaugeleulatuvad tagajärjed, vajab vähemalt päeva mõtlemist (see ei kehti ainult programmeerimise kohta).
Richard Gabrieli essee pealkiri "Halvem on parem" viitab eelisele, mis annab turule esimesena jõudmise – isegi ebatäiusliku toote puhul –, samal ajal kui keegi teine veedab terve igaviku ideaalset taga ajades. Sprite koodi mõtiskledes saan aru, et ma ei pidanud isegi rohkem koodi kirjutama, et seda õigesti teha. Mida iganes võib öelda, ma eksisin rängalt.
Järeldus
Programmeerijad teevad iga päev vigu, olgu selleks siis lollaka koodi kirjutamine või nad ei taha proovida midagi, mis nende oskusi ja tootlikkust parandaks. Muidugi võite olla programmeerija, tegemata selliseid tõsiseid vigu nagu mina. Kuid on võimatu saada heaks programmeerijaks ilma oma vigu tunnistamata ja nendest õppimata.
Kohtan pidevalt õpilasi, kes tunnevad, et nad teevad liiga palju vigu ja seetõttu ei ole nad programmeerimisest välja lõigatud. Ma tean, kui levinud on petisündroom IT-s. Loodan, et õpite minu loetletud õppetunnid – kuid pidage meeles peamist: igaüks meist teeb vigu – piinlikke, naljakaid, kohutavaid. Olen üllatunud ja ärritunud, kui mul pole tulevikus artikli jätkamiseks piisavalt materjali.
Allikas: www.habr.com