Siç thonë ata, nëse nuk keni turp për kodin tuaj të vjetër, atëherë nuk po rriteni si programues - dhe unë pajtohem me këtë mendim. Kam filluar të programoj për argëtim mbi 40 vjet më parë, dhe profesionalisht 30 vjet më parë, kështu që kam shumë gabime. shumë. Si profesor i shkencave kompjuterike, unë i mësoj studentët e mi të mësojnë nga gabimet—të tyre, të miat dhe të të tjerëve. Mendoj se është koha të flas për gabimet e mia për të mos humbur modestinë time. Shpresoj se do të jenë të dobishme për dikë.
Vendi i tretë - përpiluesi i Microsoft C
Mësuesi im i shkollës besonte se Romeo dhe Zhuljeta nuk mund të konsideroheshin si një tragjedi, sepse personazhet nuk kishin faj tragjik - ata thjesht silleshin marrëzisht, siç duhej të adoleshentët. Atëherë nuk isha dakord me të, por tani shoh një kokërr racionaliteti në mendimin e tij, veçanërisht në lidhje me programimin.
Në kohën kur mbarova vitin e dytë në MIT, isha i ri dhe pa përvojë, si në jetë ashtu edhe në programim. Në verë, unë internova në Microsoft, në ekipin e përpiluesit C. Në fillim bëra gjëra rutinë si mbështetje për profilizimin, dhe më pas m'u besua të punoja në pjesën më argëtuese të përpiluesit (siç mendova) - optimizimin e backend-it. Në veçanti, më duhej të përmirësoja kodin x86 për deklaratat e degëve.
I vendosur të shkruaj kodin optimal të makinës për çdo rast të mundshëm, u hodha në pishinë me kokë. Nëse densiteti i shpërndarjes së vlerave ishte i lartë, i futa ato . Nëse ata kishin një pjesëtues të përbashkët, unë e përdora atë për ta bërë tabelën më të ngushtë (por vetëm nëse ndarja mund të bëhej duke përdorur ). Kur të gjitha vlerat ishin fuqi dyshe, bëra një optimizim tjetër. Nëse një grup vlerash nuk i plotësonte kushtet e mia, unë e ndaja atë në disa raste të optimizueshme dhe përdora kodin tashmë të optimizuar.
Ishte një makth. Shumë vite më vonë më thanë se programuesi që trashëgoi kodin tim më urrente.
Mesimi u mesua
Siç shkruajnë David Patterson dhe John Hennessy në Architecture Computer and Computer Systems Design, një nga parimet kryesore të arkitekturës dhe dizajnit është që, në përgjithësi, gjërat duhet të funksionojnë sa më shpejt që të jetë e mundur.
Përshpejtimi i rasteve të zakonshme do të përmirësojë performancën në mënyrë më efektive sesa optimizimi i rasteve të rralla. Ironikisht, rastet e zakonshme janë shpesh më të thjeshta se ato të rralla. Kjo këshillë logjike supozon se ju e dini se cili rast konsiderohet i zakonshëm - dhe kjo është e mundur vetëm përmes një procesi testimi dhe matjeje të kujdesshme.
Në mbrojtjen time, u përpoqa të kuptoja se si dukeshin në praktikë deklaratat e degëve (si p.sh. sa degë kishte dhe si u shpërndanë konstante), por në vitin 1988 ky informacion nuk ishte i disponueshëm. Megjithatë, nuk duhej të kisha shtuar raste të veçanta sa herë që përpiluesi aktual nuk mund të gjeneronte kodin optimal për shembullin artificial që dola.
Më duhej të telefonoja një zhvillues me përvojë dhe, së bashku me të, të mendoja se cilat ishin rastet e zakonshme dhe t'i trajtoja ato në mënyrë specifike. Do të shkruaja më pak kod, por kjo është një gjë e mirë. Siç shkroi themeluesi i Stack Overflow, Jeff Atwood, armiku më i keq i një programuesi është vetë programuesi:
E di që ti ke qëllimet më të mira, ashtu si ne të gjithë. Ne krijojmë programe dhe na pëlqen të shkruajmë kode. Kështu jemi bërë ne. Ne mendojmë se çdo problem mund të zgjidhet me shirit ngjitës, një paterica të bërë vetë dhe një majë kodi. Aq sa i mundon koduesit ta pranojnë atë, kodi më i mirë është kodi që nuk ekziston. Çdo linjë e re ka nevojë për korrigjim dhe mbështetje, duhet kuptuar. Kur shtoni kod të ri, duhet ta bëni këtë me ngurrim dhe neveri, sepse të gjitha opsionet e tjera janë ezauruar. Shumë programues shkruajnë shumë kode, duke e bërë atë armikun tonë.
Nëse do të kisha shkruar një kod më të thjeshtë që mbulonte rastet e zakonshme, do të ishte shumë më e lehtë të përditësohej nëse ishte e nevojshme. Kam lënë pas një rrëmujë me të cilën askush nuk donte të merrej.
Vendi i dytë: reklamimi në rrjetet sociale
Kur punoja në Google për reklamat në mediat sociale (ju kujtohet Myspace?), shkrova diçka të tillë në 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)) {
}
}Programuesit mund ta shohin menjëherë gabimin: argumenti i fundit duhet të jetë j, jo i. Testimi i njësisë nuk e zbuloi gabimin, dhe as rishikuesi im. Nisja u krye dhe një natë kodi im shkoi në server dhe rrëzoi të gjithë kompjuterët në qendrën e të dhënave.
Asgjë e keqe nuk ndodhi. Asgjë nuk u prish për askënd, sepse para lëshimit global kodi u testua brenda një qendre të dhënash. Përveç nëse inxhinierët e SRE ndaluan së luajturi bilardo për një kohë dhe bënin pak kthim prapa. Të nesërmen në mëngjes mora një email me një dështim, korrigjova kodin dhe shtova testet e njësisë që do të kapnin gabimin. Meqenëse ndoqa protokollin - përndryshe kodi im thjesht nuk do të ekzekutohej - nuk kishte probleme të tjera.
Mesimi u mesua
Shumë janë të sigurt se një gabim kaq i madh patjetër do t'i kushtojë fajtorit shkarkimin, por kjo nuk është kështu: së pari, të gjithë programuesit bëjnë gabime, dhe së dyti, ata rrallë bëjnë të njëjtin gabim dy herë.
Në fakt, unë kam një mik programues që ishte një inxhinier i shkëlqyer dhe u pushua nga puna për një gabim të vetëm. Pas kësaj, ai u punësua në Google (dhe së shpejti u promovua) - ai foli sinqerisht për gabimin që bëri në një intervistë dhe nuk u konsiderua fatale.
Ja cfarë për Thomas Watson, kreun legjendar të IBM:
U njoftua një urdhër qeveritar me vlerë rreth një milion dollarë. IBM Corporation - ose më mirë, personalisht Thomas Watson Sr. - donte vërtet ta merrte atë. Fatkeqësisht, përfaqësuesi i shitjeve nuk ishte në gjendje ta bënte këtë dhe IBM humbi ofertën. Të nesërmen, ky punonjës hyri në zyrën e zotit Watson dhe vendosi një zarf në tavolinën e tij. Z. Watson as që u mërzit ta shikonte - ai priste një punonjës dhe e dinte se ishte një letër dorëheqjeje.
Watson pyeti se çfarë shkoi keq.
Përfaqësuesi i shitjeve foli në detaje për ecurinë e tenderit. Ai përmendi gabimet e bëra që mund të ishin shmangur. Më në fund, ai tha: “Zoti Watson, faleminderit që më lejuat të shpjegoj. E di sa shumë na duhej ky urdhër. E di sa i rëndësishëm ishte ai,” dhe u bë gati të largohej.
Watson iu afrua te dera, e pa në sy dhe ia ktheu zarfin me fjalët: “Si mund të të lë të shkosh? Unë sapo investova një milion dollarë në arsimimin tuaj.
Unë kam një bluzë që thotë: "Nëse vërtet mëson nga gabimet, atëherë unë jam tashmë një mjeshtër". Në fakt, kur bëhet fjalë për gabime, unë jam doktor shkencash.
Vendi i parë: App Inventor API
Gabimet vërtet të tmerrshme prekin një numër të madh përdoruesish, bëhen të njohura publike, kërkojnë shumë kohë për t'u korrigjuar dhe bëhen nga ata që nuk mund t'i kishin bërë. Gabimi im më i madh i përshtatet të gjitha këtyre kritereve.
Sa më keq aq më mirë
unë lexoj për këtë qasje në vitet nëntëdhjetë si studente e diplomuar, dhe më pëlqen aq shumë sa ua kërkoj studentëve të mi. Nëse nuk e mbani mend mirë, rifreskojeni kujtesën, është e vogël. Kjo ese kontraston dëshirën për "të marrë atë siç duhet" dhe qasjen "më keq është më mirë" në shumë mënyra, duke përfshirë thjeshtësinë.
Si duhet të jetë: dizajni duhet të jetë i thjeshtë në zbatim dhe ndërfaqe. Thjeshtësia e ndërfaqes është më e rëndësishme se thjeshtësia e zbatimit.
Sa më keq, aq më mirë: dizajni duhet të jetë i thjeshtë në zbatim dhe ndërfaqe. Thjeshtësia e zbatimit është më e rëndësishme se thjeshtësia e ndërfaqes.
Le ta harrojmë për një minutë. Fatkeqësisht, e kam harruar për shumë vite.
Shpikësi i aplikacioneve
Ndërsa punoja në Google, isha pjesë e ekipit , një mjedis zhvillimi në internet zvarrit-dhe lësho për zhvilluesit aspirantë të Android. Ishte viti 2009 dhe ne nxituam të nxirrnim në kohë versionin alfa, në mënyrë që gjatë verës të zhvillonim klasa master për mësuesit që mund të përdornin mjedisin gjatë mësimit në vjeshtë. Dola vullnetare për të zbatuar sprites, me nostalgji për mënyrën se si shkruaja lojëra në TI-99/4. Për ata që nuk e dinë, një sprite është një objekt grafik dydimensional që mund të lëvizë dhe të ndërveprojë me elementë të tjerë të softuerit. Shembuj të spriteve përfshijnë anije kozmike, asteroidë, mermerë dhe raketa.
Ne kemi implementuar App Inventor të orientuar drejt objekteve në Java, kështu që ka vetëm një grup objektesh atje. Meqenëse topat dhe spritet sillen shumë në mënyrë të ngjashme, unë krijova një klasë sprite abstrakte me vetitë (fushat) X, Y, Shpejtësia (shpejtësia) dhe Heading (drejtimi). Ata kishin të njëjtat metoda për zbulimin e përplasjeve, kërcimin nga skaji i ekranit, etj.
Dallimi kryesor midis një topi dhe një sprite është ajo që vizatohet saktësisht - një rreth i mbushur ose një raster. Meqenëse unë zbatova spritet fillimisht, ishte logjike të specifikoja koordinatat x dhe y të këndit të sipërm të majtë të vendit ku ndodhej imazhi.
Pasi spritet po funksiononin, vendosa që të mund të zbatoja objekte të topit me shumë pak kod. Problemi i vetëm ishte se mora rrugën më të thjeshtë (nga këndvështrimi i zbatuesit), duke treguar koordinatat x- dhe y të këndit të sipërm të majtë të konturit që inkuadron topin.
Në fakt, ishte e nevojshme të tregoheshin koordinatat x- dhe y të qendrës së rrethit, siç mësohet në çdo tekst të matematikës dhe në çdo burim tjetër që përmend rrathët.
Ndryshe nga gabimet e mia të kaluara, ky nuk preku vetëm kolegët e mi, por edhe miliona përdorues të App Inventor. Shumë prej tyre ishin fëmijë ose krejtësisht të rinj në programim. Atyre iu desh të kryenin shumë hapa të panevojshëm kur punonin në çdo aplikacion në të cilin topi ishte i pranishëm. Nëse gabimet e tjera i kujtoj me të qeshur, atëherë ky më bën të djersitem edhe sot.
Më në fund e rregullova këtë problem vetëm kohët e fundit, dhjetë vjet më vonë. "I arnuar", jo "i rregulluar", sepse siç thotë Joshua Bloch, API-të janë të përjetshme. Në pamundësi për të bërë ndryshime që do të preknin programet ekzistuese, shtuam veçorinë OriginAtCenter me vlerën false në programet e vjetra dhe true në të gjitha ato të ardhshme. Përdoruesit mund të bëjnë një pyetje logjike: kush mendoi të vendoste pikën e fillimit diku tjetër përveç qendrës. Kujt? Për një programues që ishte shumë dembel për të krijuar një API normale dhjetë vjet më parë.
Mesimet e mesuara
Kur punoni në API (të cilat pothuajse çdo programues duhet ta bëjë ndonjëherë), duhet të ndiqni këshillat më të mira të përshkruara në videon e Joshua Bloch ""ose :
- Një API mund t'ju sjellë përfitime të mëdha dhe dëme të mëdha.. Një API e mirë krijon klientë të përsëritur. E keqja bëhet makthi juaj i përjetshëm.
- API-të publike, si diamantet, zgjasin përgjithmonë. Jepni gjithçka: nuk do të ketë kurrë një shans tjetër për të bërë gjithçka siç duhet.
- Përvijimet e API-së duhet të jenë të shkurtra — një faqe me nënshkrime dhe përshkrime të klasës dhe metodës, që nuk zë më shumë se një rresht. Kjo do t'ju lejojë të ristrukturoni lehtësisht API-në nëse nuk rezulton i përsosur herën e parë.
- Përshkruani rastet e përdorimitpërpara se të implementoni API-në apo edhe të punoni në specifikimin e tij. Në këtë mënyrë ju do të shmangni zbatimin dhe specifikimin e një API plotësisht jofunksionale.
Nëse do të kisha shkruar qoftë edhe një përmbledhje të shkurtër me një skenar artificial, me shumë mundësi do ta kisha identifikuar gabimin dhe do ta korrigjoja. Nëse jo, atëherë një nga kolegët e mi do ta bënte patjetër. Çdo vendim që ka pasoja të gjera duhet të mendohet për të paktën një ditë (kjo vlen jo vetëm për programimin).
Titulli i esesë së Richard Gabriel, "Worse Is Better", i referohet avantazhit që shkon për të qenë i pari në treg – edhe me një produkt të papërsosur – ndërsa dikush tjetër kalon një përjetësi duke ndjekur të përsosurin. Duke reflektuar mbi kodin sprite, kuptoj se as që më duhej të shkruaja më shumë kod për ta marrë atë të drejtë. Çfarëdo që mund të thotë dikush, gabova rëndë.
Përfundim
Programuesit bëjnë gabime çdo ditë, pavarësisht nëse shkruajnë kodin e gabimeve ose nuk duan të provojnë diçka që do të përmirësojë aftësitë dhe produktivitetin e tyre. Sigurisht, ju mund të jeni një programues pa bërë gabime kaq të rënda si unë. Por është e pamundur të bëhesh një programues i mirë pa i njohur gabimet e tua dhe pa mësuar prej tyre.
Unë vazhdimisht ndeshem me studentë që mendojnë se bëjnë shumë gabime dhe për këtë arsye nuk janë të përjashtuar nga programimi. E di sa e zakonshme është sindroma mashtruese në IT. Shpresoj se do të mësoni mësimet që kam renditur - por mbani mend kryesorin: secili prej nesh bën gabime - të turpshme, qesharake, të tmerrshme. Do të habitem dhe do të mërzitem nëse në të ardhmen nuk do të kem materiale të mjaftueshme për të vazhduar artikullin.
Burimi: www.habr.com