Som de säger, om du inte skäms över din gamla kod, så växer du inte som programmerare - och jag håller med om denna åsikt. Jag började programmera för skojs skull för över 40 år sedan, och professionellt för 30 år sedan, så jag har många misstag. mycket. Som professor i datavetenskap lär jag mina elever att lära sig av misstag – deras, mina och andras. Jag tycker att det är dags att prata om mina misstag för att inte tappa min blygsamhet. Jag hoppas att de kommer att vara användbara för någon.

Tredje plats - Microsoft C-kompilator

Min skollärare trodde att Romeo och Julia inte kunde betraktas som en tragedi eftersom karaktärerna inte hade någon tragisk skuld – de betedde sig helt enkelt dumt, som tonåringar borde. Jag höll inte med honom då, men nu ser jag en nyans av rationalitet i hans åsikt, särskilt i samband med programmering.

När jag avslutade mitt andra år på MIT var jag ung och oerfaren, både i livet och i programmering. På sommaren arbetade jag hos Microsoft, i C-kompilatorteamet. Först gjorde jag rutinmässiga saker som profileringsstöd, och sedan fick jag förtroendet att arbeta med den roligaste delen av kompilatorn (som jag trodde) - backend-optimering. I synnerhet var jag tvungen att förbättra x86-koden för filialsatser.

Fast besluten att skriva den optimala maskinkoden för alla möjliga fall, kastade jag mig i poolen handlöst. Om distributionstätheten av värden var hög, skrev jag in dem övergångstabell. Om de hade en gemensam divisor använde jag den för att göra bordet tätare (men bara om uppdelningen kunde göras med bitskifte). När alla värden var två potenser gjorde jag ytterligare en optimering. Om en uppsättning värden inte uppfyllde mina villkor, delade jag upp den i flera optimerbara fall och använde den redan optimerade koden.

Det var en mardröm. Många år senare fick jag höra att programmeraren som ärvde min kod hatade mig.

Lärdom

Som David Patterson och John Hennessy skriver i Computer Architecture and Computer Systems Design är en av huvudprinciperna för arkitektur och design att generellt få saker att fungera så snabbt som möjligt.

Att påskynda vanliga fall kommer att förbättra prestandan mer effektivt än att optimera sällsynta fall. Ironiskt nog är vanliga fall ofta enklare än sällsynta. Detta logiska råd förutsätter att du vet vilket fall som anses vara vanligt – och detta är endast möjligt genom en process av noggrann testning och mätning.

Till mitt försvar försökte jag lista ut hur grenpåståenden såg ut i praktiken (som hur många grenar det fanns och hur konstanter fördelades), men 1988 fanns inte denna information tillgänglig. Jag borde dock inte ha lagt till specialfall när den nuvarande kompilatorn inte kunde generera optimal kod för det artificiella exemplet jag kom på.

Jag behövde ringa en erfaren utvecklare och tillsammans med honom fundera över vilka vanliga fall var och behandla dem specifikt. Jag skulle skriva mindre kod, men det är bra. Som Stack Overflow-grundaren Jeff Atwood skrev, är programmerarens värsta fiende programmeraren själv:

Jag vet att du har de bästa avsikterna, precis som vi alla. Vi skapar program och älskar att skriva kod. Det är så vi är gjorda. Vi tror att alla problem kan lösas med gaffatejp, en hemmagjord krycka och en nypa kod. Lika mycket som det plågar kodare att erkänna det, den bästa koden är koden som inte finns. Varje ny rad behöver felsökning och support, det måste förstås. När du lägger till ny kod bör du göra det med motvilja och avsky eftersom alla andra alternativ är uttömda. Många programmerare skriver för mycket kod, vilket gör det till vår fiende.

Om jag hade skrivit enklare kod som täckte vanliga fall hade det varit mycket lättare att uppdatera om det skulle behövas. Jag lämnade efter mig en röra som ingen ville ta itu med.

Andra plats: reklam på sociala nätverk

När jag arbetade på Google med reklam i sociala medier (minns du Myspace?), skrev jag något så här 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)) {
  }
}

Programmerare kan omedelbart se felet: det sista argumentet ska vara j, inte i. Enhetstestning avslöjade inte felet, och det gjorde inte min granskare heller. Lanseringen genomfördes och en natt gick min kod till servern och kraschade alla datorer i datacentret.

