Ahogy mondani szokták, ha nem szégyelli a régi kódját, akkor nem fejlődik programozóként - és ezzel a véleménnyel egyetértek. Több mint 40 éve kezdtem el szórakozásból programozni, 30 éve pedig szakmailag, szóval sok hibám van. nagyon. Számítástechnika professzorként arra tanítom a diákjaimat, hogy tanuljanak a saját, az enyém és mások hibáiból. Azt hiszem, ideje beszélnem a hibáimról, hogy ne veszítsem el a szerénységem. Remélem hasznosak lesznek valakinek.
Harmadik hely - Microsoft C fordító
Az iskolai tanárom úgy vélte, hogy a Rómeó és Júliát nem lehet tragédiának tekinteni, mert a szereplőknek nem volt tragikus bűntudata – egyszerűen hülyén viselkedtek, ahogy a tinédzsereknek kell. Akkor nem értettem vele egyet, de most egy szemernyi racionalitást látok a véleményében, főleg a programozással kapcsolatban.
Mire befejeztem a második évemet az MIT-n, fiatal voltam és tapasztalatlan, mind az életben, mind a programozásban. Nyáron a Microsoftnál gyakorlatoztam, a C fordítócsapatban, eleinte rutinszerű dolgokat csináltam, mint például a profilkészítés támogatása, majd rám bíztak, hogy a fordítóprogram legszórakoztatóbb (ahogy gondoltam) részénél - a backend optimalizáláson - dolgozzak. Különösen az x86 kódot kellett javítanom az elágazási utasításokhoz.
Elhatároztam, hogy minden lehetséges esetre megírom az optimális gépi kódot, hanyatt-homlok belevetettem magam a medencébe. Ha az értékek eloszlási sűrűsége magas volt, beírtam őket . Ha volt közös osztójuk, akkor azt használtam, hogy szorosabbá tegyem a táblázatot (de csak akkor, ha a felosztást meg lehet tenni ). Amikor az összes érték kettő hatványa volt, egy újabb optimalizálást végeztem. Ha egy értékkészlet nem felelt meg a feltételeimnek, több optimalizálható esetre bontottam, és a már optimalizált kódot használtam.
Rémálom volt. Sok évvel később azt mondták nekem, hogy a programozó, aki örökölte a kódomat, gyűlölt engem.
Megtanulta a leckét
Ahogy David Patterson és John Hennessy írja a Computer Architecture and Computer Systems Design című könyvében, az építészet és tervezés egyik fő alapelve az, hogy általában a dolgoknak a lehető leggyorsabban kell működniük.
A gyakori esetek felgyorsítása hatékonyabban javítja a teljesítményt, mint a ritka esetek optimalizálása. Ironikus módon a gyakori esetek gyakran egyszerűbbek, mint a ritkák. Ez a logikus tanács feltételezi, hogy tudja, melyik eset számít gyakorinak – és ez csak gondos tesztelés és mérés folyamatával lehetséges.
Védekezésemre megpróbáltam kitalálni, hogyan néznek ki az elágazások a gyakorlatban (például hány ág van és hogyan oszlanak el az állandók), de 1988-ban ez az információ nem állt rendelkezésre. Azonban nem kellett volna különleges eseteket hozzáadnom, amikor a jelenlegi fordító nem tudott optimális kódot generálni az általam kitalált mesterséges példához.
Fel kellett hívnom egy tapasztalt fejlesztőt, és vele együtt át kellett gondolnom, mik a gyakori esetek, és konkrétan foglalkozni kell velük. Kevesebb kódot írnék, de ez jó dolog. Ahogy a Stack Overflow alapítója, Jeff Atwood írta, a programozó legrosszabb ellensége maga a programozó:
Tudom, hogy önnek a legjobb szándéka van, ahogy nekünk is. Programokat készítünk és szeretünk kódot írni. Így készülünk. Szerintünk minden probléma megoldható ragasztószalaggal, házi mankóval és egy csipetnyi kóddal. Bármennyire is fáj a kódolóknak ezt beismerni, a legjobb kód az, amelyik nem létezik. Minden új sor hibakeresést és támogatást igényel, meg kell érteni. Amikor új kódot ad hozzá, azt vonakodva és undorral kell megtennie, mert az összes többi lehetőség kimerült. Sok programozó túl sok kódot ír, ami az ellenségünkké teszi.
Ha egyszerűbb kódot írtam volna, amely lefedi a gyakori eseteket, akkor sokkal könnyebb lett volna frissíteni, ha szükséges. Olyan rendetlenséget hagytam magam mögött, amivel senki sem akart foglalkozni.
Második hely: hirdetés a közösségi hálózatokon
Amikor a Google-nál dolgoztam a közösségi média hirdetéseivel (emlékszel a Myspace-re?), valami ilyesmit írtam C++ nyelven:
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)) {
}
}A programozók azonnal láthatják a hibát: az utolsó argumentum j legyen, ne i. Az egységteszt nem tárta fel a hibát, és a véleményezőm sem. Az indítás megtörtént, és egy éjszaka a kódom a szerverre került, és az adatközpontban lévő összes számítógép összeomlott.
Semmi rossz nem történt. Senkinek nem tört el semmi, mert a globális bevezetés előtt a kódot egy adatközponton belül tesztelték. Hacsak az SRE mérnökei nem hagyták abba egy időre a biliárdozást, és nem tettek egy kicsit vissza. Másnap reggel kaptam egy e-mailt egy összeomlási kiírással, javítottam a kódot, és olyan egységteszteket adtam hozzá, amelyek észlelik a hibát. Mivel követtem a protokollt - különben egyszerűen nem futna a kódom - nem volt más probléma.
Megtanulta a leckét
Sokan biztosak abban, hogy egy ilyen súlyos hiba minden bizonnyal az elkövető elbocsátásával jár, de ez nem így van: egyrészt minden programozó hibázik, másrészt ritkán követi el ugyanazt a hibát kétszer.
Valójában van egy programozó barátom, aki zseniális mérnök volt, és egyetlen hiba miatt kirúgták. Ezt követően felvették a Google-hoz (és hamarosan előléptették) – őszintén beszélt egy interjúban elkövetett hibájáról, és ez nem számított végzetesnek.
Ez az Thomas Watsonról, az IBM legendás vezetőjéről:
Körülbelül egymillió dollár értékű kormányrendelést jelentettek be. Az IBM Corporation – vagy inkább Thomas Watson Sr. személy szerint – nagyon szerette volna megszerezni. Sajnos az értékesítési képviselő ezt nem tudta megtenni, és az IBM elvesztette az ajánlatot. Másnap ez az alkalmazott bement Mr. Watson irodájába, és egy borítékot tett az asztalára. Mr. Watson nem is vette a fáradságot, hogy megnézze – egy alkalmazottra várt, és tudta, hogy ez egy felmondólevél.
Watson megkérdezte, mi történt.
Az értékesítési képviselő részletesen beszélt a pályázat menetéről. Nevezte az elkövetett hibákat, amelyek elkerülhetők lettek volna. Végül így szólt: „Mr. Watson, köszönöm, hogy elmagyarázta. Tudom, mennyire szükségünk volt erre a megrendelésre. Tudom, milyen fontos volt – és indulni készült.
Watson odalépett hozzá az ajtóban, a szemébe nézett, és visszaadta a borítékot a következő szavakkal: „Hogyan engedhetlek el? Most fektettem egymillió dollárt az oktatásodba.
Van egy pólóm, amelyen ez áll: "Ha tényleg tanulsz a hibákból, akkor már mester vagyok." Ami a hibákat illeti, valójában a tudomány doktora vagyok.
Első helyezett: App Inventor API
Az igazán szörnyű hibák rengeteg felhasználót érintenek, köztudomásúakká válnak, kijavításuk sokáig tart, és olyanok követik el őket, akik nem tudták elkövetni. A legnagyobb hibám mindezen kritériumoknak megfelel.
Minél rosszabb, annál jobb
olvasok erről a megközelítésről a kilencvenes években végzős hallgatóként, és annyira tetszik, hogy megkérdezem a hallgatóimtól. Ha nem jól emlékszel, frissítsd fel az emlékezeted, kicsi. Ez az esszé sok tekintetben szembeállítja a „jóra fordulás” vágyát és a „rosszabb, annál jobb” megközelítést sok szempontból, beleértve az egyszerűséget is.
Milyen legyen: a tervezésnek egyszerűnek kell lennie a megvalósításban és a felületen. Az interfész egyszerűsége fontosabb, mint a megvalósítás egyszerűsége.
Minél rosszabb, annál jobb: a tervezésnek egyszerűnek kell lennie a megvalósításban és a felületen. A megvalósítás egyszerűsége fontosabb, mint az interfész egyszerűsége.
Ezt felejtsük el egy percre. Sajnos sok évre megfeledkeztem róla.
App Inventor
Amíg a Google-nál dolgoztam, a csapat tagja voltam , egy drag and drop online fejlesztői környezet a feltörekvő Android-fejlesztők számára. 2009 volt, és siettünk időben kiadni az alfa verziót, hogy nyáron mesterkurzusokat tarthassunk azoknak a tanároknak, akik az őszi tanítás során tudják használni a környezetet. Önként vállaltam a sprite-ok megvalósítását, nosztalgiázva arra, hogyan szoktam játékokat írni a TI-99/4-re. Azok számára, akik nem ismerik, a sprite egy kétdimenziós grafikus objektum, amely képes mozogni és kölcsönhatásba lépni más szoftverelemekkel. A sprite példái közé tartoznak az űrhajók, aszteroidák, golyók és ütők.
Az objektumorientált App Inventort Java nyelven implementáltuk, így csak egy csomó objektum van benne. Mivel a golyók és a sprite-ok nagyon hasonlóan viselkednek, létrehoztam egy absztrakt sprite osztályt X, Y, Speed (sebesség) és Heading (irány) tulajdonságokkal. Ugyanazok a módszereik voltak az ütközések észlelésére, a képernyő széléről való visszapattanásra stb.
A fő különbség a labda és a sprite között az, hogy pontosan mit rajzolunk – egy kitöltött kört vagy egy rasztert. Mivel először a sprite-okat implementáltam, logikus volt, hogy megadjam a kép helyének bal felső sarkának x- és y-koordinátáit.
Miután a sprite-ok működtek, úgy döntöttem, hogy nagyon kevés kóddal tudok golyós objektumokat megvalósítani. A gond csak az volt, hogy a (megvalósító szempontjából) legegyszerűbb útvonalat választottam, a labdát keretező kontúr bal felső sarkának x- és y-koordinátáit feltüntetve.
Valójában a kör középpontjának x- és y-koordinátáit kellett feltüntetni, ahogyan azt minden matematika tankönyv és minden más kört említő forrás tanítja.
A korábbi hibáimmal ellentétben ez nem csak a kollégáimat, hanem az App Inventor felhasználók millióit is érintette. Sokan közülük gyerekek voltak, vagy teljesen újak voltak a programozásban. Rengeteg szükségtelen lépést kellett végrehajtaniuk, amikor minden olyan alkalmazáson dolgoztak, amelyben a labda jelen volt. Ha nevetve emlékszem vissza a többi hibámra, akkor ez még ma is megizzaszt.
Végül csak nemrég, tíz évvel később javítottam ki ezt a hibát. „Patched”, nem „javított”, mert ahogy Joshua Bloch mondja, az API-k örökkévalóak. Nem tudtunk olyan változtatásokat végrehajtani, amelyek a meglévő programokat érintenék, ezért hozzáadtuk az OriginAtCenter tulajdonságot false értékkel a régi programokban, és true értékkel az összes jövőbeni programban. A felhasználók feltehetnek egy logikus kérdést: kinek jutott eszébe, hogy a kiindulási pontot a középponton kívül máshová helyezze el. Kinek? Egy programozónak, aki túl lusta volt egy normál API létrehozásához tíz évvel ezelőtt.
Tanulságok
Amikor API-kon dolgozik (amit néha szinte minden programozónak meg kell tennie), kövesse a Joshua Bloch videójában felvázolt legjobb tanácsokat.vagy :
- Egy API nagy előnyökkel és károkkal is járhat.. Egy jó API visszatérő ügyfeleket hoz létre. A rossz örök rémálmod lesz.
- A nyilvános API-k, akárcsak a gyémántok, örökké tartanak. Adj bele mindent: soha többé nem lesz lehetőség arra, hogy mindent jól csinálj.
- Az API-vázlatoknak rövidnek kell lenniük — egy oldal osztály- és metódusaláírásokkal és leírásokkal, legfeljebb egy sort foglalva. Ez lehetővé teszi az API egyszerű átstrukturálását, ha az első alkalommal nem lesz tökéletes.
- Ismertesse a felhasználási eseteketaz API megvalósítása vagy akár a specifikációján való munka előtt. Így elkerülheti egy teljesen nem működő API megvalósítását és megadását.
Ha csak egy rövid szinopszist írtam volna mesterséges forgatókönyvvel, valószínűleg azonosítottam volna a hibát, és kijavítottam volna. Ha nem, akkor az egyik kollégám biztosan megtenné. Minden olyan döntésen, amelynek messzemenő következményei vannak, legalább egy napig gondolkodni kell (ez nem csak a programozásra vonatkozik).
Richard Gabriel esszéjének címe: „A rosszabb a jobb” arra az előnyre utal, hogy elsőként kerül a piacra – még egy tökéletlen termék esetén is –, miközben valaki más egy örökkévalóságon át a tökéleteset kergeti. A sprite kódon töprengve rájövök, hogy nem is kellett több kódot írnom, hogy helyes legyen. Bármit mondjon valaki, nagyot tévedtem.
Következtetés
A programozók nap mint nap követnek el hibákat, akár hibás kódot írnak, akár nem akarnak kipróbálni valamit, ami javítja készségeiket és termelékenységüket. Természetesen lehetsz programozó anélkül, hogy olyan súlyos hibákat követnél el, mint én. De lehetetlen jó programozóvá válni anélkül, hogy felismerné a hibáit, és nem tanulna belőlük.
Folyamatosan találkozom olyan diákokkal, akik úgy érzik, hogy túl sok hibát követnek el, és ezért nem akarják őket programozni. Tudom, milyen gyakori az imposztor szindróma az informatikában. Remélem, megtanulod az általam felsorolt leckéket – de ne feledd a legfontosabbat: mindannyian követünk el hibákat – kínosak, viccesek, szörnyűek. Meg fogok lepődni és ideges leszek, ha a jövőben nem lesz elég anyagom a cikk folytatásához.
Forrás: will.com