Som de sier, hvis du ikke skammer deg over den gamle koden din, vokser du ikke som programmerer - og jeg er enig i denne oppfatningen. Jeg begynte å programmere for moro skyld for over 40 år siden, og profesjonelt for 30 år siden, så jeg har mange feil. veldig mye. Som professor i informatikk lærer jeg elevene mine å lære av feil – deres, mine og andres. Jeg tror det er på tide å snakke om feilene mine for ikke å miste beskjedenhet. Jeg håper de vil være nyttige for noen.
Tredjeplass - Microsoft C-kompilator
Skolelæreren min mente at Romeo og Julie ikke kunne betraktes som en tragedie fordi karakterene ikke hadde noen tragisk skyldfølelse – de oppførte seg rett og slett dumt, slik tenåringer burde. Jeg var ikke enig med ham da, men nå ser jeg et snev av rasjonalitet etter hans mening, spesielt i forbindelse med programmering.
Da jeg fullførte mitt andre år ved MIT, var jeg ung og uerfaren, både i livet og i programmering. Om sommeren internerte jeg hos Microsoft, på C-kompilatorteamet. Først gjorde jeg rutinemessige ting som profileringsstøtte, og så ble jeg betrodd å jobbe med den morsomste delen av kompilatoren (som jeg trodde) - backend-optimalisering. Spesielt måtte jeg forbedre x86-koden for grenutsagn.
Fast bestemt på å skrive den optimale maskinkoden for alle mulige tilfeller, kastet jeg meg hodestups i bassenget. Hvis distribusjonstettheten av verdier var høy, skrev jeg dem inn . Hvis de hadde en felles deler, brukte jeg den til å gjøre bordet strammere (men bare hvis delingen kunne gjøres med ). Da alle verdiene var potenser av to, gjorde jeg en ny optimalisering. Hvis et sett med verdier ikke tilfredsstilte betingelsene mine, delte jeg det opp i flere optimaliserbare tilfeller og brukte den allerede optimaliserte koden.
Det var et mareritt. Mange år senere ble jeg fortalt at programmereren som arvet koden min hatet meg.
Lært en lekse
Som David Patterson og John Hennessy skriver i Computer Architecture and Computer Systems Design, er et av hovedprinsippene for arkitektur og design å få ting til å fungere så raskt som mulig.
Å øke hastigheten på vanlige tilfeller vil forbedre ytelsen mer effektivt enn å optimalisere sjeldne tilfeller. Ironisk nok er vanlige tilfeller ofte enklere enn sjeldne. Dette logiske rådet forutsetter at du vet hvilket tilfelle som anses som vanlig – og dette er kun mulig gjennom en prosess med nøye testing og måling.
Til mitt forsvar forsøkte jeg å finne ut hvordan grenutsagn så ut i praksis (som hvor mange grener det var og hvordan konstanter var fordelt), men i 1988 var ikke denne informasjonen tilgjengelig. Jeg skulle imidlertid ikke ha lagt til spesielle tilfeller når den nåværende kompilatoren ikke kunne generere optimal kode for det kunstige eksemplet jeg kom opp med.
Jeg trengte å ringe en erfaren utvikler og sammen med ham tenke på hva de vanlige sakene var og behandle dem spesifikt. Jeg ville skrevet mindre kode, men det er bra. Som Stack Overflow-grunnlegger Jeff Atwood skrev, er programmererens verste fiende programmereren selv:
Jeg vet at du har de beste intensjonene, som vi alle har. Vi lager programmer og elsker å skrive kode. Det er slik vi er laget. Vi tenker at ethvert problem kan løses med gaffatape, en hjemmelaget krykke og en klype kode. Like mye som det plager kodere å innrømme det, den beste koden er koden som ikke eksisterer. Hver ny linje trenger feilsøking og støtte, den må forstås. Når du legger til ny kode, bør du gjøre det med motvilje og avsky fordi alle andre alternativer er uttømt. Mange programmerere skriver for mye kode, noe som gjør det til vår fiende.
Hvis jeg hadde skrevet enklere kode som dekket vanlige tilfeller, hadde det vært mye lettere å oppdatere om nødvendig. Jeg etterlot meg et rot som ingen ønsket å håndtere.
Andreplass: annonsering på sosiale nettverk
Da jeg jobbet i Google med annonsering på sosiale medier (husker du Myspace?), skrev jeg noe slikt i 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)) {
}
}Programmerere kan umiddelbart se feilen: det siste argumentet skal være j, ikke i. Enhetstesting avslørte ikke feilen, og det gjorde heller ikke anmelderen min. Lanseringen ble gjennomført, og en natt gikk koden min til serveren og krasjet alle datamaskinene i datasenteret.
Ingenting vondt skjedde. Ingenting gikk i stykker for noen, for før den globale lanseringen ble koden testet i ett datasenter. Med mindre SRE-ingeniører sluttet å spille biljard en stund og gjorde en liten tilbakerulling. Neste morgen fikk jeg en e-post med en krasjdump, rettet koden og la til enhetstester som ville fange opp feilen. Siden jeg fulgte protokollen – ellers ville koden min rett og slett ikke kjøre – var det ingen andre problemer.
Lært en lekse
Mange er sikre på at en så stor feil definitivt vil koste den skyldige oppsigelsen, men dette er ikke slik: For det første gjør alle programmerere feil, og for det andre gjør de sjelden den samme feilen to ganger.
Faktisk har jeg en programmerervenn som var en strålende ingeniør og fikk sparken for å ha gjort en enkelt feil. Etter det ble han ansatt hos Google (og snart forfremmet) - han snakket ærlig om feilen han gjorde i et intervju, og den ble ikke ansett som dødelig.
Det er hva om Thomas Watson, den legendariske lederen av IBM:
En statlig ordre verdt rundt en million dollar ble annonsert. IBM Corporation – eller rettere sagt, Thomas Watson Sr. personlig – ønsket virkelig å få det. Dessverre klarte ikke salgsrepresentanten å gjøre dette og IBM tapte budet. Dagen etter kom denne ansatte inn på Mr. Watsons kontor og la en konvolutt på skrivebordet hans. Mr. Watson brydde seg ikke engang om å se på det – han ventet på en ansatt og visste at det var et oppsigelsesbrev.
Watson spurte hva som gikk galt.
Salgsrepresentanten fortalte detaljert om fremdriften i anbudet. Han nevnte feil som kunne vært unngått. Til slutt sa han: «Mr. Watson, takk for at jeg fikk forklare det. Jeg vet hvor mye vi trengte denne bestillingen. Jeg vet hvor viktig han var,” og gjorde seg klar til å dra.
Watson kom bort til ham ved døren, så ham inn i øynene og returnerte konvolutten med ordene: «Hvordan kan jeg la deg gå? Jeg har nettopp investert en million dollar i utdanningen din.
Jeg har en t-skjorte som sier: "Hvis du virkelig lærer av feil, så er jeg allerede en mester." Faktisk, når det kommer til feil, er jeg en doktor i vitenskap.
Første plass: App Inventor API
Virkelig forferdelige feil påvirker et stort antall brukere, blir offentlig kjent, tar lang tid å rette opp, og blir gjort av de som ikke kunne ha gjort dem. Min største feil passer alle disse kriteriene.
Jo verre jo bedre
Jeg leser om denne tilnærmingen på nittitallet som hovedfagsstudent, og jeg liker den så godt at jeg spør studentene mine om den. Hvis du ikke husker det godt, frisk opp hukommelsen, den er liten. Dette essayet kontrasterer ønsket om å "få det rett" og "verre er bedre"-tilnærmingen på mange måter, inkludert enkelhet.
Slik skal det være: Designet skal være enkelt i implementering og grensesnitt. Enkelheten til grensesnittet er viktigere enn enkelheten i implementeringen.
Jo verre, jo bedre: Designet skal være enkelt i implementering og grensesnitt. Enkel implementering er viktigere enn enkelhet i grensesnittet.
La oss glemme det et øyeblikk. Dessverre har jeg glemt det i mange år.
Appoppfinner
Mens jeg jobbet hos Google, var jeg en del av teamet , et dra-og-slipp utviklingsmiljø på nettet for ambisiøse Android-utviklere. Det var 2009, og vi hadde det travelt med å gi ut alfaversjonen i tide slik at vi om sommeren kunne holde mesterklasser for lærere som kunne bruke miljøet når de underviste om høsten. Jeg meldte meg frivillig til å implementere sprites, nostalgisk for hvordan jeg pleide å skrive spill på TI-99/4. For de som ikke vet, er en sprite et todimensjonalt grafisk objekt som kan bevege seg og samhandle med andre programvareelementer. Eksempler på sprites inkluderer romskip, asteroider, klinkekuler og racketer.
Vi implementerte objektorientert App Inventor i Java, så det er bare en haug med objekter der inne. Siden baller og sprites oppfører seg veldig likt, har jeg laget en abstrakt sprite-klasse med egenskaper (felt) X, Y, Speed (speed) og Heading (retning). De hadde de samme metodene for å oppdage kollisjoner, sprette fra kanten av skjermen osv.
Hovedforskjellen mellom en ball og en sprite er nøyaktig hva som er tegnet - en fylt sirkel eller et raster. Siden jeg implementerte sprites først, var det logisk å spesifisere x- og y-koordinatene til øvre venstre hjørne av der bildet var plassert.
Når sprites fungerte, bestemte jeg meg for at jeg kunne implementere ballobjekter med veldig lite kode. Det eneste problemet var at jeg tok den enkleste ruten (fra implementerens synspunkt), og indikerte x- og y-koordinatene til det øvre venstre hjørnet av konturen som rammer ballen inn.
Faktisk var det nødvendig å indikere x- og y-koordinatene til sentrum av sirkelen, slik det er undervist i en hvilken som helst lærebok i matematikk og enhver annen kilde som nevner sirkler.
I motsetning til mine tidligere feil, påvirket denne ikke bare kollegene mine, men også millioner av App Inventor-brukere. Mange av dem var barn eller helt nye innen programmering. De måtte utføre mange unødvendige trinn når de jobbet med hver applikasjon der ballen var til stede. Hvis jeg husker de andre feilene mine med latter, så får denne meg til å svette selv i dag.
Jeg har endelig rettet denne feilen bare nylig, ti år senere. "Løpt", ikke "fikset", fordi som Joshua Bloch sier, APIer er evige. Vi kunne ikke gjøre endringer som ville påvirke eksisterende programmer, vi la til OriginAtCenter-egenskapen med verdien false i gamle programmer og sann i alle fremtidige. Brukere kan stille et logisk spørsmål: hvem har i det hele tatt tenkt på å plassere startpunktet et annet sted enn sentrum. Til hvem? Til en programmerer som var for lat til å lage en vanlig API for ti år siden.
Lærdom
Når du jobber med APIer (som nesten alle programmerere må gjøre noen ganger), bør du følge de beste rådene som er skissert i Joshua Blochs video ""eller :
- Et API kan gi deg både stor fordel og stor skade.. Et godt API skaper tilbakevendende kunder. Den dårlige blir ditt evige mareritt.
- Offentlige APIer, som diamanter, varer evig. Gi alt: det vil aldri være en ny sjanse til å gjøre alt riktig.
- API-konturer bør være korte — én side med klasse- og metodesignaturer og beskrivelser, som ikke tar opp mer enn en linje. Dette lar deg enkelt omstrukturere API-et hvis det ikke blir perfekt første gang.
- Beskriv brukstilfellerfør du implementerer APIen eller til og med jobber med spesifikasjonen. På denne måten vil du unngå å implementere og spesifisere en fullstendig ikke-funksjonell API.
Hvis jeg hadde skrevet til og med en kort synopsis med et kunstig skript, ville jeg mest sannsynlig ha identifisert feilen og rettet den. Hvis ikke, ville en av mine kolleger definitivt gjort det. Enhver beslutning som har vidtrekkende konsekvenser må tenkes over i minst en dag (dette gjelder ikke bare programmering).
Tittelen på Richard Gabriels essay, «Worse Is Better», refererer til fordelen med å være først på markedet – selv med et ufullkomment produkt – mens noen andre bruker en evighet på å jage det perfekte. Når jeg reflekterer over spritekoden, innser jeg at jeg ikke engang trengte å skrive mer kode for å få den riktig. Uansett hva man kan si, tok jeg grovt feil.
Konklusjon
Programmerere gjør feil hver dag, enten det er å skrive buggy-kode eller ikke ønsker å prøve noe som vil forbedre deres ferdigheter og produktivitet. Selvfølgelig kan du være programmerer uten å gjøre så alvorlige feil som jeg gjorde. Men det er umulig å bli en god programmerer uten å gjenkjenne feilene dine og lære av dem.
Jeg møter stadig elever som føler at de gjør for mange feil og derfor ikke er ute av programmering. Jeg vet hvor vanlig bedragersyndrom er innen IT. Jeg håper du vil lære leksjonene jeg har listet opp - men husk den viktigste: hver av oss gjør feil - pinlig, morsom, forferdelig. Jeg vil bli overrasket og opprørt hvis jeg i fremtiden ikke har nok materiale til å fortsette artikkelen.
Kilde: www.habr.com