Inget dåligt hände. Inget gick sönder för någon, för innan den globala lanseringen testades koden i ett datacenter. Om inte SRE-ingenjörer slutade spela biljard ett tag och gjorde en liten rollback. Nästa morgon fick jag ett mejl med en krockdump, korrigerade koden och lade till enhetstester som skulle fånga felet. Eftersom jag följde protokollet - annars skulle min kod helt enkelt misslyckas med att köra - det fanns inga andra problem.

Lärdom

Många är säkra på att ett så stort misstag definitivt kommer att kosta den skyldige avskedandet, men så är det inte: för det första gör alla programmerare misstag, och för det andra gör de sällan samma misstag två gånger.

Faktum är att jag har en programmerare som var en briljant ingenjör och fick sparken för att ha gjort ett enda misstag. Efter det anställdes han på Google (och befordrades snart) - han talade ärligt om misstaget han gjorde i en intervju, och det ansågs inte vara ödesdigert.

Här är vad säga om Thomas Watson, den legendariske chefen för IBM:

En statlig order värd cirka en miljon dollar tillkännagavs. IBM Corporation - eller snarare, Thomas Watson Sr. personligen - ville verkligen få det. Tyvärr kunde säljaren inte göra detta och IBM förlorade budet. Dagen efter kom den här anställde in på Mr. Watsons kontor och lade ett kuvert på hans skrivbord. Herr Watson brydde sig inte ens om att titta på det - han väntade på en anställd och visste att det var ett avskedsbrev.

Watson frågade vad som gick fel.

Säljaren berättade i detalj om hur upphandlingen fortskrider. Han namngav misstag som hade kunnat undvikas. Till slut sa han: "Mr Watson, tack för att jag fick förklara. Jag vet hur mycket vi behövde den här beställningen. Jag vet hur viktig han var”, och gjorde sig redo att lämna.

Watson gick fram till honom vid dörren, såg honom i ögonen och lämnade tillbaka kuvertet med orden: ”Hur kan jag släppa dig? Jag har precis investerat en miljon dollar i din utbildning.

Jag har en T-shirt där det står: "Om du verkligen lär dig av misstag, då är jag redan en mästare." Faktum är att när det kommer till fel är jag doktor i naturvetenskap.

Första plats: App Inventor API

Verkligen fruktansvärda fel påverkar ett stort antal användare, blir allmänt kända, tar lång tid att rätta till och görs av de som inte kunde ha gjort dem. Mitt största misstag passar alla dessa kriterier.

Ju sämre desto bättre

jag läser essä av Richard Gabriel om det här förhållningssättet på nittiotalet som doktorand, och jag gillar det så mycket att jag frågar det till mina studenter. Om du inte kommer ihåg det så bra, fräscha upp ditt minne, det är litet. Den här uppsatsen kontrasterar viljan att "få det rätt" och "värre är bättre"-metoden på många sätt, inklusive enkelhet.

Hur det ska vara: designen ska vara enkel i implementering och gränssnitt. Enkelheten i gränssnittet är viktigare än enkel implementering.

Ju sämre, desto bättre: designen ska vara enkel i implementering och gränssnitt. Enkel implementering är viktigare än enkelhet i gränssnittet.

Låt oss glömma det för en minut. Tyvärr glömde jag bort det i många år.

App uppfinnare

När jag arbetade på Google var jag en del av teamet App uppfinnare, en dra-och-släpp utvecklingsmiljö online för blivande Android-utvecklare. Det var 2009 och vi hade bråttom att släppa alfaversionen i tid så att vi på sommaren kunde hålla mästarklasser för lärare som kunde använda miljön när de undervisade på hösten. Jag anmälde mig frivilligt att implementera sprites, nostalgisk över hur jag brukade skriva spel på TI-99/4. För de som inte vet är en sprite ett tvådimensionellt grafiskt objekt som kan röra sig och interagera med andra programvaruelement. Exempel på sprites inkluderar rymdskepp, asteroider, kulor och racketar.

Vi implementerade objektorienterad App Inventor i Java, så det finns bara ett gäng objekt där. Eftersom bollar och sprites beter sig väldigt lika skapade jag en abstrakt spriteklass med egenskaper (fält) X, Y, Speed ​​​​(speed) och Heading (riktning). De hade samma metoder för att upptäcka kollisioner, studsa från kanten av skärmen, etc.

