Soos hulle sê, as jy nie skaam is vir jou ou kode nie, dan groei jy nie as 'n programmeerder nie - en ek stem saam met hierdie mening. Ek het meer as 40 jaar gelede vir pret begin kodeer en 30 jaar gelede professioneel, so ek het baie foute gemaak. baie. As professor in rekenaarwetenskap leer ek my studente om uit foute te leer – hul eie, myne, ander. Ek dink dit is tyd om oor my foute te praat, om nie beskeidenheid te verloor nie. Ek hoop hulle sal nuttig wees vir iemand.

Derde plek - C samesteller van Microsoft

My hoërskoolonderwyser het gedink Romeo en Juliet is nie 'n tragedie nie, want die karakters het nie tragiese skuldgevoelens nie - hulle het net dom opgetree, soos tieners moet. Toe het ek nie met hom saamgestem nie, maar nou sien ek ’n rasionele grein na sy mening – veral in verband met programmering.

Teen die tyd dat ek my tweede jaar by MIT voltooi het, was ek jonk en onervare, beide in die lewe en in programmering. Gedurende die somer het ek 'n internskap by Microsoft gedoen, op die C-samestellerspan. Aanvanklik het ek 'n roetine soos profileringondersteuning gedoen, en toe is my toevertrou om aan die lekkerste (na my mening) deel van die samesteller te werk - backend optimalisering. Ek moes veral die x86-kode vir takstate verbeter.

Vasbeslote om die beste masjienkode vir elke moontlike geval te skryf, het ek my kop in die swembad gegooi. As die verspreidingsdigtheid van waardes hoog was, het ek dit ingevoer spring tafel. As hulle 'n gemeenskaplike deler gehad het, het ek dit gebruik om die tafel digter te maak (maar net as die verdeling gedoen kon word met bietjie verskuiwing). Toe alle waardes kragte van twee was, het ek nog 'n optimalisering uitgevoer. As die stel waardes nie aan my voorwaardes voldoen het nie, het ek dit in verskeie geoptimaliseerde gevalle opgebreek en die reeds geoptimaliseerde kode gebruik.

Dit was 'n nagmerrie. Jare later is daar vir my gesê dat die programmeerder wat my kode geërf het, my gehaat het.

Les geleer

Soos David Patterson en John Hennessy in Rekenaarargitektuur en Rekenaarstelselontwerp skryf, is een van die hoofbeginsels van argitektuur en ontwerp om dinge in die algemeen so vinnig as moontlik te laat loop.

Om algemene gevalle te bespoedig, sal prestasie meer effektief verbeter as om seldsame gevalle te optimaliseer. Ironies genoeg is algemene gevalle dikwels eenvoudiger as seldsame gevalle. Hierdie logiese advies impliseer dat jy weet watter geval om as algemeen te beskou - en dit kan slegs deur noukeurige toetsing en meting gedoen word.

Ek het in my verdediging probeer uitpluis hoe die takstate in die praktyk gelyk het (byvoorbeeld hoeveel takke bestaan ​​het en hoe die konstantes toegeken is), maar in 1988 was hierdie inligting nie beskikbaar nie. Ek moes egter nie spesiale gevalle bygevoeg het wanneer die huidige samesteller nie optimale kode vir my kunsmatige voorbeeld kon genereer nie.

Ek moes 'n ervare ontwikkelaar bel en saam met hom dink oor wat die algemene gevalle is en spesifiek daaroor handel. Ek sou minder kode skryf, maar dit is selfs goed. Soos Jeff Atwood, stigter van Stack Overflow, geskryf het, is 'n programmeerder se grootste vyand die programmeerder self:

Ek weet jy het die beste bedoelings, net soos ons almal. Ons skep programme en skryf graag kode. Dit is hoe ons is. Ons dink dat enige probleem opgelos kan word met plakband, 'n tuisgemaakte kruk en 'n knippie kode. So pynlik as wat dit vir kodeerders is om dit te erken, die beste kode is die kode wat nie bestaan ​​nie. Elke nuwe lyn het ontfouting en ondersteuning nodig, dit moet verstaan ​​word. Wanneer jy nuwe kode byvoeg, moet jy dit met onwilligheid en afsku doen, want alle ander opsies is uitgeput. Baie programmeerders skryf te veel kode, wat dit ons vyand maak.

As ek eenvoudiger kode geskryf het wat algemene gevalle dek, dan sou dit baie makliker gewees het om dit op te dateer indien nodig. Ek het 'n gemors agtergelaat waarmee niemand wou mors nie.

Naaswenner: sosiale media-advertensies

Toe ek by Google aan sosiale media-advertensies gewerk het (onthou jy Myspace?), het ek so iets in C++ geskryf:

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

Programmeerders sal waarskynlik dadelik die fout sien: die laaste argument moet j wees, nie i nie. Eenheidtoetsing het nie 'n fout geopenbaar nie, en ook nie my resensent nie. Daar was 'n bekendstelling, en een aand het my kode na die bediener gegaan en al die rekenaars in die datasentrum inmekaar gevou.

