Zoals het gezegde luidt: als je je niet schaamt voor je oude code, groei je niet als programmeur – en daar ben ik het mee eens. Ik ben meer dan 40 jaar geleden voor de lol begonnen met programmeren, en 30 jaar geleden professioneel, dus ik heb mijn portie fouten gemaakt. zoveelAls docent informatica leer ik mijn studenten om van fouten te leren – die van henzelf, de mijne en die van anderen. Ik vind dat het tijd is om mijn fouten te delen en mijn bescheidenheid te bewaren. Ik hoop dat ze nuttig zullen zijn voor iemand.
Derde plaats - Microsoft's C-compiler
Mijn leraar vond dat Romeo en Julia geen tragedie kon zijn, omdat de personages niet tragisch schuldig waren – ze waren gewoon dom, zoals tieners doen. Ik was het toen niet met hem eens, maar nu zie ik een kern van waarheid in zijn mening – vooral met betrekking tot programmeren.
Tegen de tijd dat ik mijn tweede jaar aan MIT afrondde, was ik jong en onervaren, zowel in het leven als in programmeren. Die zomer liep ik stage bij Microsoft, in het C-compilerteam. Aanvankelijk deed ik routinewerk zoals profileringsondersteuning, maar toen kreeg ik de taak om te werken aan wat ik het leukste onderdeel van de compiler vond: backend-optimalisatie. Ik moest met name de x86-code voor vertakkende statements verbeteren.
Vastbesloten om voor elk mogelijk geval optimale machinecode te schrijven, dook ik erin. Als de dichtheid van de verdeling van waarden hoog was, voerde ik ze in Als ze een gemeenschappelijke deler hadden, gebruikte ik die om de tabel dichter te maken (maar alleen als de deling kon worden gedaan met behulp van ). Toen alle waarden machten van twee waren, voerde ik een nieuwe optimalisatie uit. Als de set waarden niet aan mijn voorwaarden voldeed, splitste ik deze op in verschillende geoptimaliseerde gevallen en gebruikte ik de reeds geoptimaliseerde code.
Het was een nachtmerrie. Jaren later hoorde ik dat de programmeur die mijn code had geërfd, me haatte.
Les geleerd
Zoals David Patterson en John Hennessy in Computer Architecture and the Design of Computer Systems schrijven, is een van de belangrijkste principes van architectuur en ontwerp om dingen zo snel mogelijk te laten werken.
Het versnellen van veelvoorkomende gevallen verbetert de prestaties effectiever dan het optimaliseren van zeldzame gevallen. Ironisch genoeg zijn veelvoorkomende gevallen vaak eenvoudiger dan zeldzame gevallen. Dit logische advies gaat ervan uit dat u weet wat als een veelvoorkomend geval geldt, wat alleen kan door zorgvuldig testen en meten.
Ter verdediging moet ik zeggen dat ik heb geprobeerd uit te zoeken hoe vertakkingsinstructies er in de praktijk uitzagen (bijvoorbeeld hoeveel vertakkingen er waren en hoe constanten waren verdeeld), maar die informatie was in 1988 nog niet beschikbaar. Toch had ik geen speciale gevallen moeten toevoegen wanneer de daadwerkelijke compiler geen optimale code voor mijn kunstmatige voorbeeld kon genereren.
Ik had een ervaren ontwikkelaar moeten inschakelen en samen de veelvoorkomende gevallen moeten doordenken en specifiek moeten aanpakken. Ik had minder code moeten schrijven, maar dat is goed. Zoals Jeff Atwood, oprichter van Stack Overflow, schreef: de grootste vijand van een programmeur is de programmeur zelf:
Ik weet dat je de beste bedoelingen hebt, en wij allemaal ook. We schrijven software en we schrijven graag code. Zo zijn we nu eenmaal. We denken dat elk probleem opgelost kan worden met ducttape, een hack en een snufje code. Hoe moeilijk het programmeurs het ook vinden om toe te geven, de beste code is de code die niet bestaat. Elke nieuwe regel moet worden gedebugd, onderhouden en begrepen. Wanneer je nieuwe code toevoegt, doe dat dan met tegenzin en afkeer, omdat alle andere opties zijn uitgeput. Veel programmeurs schrijven te veel code, waardoor het onze vijand wordt.
Als ik eenvoudigere code had geschreven die veelvoorkomende gevallen afdekte, zou het veel makkelijker zijn geweest om deze indien nodig bij te werken. Wat ik achterliet, was een puinhoop waar niemand zich mee wilde bemoeien.
Tweede plaats: adverteren op sociale netwerken
Toen ik bij Google aan social media-advertenties werkte (herinner je je Myspace nog?), schreef ik zoiets 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 zullen de fout waarschijnlijk meteen zien: het laatste argument moet j zijn, niet i. Unittesten hebben de fout niet opgemerkt, en mijn tester ook niet. De run was voltooid en op een nacht ging mijn code naar de server en crashte elke computer in het datacenter.
Er gebeurde niets vreselijks. Niemand maakte iets kapot, want vóór de wereldwijde lancering werd de code in één datacenter getest. Behalve dat de SRE-engineers even stopten met poolen en een kleine rollback uitvoerden. De volgende ochtend ontving ik een e-mail met een crashdump, corrigeerde ik de code en voegde ik unittests toe die de fout aan het licht zouden hebben gebracht. Omdat ik het protocol volgde - anders zou mijn code de lancering simpelweg niet hebben doorstaan - deden zich geen andere problemen voor.
Les geleerd
Veel mensen zijn er zeker van dat zo'n grote fout de dader gegarandeerd zijn ontslag zal kosten, maar dat is niet waar: ten eerste maakt elke programmeur fouten en ten tweede maken ze zelden dezelfde fout twee keer.
Ik ken zelfs een programmeur, een briljante ingenieur, die werd ontslagen vanwege één enkele fout. Hij werd vervolgens aangenomen bij Google (en maakte al snel promotie) omdat hij eerlijk was geweest over de fout tijdens het sollicitatiegesprek, en het werd niet als fataal beschouwd.
Stem hto over Thomas Watson, het legendarische hoofd van IBM:
Er werd een overheidsopdracht aangekondigd voor ongeveer een miljoen dollar. IBM Corporation - of liever gezegd, Thomas Watson Sr. persoonlijk - wilde die per se hebben. Helaas slaagde de salesvertegenwoordiger daar niet in en verloor IBM de aanbesteding. De volgende dag kwam de medewerker naar het kantoor van meneer Watson en legde een envelop op zijn bureau. Meneer Watson keek er niet eens naar - hij wachtte op de medewerker en wist dat het een ontslagbrief was.
Watson vroeg wat er mis was gegaan.
De verkoper gaf een gedetailleerd overzicht van de aanbesteding. Hij wees op de fouten die waren gemaakt en die vermeden hadden kunnen worden. Ten slotte zei hij: "Meneer Watson, bedankt dat u me de uitleg hebt laten geven. Ik weet hoe hard we deze bestelling nodig hadden. Ik weet hoe belangrijk hij was," en hij draaide zich om om te vertrekken.
Watson liep naar hem toe bij de deur, keek hem in de ogen en gaf hem de envelop terug. "Hoe kan ik je nu laten gaan? Ik heb net een miljoen dollar geïnvesteerd in je opleiding."
Ik heb een T-shirt met de tekst: "Als je van fouten echt iets leert, dan ben ik al een meester." Sterker nog, als het om fouten gaat, ben ik een doctoraat.
Eerste plaats: App Inventor API
Echt vreselijke fouten treffen een enorm aantal gebruikers, worden algemeen bekend, duren lang om te herstellen en worden gemaakt door mensen die ze hadden kunnen voorkomen. Mijn grootste fout voldoet aan al deze criteria.
Hoe slechter, hoe beter
Ik lees Ik heb in de jaren negentig, als promovendus, over deze aanpak nagedacht en ik ben er zo enthousiast over dat ik hem aan mijn studenten voorleg. Als je het je niet goed herinnert, fris je geheugen dan even op; het is kort. Het contrasteert de wens om "het goed te doen" met de "slechter is beter"-aanpak op veel niveaus, waaronder eenvoud.
Hoe het hoort: het ontwerp moet eenvoudig zijn in implementatie en interface. Eenvoud van de interface is belangrijker dan eenvoud van implementatie.
Hoe slechter, hoe beter: het ontwerp moet eenvoudig te implementeren en te gebruiken zijn. Gemak van implementatie is belangrijker dan gebruiksgemak.
Laten we het even vergeten. Helaas ben ik het jarenlang vergeten.
App-uitvinder
Toen ik bij Google werkte, maakte ik deel uit van een team , een online ontwikkelomgeving met drag-and-drop-functionaliteit voor beginners Android-ontwikkelaars. Het was 2009 en we haastten ons om de alfaversie op tijd uit te brengen, zodat we in de zomer workshops voor docenten konden geven, die de omgeving vervolgens in het najaar in hun klaslokalen konden gebruiken. Ik bood aan om sprites te implementeren, nostalgisch naar de tijd dat ik games schreef op de TI-99/4. Voor degenen die er niet bekend mee zijn: een sprite is een tweedimensionaal grafisch object dat kan bewegen en interactie kan hebben met andere software-elementen. Voorbeelden van sprites zijn ruimteschepen, asteroïden, ballen en peddels.
We hebben objectgeoriënteerde App Inventor in Java geïmplementeerd, dus er zijn gewoon een heleboel objecten. Omdat ballen en sprites zich zeer vergelijkbaar gedragen, heb ik een abstracte spriteklasse gemaakt met eigenschappen (velden) X, Y, Snelheid en Richting. Ze hadden dezelfde methoden voor het detecteren van botsingen, het stuiteren van de rand van het scherm, enzovoort.
Het belangrijkste verschil tussen een bal en een sprite is wat er getekend wordt: een gevulde cirkel of een raster. Omdat ik eerst sprites heb geïmplementeerd, was het logisch om de x- en y-coördinaten van de linkerbovenhoek van de plek waar de afbeelding zich bevond, te specificeren.
Toen de sprites eenmaal werkten, besloot ik dat ik de balobjecten met heel weinig code kon implementeren. Het enige probleem was dat ik de makkelijkste route (vanuit het oogpunt van een implementator) nam door de x- en y-coördinaten van de linkerbovenhoek van de omtrek die de bal omlijst, te specificeren.
In feite was het noodzakelijk om de x- en y-coördinaten van het middelpunt van de cirkel te specificeren, zoals elk wiskundeboek en elke andere bron die het woord cirkels gebruikt leert.
In tegenstelling tot mijn eerdere fouten had deze niet alleen gevolgen voor mijn collega's, maar ook voor miljoenen App Inventor-gebruikers. Velen van hen waren kinderen of hadden nog nooit eerder geprogrammeerd. Ze moesten veel extra werk doen bij elke applicatie die ze leuk vonden. Als ik met een lach terugdenk aan mijn andere fouten, dan is deze nog steeds een zweterig moment.
Ik heb deze bug pas onlangs, tien jaar later, gepatcht. "Gepatcht", niet "gerepareerd", want zoals Joshua Bloch zegt, API's zijn voor altijd. Omdat we geen wijzigingen konden aanbrengen die bestaande programma's zouden beïnvloeden, hebben we de eigenschap OriginAtCenter toegevoegd met de waarde false in oude programma's en true in alle toekomstige. Gebruikers zouden zich terecht kunnen afvragen wie er ooit op het idee is gekomen om de oorsprong ergens anders dan in het midden te plaatsen. Wie? Een programmeur die tien jaar geleden te lui was om een fatsoenlijke API te schrijven.
Geleerde lessen
Wanneer u aan een API werkt (wat vrijwel elke programmeur op een gegeven moment moet doen), moet u het beste advies opvolgen dat wordt beschreven in de video van Joshua Bloch ""of :
- API's kunnen u grote voordelen, maar ook grote schade opleverenEen goede API zorgt voor terugkerende klanten. Een slechte API wordt je eeuwige nachtmerrie.
- Publieke API's, net als diamanten, zijn voor altijdGeef alles wat je hebt: je krijgt geen tweede kans om het goed te doen.
- API-notities moeten beknopt zijn — één pagina met klasse- en methodehandtekeningen en -beschrijvingen die niet meer dan één regel in beslag nemen. Zo kunt u de API eenvoudig herstructureren als deze niet meteen perfect is.
- Beschrijf de use cases, voordat u de API implementeert of zelfs maar aan de specificatie ervan werkt. Zo voorkomt u dat u een volledig niet-functionele API implementeert en specificeert.
Als ik zelfs maar een korte samenvatting met een kunstmatig scenario had geschreven, had ik de fout hoogstwaarschijnlijk opgemerkt en gecorrigeerd. Zo niet, dan had een van mijn collega's het gedaan. Over elke beslissing met verstrekkende gevolgen moet minstens 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 hebt als eerste op de markt te zijn, zelfs met een imperfect product, terwijl iemand anders eeuwenlang naar perfectie streeft. Als ik terugkijk op de spritecode, besef ik dat ik niet eens meer code hoefde te schrijven om het goed te krijgen. Ik zat er compleet naast.
Conclusie
Programmeurs maken dagelijks fouten, of het nu gaat om het schrijven van buggy code of het nalaten om iets te proberen wat hun vaardigheden en productiviteit zou verbeteren. Natuurlijk kun je programmeur zijn zonder de grote fouten te maken die ik maakte. Maar je kunt geen goede programmeur worden zonder je bewust te zijn van je fouten en ervan te leren.
Ik kom constant studenten tegen die het gevoel hebben dat ze te veel fouten maken en daarom niet geschikt zijn voor programmeren. Ik weet hoe vaak het imposter-syndroom voorkomt in de IT. Ik hoop dat je de lessen die ik heb opgesomd, zult leren, maar onthoud de belangrijkste: iedereen maakt fouten – gênant, grappig, vreselijk. Ik zou verbaasd en teleurgesteld zijn als ik in de toekomst niet genoeg materiaal heb om dit artikel voort te zetten.
Bron: www.habr.com
