Zoals ze zeggen: als je je niet schaamt voor je oude code, dan groei je niet als programmeur - en ik ben het met deze mening eens. Ik ben meer dan 40 jaar geleden begonnen met programmeren voor de lol, en professioneel 30 jaar geleden, dus ik maak veel fouten. heel veel. Als hoogleraar informatica leer ik mijn studenten leren van fouten – die van hen, die van mij en die van anderen. Ik denk dat het tijd is om over mijn fouten te praten, om mijn bescheidenheid niet te verliezen. Ik hoop dat ze voor iemand nuttig zullen zijn.
Derde plaats - Microsoft C-compiler
Mijn schoolleraar was van mening dat Romeo en Julia niet als een tragedie konden worden beschouwd omdat de personages geen tragische schuldgevoelens hadden - ze gedroegen zich eenvoudigweg dom, zoals tieners zouden moeten doen. Ik was het toen niet met hem eens, maar nu zie ik een greintje rationaliteit in zijn mening, vooral in verband met programmeren.
Tegen de tijd dat ik mijn tweede jaar aan het MIT afrondde, was ik jong en onervaren, zowel in het leven als in het programmeren. In de zomer liep ik stage bij Microsoft, in het compilerteam van C. In eerste instantie deed ik routinematige dingen zoals profileringsondersteuning, en daarna werd mij toevertrouwd om aan het leukste deel van de compiler te werken (zoals ik dacht): backend-optimalisatie. In het bijzonder moest ik de x86-code voor branch-instructies verbeteren.
Vastbesloten om voor elk mogelijk geval de optimale machinecode te schrijven, gooide ik mezelf hals over kop in het zwembad. Als de distributiedichtheid van waarden hoog was, voerde ik ze in . Als ze een gemeenschappelijke deler hadden, gebruikte ik die om de tabel strakker te maken (maar alleen als de deling kon worden gedaan met behulp van ). Toen alle waarden machten van twee waren, heb ik nog een optimalisatie uitgevoerd. Als een reeks waarden niet aan mijn voorwaarden voldeed, splitste ik deze op in verschillende optimaliseerbare gevallen en gebruikte ik de reeds geoptimaliseerde code.
Het was een nachtmerrie. Vele jaren later kreeg ik te horen dat de programmeur die mijn code had geërfd, mij haatte.
Les geleerd
Zoals David Patterson en John Hennessy schrijven in Computer Architecture and Computer Systems Design, is een van de belangrijkste principes van architectuur en ontwerp om dingen in het algemeen zo snel mogelijk te laten werken.
Het versnellen van veelvoorkomende gevallen zal de prestaties effectiever verbeteren dan het optimaliseren van zeldzame gevallen. Ironisch genoeg zijn veel voorkomende gevallen vaak eenvoudiger dan zeldzame gevallen. Dit logische advies gaat ervan uit dat u weet welk geval als veelvoorkomend wordt beschouwd - en dit is alleen mogelijk door een proces van zorgvuldig testen en meten.
Ter verdediging probeerde ik erachter te komen hoe vertakkingsverklaringen er in de praktijk uitzagen (zoals hoeveel vertakkingen er waren en hoe constanten werden verdeeld), maar in 1988 was deze informatie niet beschikbaar. Ik had echter geen speciale gevallen moeten toevoegen als de huidige compiler geen optimale code kon genereren voor het kunstmatige voorbeeld dat ik bedacht had.
Ik moest een ervaren ontwikkelaar bellen en samen met hem nadenken over de meest voorkomende gevallen en daar specifiek mee omgaan. Ik zou minder code schrijven, maar dat is maar goed ook. Zoals Jeff Atwood, de oprichter van Stack Overflow, schreef: de grootste vijand van een programmeur is de programmeur zelf:
Ik weet dat je de beste bedoelingen hebt, net als wij allemaal. We maken programma's en schrijven graag code. Zo zijn wij gemaakt. Wij denken dat elk probleem kan worden opgelost met ducttape, een zelfgemaakte kruk en een snufje code. Hoezeer het programmeurs ook pijn doet om het toe te geven, de beste code is de code die niet bestaat. Elke nieuwe regel heeft debuggen en ondersteuning nodig, het moet begrepen worden. Als je nieuwe code toevoegt, moet je dat met tegenzin en walging doen, omdat alle andere opties zijn uitgeput. Veel programmeurs schrijven te veel code, waardoor deze onze vijand wordt.
Als ik eenvoudiger code had geschreven die veelvoorkomende gevallen dekte, zou het veel gemakkelijker zijn geweest om indien nodig bij te werken. Ik liet een puinhoop achter waar niemand mee om wilde gaan.
Tweede plaats: adverteren op sociale netwerken
Toen ik bij Google werkte aan adverteren op sociale media (weet je nog Myspace?), schreef ik zoiets als dit in 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)) {
}
}Programmeurs kunnen de fout onmiddellijk zien: het laatste argument moet j zijn, en niet i. Het testen van eenheden bracht de fout niet aan het licht, en mijn recensent ook niet. De lancering vond plaats en op een avond ging mijn code naar de server en crashte alle computers in het datacenter.
Er gebeurde niets ergs. Voor niemand brak er iets, want vóór de wereldwijde lancering werd de code binnen één datacenter getest. Tenzij de SRE-ingenieurs een tijdje stopten met biljarten en een beetje terugdraaiden. De volgende ochtend ontving ik een e-mail met een crashdump, corrigeerde de code en voegde unittests toe die de fout zouden opsporen. Omdat ik het protocol volgde - anders zou mijn code simpelweg niet werken - waren er geen andere problemen.
Les geleerd
Velen zijn er zeker van dat zo'n grote fout de dader zeker zal ontslaan, maar dat is niet het geval: ten eerste maken alle programmeurs fouten, en ten tweede maken ze zelden dezelfde fout twee keer.
Ik heb zelfs een bevriend programmeur die een briljante ingenieur was en werd ontslagen omdat hij één enkele fout had gemaakt. Daarna werd hij aangenomen bij Google (en maakte al snel promotie) - hij sprak eerlijk over de fout die hij maakte in een interview, en deze werd niet als fataal beschouwd.
Stem hto over Thomas Watson, het legendarische hoofd van IBM:
Er werd een overheidsbevel ter waarde van ongeveer een miljoen dollar aangekondigd. IBM Corporation – of beter gezegd Thomas Watson Sr. persoonlijk – wilde het heel graag krijgen. Helaas kon de vertegenwoordiger dit niet doen en verloor IBM het bod. De volgende dag kwam deze medewerker het kantoor van meneer Watson binnen en legde een envelop op zijn bureau. Meneer Watson nam niet eens de moeite om ernaar te kijken; hij wachtte op een medewerker en wist dat het een ontslagbrief was.
Watson vroeg wat er mis ging.
De vertegenwoordiger vertelde uitgebreid over het verloop van de aanbesteding. Hij noemde gemaakte fouten die voorkomen hadden kunnen worden. Ten slotte zei hij: 'Meneer Watson, bedankt dat ik het mag uitleggen. Ik weet hoe hard we deze bestelling nodig hadden. Ik weet hoe belangrijk hij was, 'en maakte zich klaar om te vertrekken.
Watson benaderde hem bij de deur, keek hem in de ogen en gaf de envelop terug met de woorden: 'Hoe kan ik je laten gaan? Ik heb net een miljoen dollar in jouw opleiding geïnvesteerd.
Ik heb een T-shirt met de tekst: “Als je echt leert van fouten, dan ben ik al een meester.” Als het om fouten gaat, ben ik eigenlijk doctor in de wetenschappen.
Eerste plaats: App Inventor API
Echt vreselijke fouten treffen een groot aantal gebruikers, worden algemeen bekend, het duurt lang voordat ze zijn gecorrigeerd en worden gemaakt door degenen die ze niet hadden kunnen maken. Mijn grootste fout voldoet aan al deze criteria.
Hoe slechter hoe beter
ik lees over deze aanpak in de jaren negentig als afgestudeerde student, en ik vind het zo leuk dat ik het aan mijn studenten vraag. Als u het zich niet goed herinnert, fris dan uw geheugen op, het is klein. Dit essay contrasteert de wens om ‘het goed te doen’ en de ‘slechter is beter’-benadering op veel manieren, inclusief eenvoud.
Hoe het zou moeten zijn: het ontwerp moet eenvoudig zijn qua implementatie en interface. Eenvoud van de interface is belangrijker dan eenvoud van implementatie.
Hoe slechter, hoe beter: het ontwerp moet eenvoudig zijn qua implementatie en interface. Eenvoud van implementatie is belangrijker dan eenvoud van de interface.
Laten we dat even vergeten. Helaas ben ik het al jaren vergeten.
App-uitvinder
Toen ik bij Google werkte, maakte ik deel uit van het team , een online ontwikkelomgeving met slepen en neerzetten voor aspirant-Android-ontwikkelaars. Het was 2009 en we hadden haast om de alfaversie op tijd uit te brengen, zodat we in de zomer masterclasses konden houden voor leraren die de omgeving konden gebruiken bij het lesgeven in het najaar. Ik bood aan om sprites te implementeren, nostalgisch naar hoe ik vroeger games schreef op de TI-99/4. Voor degenen die het niet weten: een sprite is een tweedimensionaal grafisch object dat kan bewegen en kan communiceren met andere software-elementen. Voorbeelden van sprites zijn ruimteschepen, asteroïden, knikkers en rackets.
We hebben objectgeoriënteerde App Inventor in Java geïmplementeerd, dus er zitten maar een paar objecten in. Omdat ballen en sprites zich zeer vergelijkbaar gedragen, heb ik een abstracte sprite-klasse gemaakt met eigenschappen (velden) X, Y, Snelheid (snelheid) en Heading (richting). Ze hadden dezelfde methoden voor het detecteren van botsingen, het stuiteren van de rand van het scherm, enz.
Het belangrijkste verschil tussen een bal en een sprite is wat er precies wordt getekend: een gevulde cirkel of een raster. Omdat ik eerst sprites implementeerde, was het logisch om de x- en y-coördinaten te specificeren van de linkerbovenhoek van waar de afbeelding zich bevond.
Toen de sprites eenmaal werkten, besloot ik dat ik balobjecten met heel weinig code kon implementeren. Het enige probleem was dat ik de eenvoudigste route nam (vanuit het standpunt van de uitvoerder), waarbij ik de x- en y-coördinaten aangaf van de linkerbovenhoek van de contour die de bal omlijst.
In feite was het nodig om de x- en y-coördinaten van het middelpunt van de cirkel aan te geven, zoals wordt geleerd in elk wiskundehandboek en elke andere bron waarin cirkels worden genoemd.
In tegenstelling tot mijn fouten uit het verleden had deze niet alleen gevolgen voor mijn collega's, maar ook voor miljoenen App Inventor-gebruikers. Velen van hen waren kinderen of helemaal nieuw in programmeren. Ze moesten veel onnodige stappen uitvoeren bij het werken aan elke applicatie waarin de bal aanwezig was. Als ik me mijn andere fouten met lachen herinner, dan laat deze me zelfs vandaag nog zweten.
Ik heb deze bug pas onlangs, tien jaar later, gepatcht. “Gepatcht”, niet “gefixt”, want zoals Joshua Bloch zegt: API’s zijn eeuwig. Omdat we geen wijzigingen konden aanbrengen die van invloed zouden zijn op bestaande programma's, hebben we de eigenschap OriginAtCenter toegevoegd met de waarde false in oude programma's en true in alle toekomstige programma's. Gebruikers kunnen een logische vraag stellen: wie heeft er überhaupt aan gedacht om het startpunt ergens anders dan in het midden te plaatsen? Aan wie? Aan een programmeur die tien jaar geleden te lui was om een normale API te maken.
Les geleerd
Wanneer je aan API's werkt (wat bijna elke programmeur wel eens moet doen), moet je het beste advies volgen dat wordt beschreven in de video van Joshua Bloch ""of :
- Een API kan u zowel grote voordelen als grote schade opleveren.. Een goede API zorgt voor terugkerende klanten. De slechte wordt je eeuwige nachtmerrie.
- Publieke API’s gaan, net als diamanten, eeuwig mee. Geef alles: er zal nooit meer een kans zijn om alles goed te doen.
- API-overzichten moeten kort zijn — één pagina met handtekeningen en beschrijvingen van klassen en methoden, die niet meer dan één regel beslaat. Hierdoor kunt u de API eenvoudig herstructureren als deze de eerste keer niet perfect blijkt te zijn.
- Beschrijf gebruiksscenario'svoordat u de API implementeert of zelfs maar aan de specificatie ervan werkt. Op deze manier vermijdt u het implementeren en specificeren van een volledig niet-functionele API.
Als ik zelfs maar een korte samenvatting met een kunstmatig script had geschreven, zou ik hoogstwaarschijnlijk de fout hebben geïdentificeerd en gecorrigeerd. Zo niet, dan zou een van mijn collega’s het zeker doen. Over elke beslissing die verstrekkende gevolgen heeft, moet minimaal een dag worden nagedacht (dit geldt niet alleen voor programmeren).
De titel van Richard Gabriels essay, 'Worse Is Better', verwijst naar het voordeel dat je krijgt als je als eerste op de markt komt – zelfs met een imperfect product – terwijl iemand anders een eeuwigheid doorbrengt met het najagen van het perfecte product. Als ik nadenk over de sprite-code, realiseer ik me dat ik niet eens meer code hoefde te schrijven om het goed te krijgen. Wat je ook zegt, ik heb me ernstig vergist.
Conclusie
Programmeurs maken elke dag fouten, of het nu gaat om het schrijven van code met fouten of het niet willen proberen van iets dat hun vaardigheden en productiviteit zal verbeteren. Natuurlijk kun je programmeur zijn zonder zulke ernstige fouten te maken als ik. Maar het is onmogelijk om een goede programmeur te worden zonder je fouten te erkennen en ervan te leren.
Ik kom voortdurend studenten tegen die het gevoel hebben dat ze te veel fouten maken en daarom niet geschikt zijn voor programmeren. Ik weet hoe vaak het impostersyndroom voorkomt in de IT. Ik hoop dat je de lessen zult leren die ik heb opgesomd - maar onthoud de belangrijkste: ieder van ons maakt fouten - gênant, grappig, verschrikkelijk. Ik zal verrast en boos zijn als ik in de toekomst niet genoeg materiaal heb om door te gaan met het artikel.
Bron: www.habr.com