Niks vreesliks het gebeur nie. Niks het vir enigiemand gebreek nie, want voor die wêreldwye bekendstelling is die kode binne dieselfde datasentrum getoets. Behalwe dat SRE-ingenieurs kortstondig opgehou het om biljart te speel en 'n klein terugrol gemaak het. Die volgende oggend het ek 'n e-pos met 'n crash dump ontvang, die kode reggestel en eenheidstoetse bygevoeg wat die fout sou onthul het. Aangesien ek die protokol gevolg het - anders sou my kode eenvoudig nie werk nie - was daar geen ander probleme nie.

Les geleer

Baie mense glo dat so 'n groot fout sekerlik die persoon wat verantwoordelik is vir die ontslag sal kos, maar dit is nie so nie: eerstens maak alle programmeerders foute, en tweedens maak hulle selde dieselfde fout twee keer.

Trouens, ek het 'n programmeerdervriend wat 'n briljante ingenieur is wat vir 'n enkele fout afgedank is. Daarna is hy deur Google aangestel (en gou bevorder) - hy het eerlik gepraat oor die fout wat hy in die onderhoud gemaak het, en dit is nie as noodlottig beskou nie.

Dis wat vertel oor Thomas Watson, die legendariese hoof van IBM:

’n Regeringsbevel ter waarde van sowat ’n miljoen dollar is aangekondig. IBM Corporation - of liewer, Thomas Watson Sr. persoonlik - wou dit regtig kry. Ongelukkig kon die verkoopsverteenwoordiger dit nie doen nie, en IBM het die bod verloor. Die volgende dag het hierdie werknemer na mnr. Watson se kantoor gekom en 'n koevert op sy lessenaar geplaas. Mnr. Watson het nie eers daarna gekyk nie - hy het vir 'n werknemer gewag en geweet dit is 'n bedankingsbrief.

Watson het gevra wat verkeerd geloop het.

Die verkoopsverteenwoordiger het breedvoerig oor die verloop van die tender gepraat. Hy het die foute genoem wat vermy kon word. Uiteindelik het hy gesê: “Meneer Watson, dankie dat ek myself kon verduidelik. Ek weet hoeveel ons hierdie bestelling nodig gehad het. Ek weet hoe belangrik hy was,” en het gereed gemaak om te vertrek.

Watson het hom by die deur genader, in sy oë gekyk en die koevert teruggegee met die woorde: “Hoe kan ek jou laat gaan? Ek het sopas 'n miljoen dollar in jou opvoeding belê.

Ek het 'n T-hemp wat sê: "As jy regtig uit foute leer, dan is ek reeds 'n meester." Trouens, ek is 'n PhD wanneer dit by foute kom.

Eerste plek: App Inventor API

Werklik verskriklike foute raak 'n groot aantal gebruikers, word publieke kennis, word vir 'n lang tyd reggestel en word gemaak deur diegene wat dit nie kon maak nie. My grootste fout voldoen aan al hierdie kriteria.

Hoe slegter hoe beter

ek lees opstel deur Richard Gabriel oor hierdie benadering in die negentigerjare, as 'n nagraadse student, en ek hou so baie daarvan dat ek my studente daaroor uitvra. As jy dit nie goed onthou nie, verfris jou geheue, dit is klein. In hierdie opstel word die begeerte om dit "reg te doen" en die "erger is beter" benadering op baie maniere gekontrasteer, insluitend eenvoud.

Doen dit reg: Die ontwerp moet eenvoudig in implementering en koppelvlak wees. Die eenvoud van die koppelvlak is belangriker as die eenvoud van die implementering.

Hoe erger, hoe beter: die ontwerp moet eenvoudig wees in implementering en koppelvlak. Gemak van implementering is belangriker as die eenvoud van die koppelvlak.

Kom ons vergeet vir 'n oomblik daarvan. Ongelukkig het ek vir baie jare daarvan vergeet.

App uitvinder

Terwyl ek by Google gewerk het, was ek deel van die span App uitvinder, 'n aanlyn sleep-en-drop-ontwikkelingsomgewing vir beginner Android-ontwikkelaars. Dit was 2009 en ons het gehaas om die alfa-weergawe betyds vry te stel om oor die somer meesterklasse vir onderwysers te gee wat die omgewing kon gebruik om in die herfs te onderrig. Ek het vrywillig aangebied om die sprites te implementeer, nostalgies vir die manier waarop ek speletjies op die TI-99/4 geskryf het. Vir diegene wat nie weet nie, 'n sprite is 'n XNUMXD grafiese voorwerp wat kan rondbeweeg en interaksie met ander sagteware-elemente kan hê. Voorbeelde van sprites is ruimteskepe, asteroïdes, ballonne en rakette.