Den största skillnaden mellan en boll och en sprite är exakt vad som ritas - en fylld cirkel eller ett raster. Eftersom jag implementerade sprites först, var det logiskt att ange x- och y-koordinaterna för det övre vänstra hörnet där bilden var placerad.

När sprites väl fungerade bestämde jag mig för att jag kunde implementera bollobjekt med väldigt lite kod. Det enda problemet var att jag tog den enklaste vägen (ur implementerarens synvinkel), och angav x- och y-koordinaterna för det övre vänstra hörnet av konturen som ramar in bollen.

I själva verket var det nödvändigt att ange x- och y-koordinaterna för cirkelns mittpunkt, som lärs ut i någon matematiklärobok och någon annan källa som nämner cirklar.

Till skillnad från mina tidigare misstag påverkade det här inte bara mina kollegor utan också miljontals App Inventor-användare. Många av dem var barn eller helt nya inom programmering. De var tvungna att utföra många onödiga steg när de arbetade med varje applikation där bollen fanns. Om jag minns mina andra misstag med skratt, då får den här mig att svettas även idag.

Jag fixade äntligen denna bugg helt nyligen, tio år senare. "Lättad", inte "fixad", för som Joshua Bloch säger, API:er är eviga. Det gick inte att göra ändringar som skulle påverka befintliga program, vi lade till egenskapen OriginAtCenter med värdet false i gamla program och sant i alla framtida. Användare kan ställa en logisk fråga: vem tänkte ens placera startpunkten någon annanstans än centrum. Till vem? Till en programmerare som var för lat för att skapa ett normalt API för tio år sedan.

Lärdomar

När du arbetar med API:er (vilket nästan alla programmerare måste göra ibland), bör du följa de bästa råden som beskrivs i Joshua Blochs video "Hur man skapar ett bra API och varför det är så viktigt"eller i denna korta lista:

• Ett API kan ge dig både stor nytta och stor skada.. Ett bra API skapar återkommande kunder. Den dåliga blir din eviga mardröm.
• Offentliga API:er, som diamanter, varar för evigt. Ge allt: det kommer aldrig att finnas en ny chans att göra allt rätt.
• API-konturer bör vara korta — en sida med klass- och metodsignaturer och beskrivningar, som inte tar upp mer än en rad. Detta gör att du enkelt kan strukturera om API:et om det inte blir perfekt första gången.
• Beskriv användningsfallinnan du implementerar API:et eller ens arbetar med dess specifikation. På så sätt slipper du implementera och specificera ett helt icke-funktionellt API.

Om jag hade skrivit ens en kort synopsis med ett konstgjort manus, skulle jag troligen ha identifierat felet och rättat till det. Om inte, så skulle en av mina kollegor definitivt göra det. Alla beslut som får långtgående konsekvenser måste tänkas över i minst ett dygn (detta gäller inte bara programmering).

Titeln på Richard Gabriels essä, "Worse Is Better", syftar på fördelen med att vara först ut på marknaden – även med en ofullkomlig produkt – medan någon annan spenderar en evighet på att jaga den perfekta. När jag reflekterar över spritekoden inser jag att jag inte ens behövde skriva mer kod för att få det rätt. Vad man än kan säga så hade jag grovt fel.

Slutsats

Programmerare gör misstag varje dag, oavsett om det är att skriva buggykod eller inte vill prova något som kommer att förbättra deras skicklighet och produktivitet. Självklart kan man vara programmerare utan att göra så allvarliga misstag som jag gjorde. Men det är omöjligt att bli en bra programmerare utan att känna igen dina misstag och lära av dem.

Jag stöter ständigt på elever som känner att de gör för många misstag och därför inte är utsmyckade för programmering. Jag vet hur vanligt bedragaresyndrom är inom IT. Jag hoppas att du kommer att lära dig de lärdomar jag har listat - men kom ihåg den viktigaste: var och en av oss gör misstag - pinsamma, roliga, hemska. Jag kommer att bli förvånad och upprörd om jag i framtiden inte har tillräckligt med material för att fortsätta artikeln.

Källa: will.com