Ons het 'n objekgeoriënteerde App Inventor in Java geïmplementeer, so dit is net 'n klomp voorwerpe. Aangesien balle en sprites baie soortgelyk optree, het ek 'n abstrakte sprite-klas geskep met eienskappe (velde) X, Y, Speed ​​​​(spoed) en Heading (rigting). Hulle het dieselfde metodes gehad om botsings op te spoor, van die skermgrens af te weerkaats, ensovoorts.

Die belangrikste verskil tussen 'n bal en 'n sprite is wat presies geteken word - 'n gevulde sirkel of 'n raster. Sedert ek die eerste keer sprites geïmplementeer het, was dit sinvol om die x- en y-koördinate van die boonste linkerhoek van die plek waar die beeld geleë was, te spesifiseer.

Sodra die sprites aan die gang was, het ek gedink ek kan ballonvoorwerpe met baie min kode implementeer. Die enigste probleem was dat ek die eenvoudigste manier gegaan het (uit die oogpunt van die implementeerder), deur die x- en y-koördinate van die boonste linkerhoek van die buitelyn wat die bal omraam, te spesifiseer.

Trouens, dit was nodig om die x- en y-koördinate van die middelpunt van die sirkel te spesifiseer, soos elke wiskundehandboek en enige ander bron wat sirkels noem, leer.

Anders as my vorige foute, het hierdie een nie net my kollegas geraak nie, maar ook miljoene App Inventor-gebruikers. Baie van hulle was kinders of heeltemal nuut in programmering. Hulle moes baie oortollige werk doen op elke aansoek wat 'n bal gehad het. As ek my ander foute met die lag onthou, dan laat hierdie een my vandag sweet.

Ek het hierdie fout uiteindelik eers onlangs, tien jaar later, gelap. "Patched", nie "fixed", want soos Joshua Bloch sê, API's is ewig. Ons was nie in staat om veranderinge aan te bring wat bestaande programme sou beïnvloed nie, ons het die OriginAtCenter-eienskap bygevoeg met 'n waarde van vals in ouer programme en waar in alle toekomstige programme. Gebruikers kan 'n wettige vraag vra, wat selfs gedink het om die verwysingspunt iewers anders as die sentrum te plaas. Aan wie? Een programmeerder wat tien jaar gelede te lui was om 'n normale API te skep.

Lesse geleer

Wanneer jy aan 'n API werk (iets wat byna elke programmeerder soms moet doen), moet jy die beste raad volg wat in die Joshua Bloch-video uiteengesit word.Hoe om 'n goeie API te skep en hoekom dit so belangrik is"of in hierdie kort lys:

• 'n API kan jou beide groot goed en groot skade doen. 'n Goeie API skep lojale kliënte. Die slegte word jou ewige nagmerrie.
• Openbare API's, soos diamante, is vir ewig. Gee alles: daar sal geen ander kans wees om alles reg te doen nie.
• API-omskrywings moet bondig wees - een bladsy met handtekeninge van klasse en metodes en beskrywings, wat nie meer as 'n reël beslaan nie. Dit sal jou toelaat om die API maklik te herstruktureer as dit nie die eerste keer perfek uitkom nie.
• Skryf gebruiksgevalle neervoor die implementering van die API en selfs aan die spesifikasie daarvan werk. Op hierdie manier vermy jy die implementering en spesifikasie van 'n heeltemal nie-funksionele API.

As ek ten minste 'n klein opsomming met 'n kunsmatige skrif geskryf het, sou ek heel waarskynlik die fout geïdentifiseer het en dit reggestel het. Indien nie, dan sal een van my kollegas dit beslis doen. Enige besluit wat verreikende gevolge het, moet vir ten minste 'n dag oorweeg word (dit geld nie net vir programmering nie).

Die titel van Richard Gabriel se opstel, "The Worse, the Better," verwys na die voordeel wat die een kry wat die eerste keer die mark betree het - selfs met 'n onvolmaakte produk - terwyl iemand anders die ideaal vir eeue najaag. As ek aan die sprite-kode dink, besef ek dat ek nie eers meer kode hoef te skryf om dit reg te kry nie. Wat 'n mens ook al mag sê, ek het my grootliks misgis.

Gevolgtrekking

Programmeerders maak elke dag foute, of dit nou is om karretjie-kode te skryf of nie iets wil probeer wat hul vaardigheid en produktiwiteit sal verbeter nie. Natuurlik kan jy 'n programmeerder wees sonder om sulke ernstige foute soos ek te maak. Maar dit is onmoontlik om 'n goeie programmeerder te word sonder om jou foute te besef en sonder om daaruit te leer.

Ek loop heeltyd studente raak wat voel hulle maak te veel foute en dis hoekom hulle nie gemaak is vir programmering nie. Ek weet hoe algemeen die bedrieërsindroom in IT voorkom. Ek hoop jy sal die lesse leer wat ek gelys het – maar onthou die belangrikste een: elkeen van ons maak foute – skandelik, snaaks, verskriklik. Ek sal verbaas en ontsteld wees as ek in die toekoms nie genoeg materiaal het om die artikel voort te sit nie.

Bron: will.com