Esaten den bezala, zure kode zaharraz lotsatzen ez bazara, ez zara programatzaile gisa hazten ari - eta ados nago iritzi honekin. Duela 40 urte baino gehiago dibertsiorako programatzen hasi nintzen, eta profesionalki duela 30 urte, beraz, akats asko ditut. asko. Informatika irakaslea naizen heinean, nire ikasleei akatsetatik ikasten irakasten diet, haienak, nireak eta besteenak. Nire akatsez hitz egiteko garaia dela uste dut, apaltasuna ez galtzeko. Norbaitentzako baliagarriak izango direla espero dut.

Hirugarren postua - Microsoft C konpilatzailea

Nire eskolako irakasleak uste zuen Romeo eta Julieta ezin zirela tragediatzat hartu, pertsonaiek ez zutelako erru tragikorik; ergelkeriaz jokatzen zuten, nerabeek behar luketen moduan. Orduan ez nengoen ados berarekin, baina orain arrazionaltasun ale bat ikusten diot bere ustez, batez ere programazioarekin lotuta.

MITen bigarren ikasturtea amaitu nuenerako, gaztea eta esperientziarik gabekoa nintzen, bizitzan zein programazioan. Udan, Microsoft-en egin nuen praktikak, C konpilatzaile taldean. Hasieran ohiko gauzak egiten nituen profilaren euskarria bezalakoak, eta gero konpilatzailearen zatirik dibertigarriena (uste nuen bezala) lan egitea agindu zidaten: backend optimizazioa. Bereziki, x86 kodea hobetu behar izan nuen adar-adierazpenetarako.

Kasu posible bakoitzerako makina-kode optimoa idazteko erabakia hartu nuen, buru-belarri bota nuen igerilekura. Balioen banaketa dentsitatea handia bazen, sartu nituen trantsizio taula. Zatitzaile komun bat bazuten, mahaia estutzeko erabiltzen nuen (baina bakarrik zatiketa erabiliz egin zitekeen bit-aldaketa). Balio guztiak biren potentzia zirenean, beste optimizazio bat egin nuen. Balio multzo batek nire baldintzak betetzen ez baditu, hainbat kasu optimizagarritan banatu dut eta jada optimizatutako kodea erabili dut.

Amesgaiztoa izan zen. Urte asko geroago esan zidaten nire kodea heredatu zuen programatzaileak gorroto ninduela.

Ikasgaia

David Pattersonek eta John Hennessy-k Computer Architecture and Computer Systems Design-en idazten dutenez, arkitekturaren eta diseinuaren printzipio nagusietako bat, oro har, gauzak ahalik eta azkarren funtzionatzea da.

Kasu arruntak bizkortzeak errendimendua hobetuko du kasu bakanak optimizatzeak baino. Ironikoki, kasu arruntak sarritan bakanak baino sinpleagoak dira. Aholku logiko honek suposatzen du badakizula zein kasu ohikotzat jotzen den, eta hori proba eta neurketa zorrotzen prozesu baten bidez bakarrik da posible.

Nire defentsan, praktikan adar-adierazpenak nolakoak ziren (adibidez, zenbat adar zeuden eta konstanteak nola banatu ziren) irudikatzen saiatu nintzen, baina 1988an informazio hori ez zegoen eskuragarri. Hala ere, ez nuke kasu berezirik gehitu behar oraingo konpilatzaileak kode optimoa sortu ezin izan dudan adibide artifizialarentzat.

Esperientziadun garatzaile bati deitu behar nion eta, berarekin batera, ohiko kasuak zeintzuk ziren pentsatu eta berariaz landu. Kode gutxiago idatziko nuke, baina hori ona da. Jeff Atwood Stack Overflow sortzaileak idatzi zuenez, programatzaile baten etsairik okerrena programatzailea bera da:

Badakit asmorik onena duzula, denok bezala. Programak sortzen ditugu eta kodea idaztea gustatzen zaigu. Horrela eginak gaude. Uste dugu edozein arazo konpon daitekeela zintarekin, etxeko makuluarekin eta kode pixka batekin. Kodegileei hori aitortzeak pena ematen dien bezala, koderik onena existitzen ez den kodea da. Lerro berri bakoitzak arazketa eta laguntza behar du, ulertu behar da. Kode berria gehitzen duzunean, nahigabe eta nazkarekin egin beharko zenuke, beste aukera guztiak agortu direlako. Programatzaile askok kode gehiegi idazten dute, gure etsaia bihurtuz.

Kasu arruntak biltzen dituen kode sinpleagoa idatzi izan banu, behar izanez gero eguneratzea askoz errazagoa izango zen. Inork aurre egin nahi ez zion nahaspila atzean utzi nuen.

Bigarren postua: sare sozialetako publizitatea

Googlen sare sozialetako publizitatean lanean ari nintzela (gogoratzen al zara Myspace?), honelako zerbait idatzi nuen C++-n:

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

Programatzaileek berehala ikus dezakete errorea: azken argumentuak j izan behar du, ez i. Unitate-probak ez du akatsa agerian utzi, eta nire ebaluatzaileak ere ez. Abian jarri zen, eta gau batean nire kodea zerbitzarira joan zen eta datu-zentroko ordenagailu guztiak huts egin zituen.

Ez zen ezer txarrik gertatu. Inorentzat ez zen ezer hautsi, mundu mailako abian jarri aurretik kodea datu-zentro batean probatu baitzen. SREko ingeniariek billarra jokatzeari utzi eta atzera pixka bat egin ez badute behintzat. Biharamunean, mezu elektroniko bat jaso nuen kraskadura-iraulketa batekin, kodea zuzendu eta errorea atzemango zuten unitate-probak gehitu nituen. Protokoloa jarraitu nuenez -bestela nire kodea exekutatzen huts egingo litzateke- ez zen beste arazorik egon.

Ikasgaia

Askok ziur daude halako akats handi batek errudunaren kaleratzea kostatuko zaiola zalantzarik gabe, baina ez da horrela: lehenik eta behin, programatzaile guztiek akatsak egiten dituzte eta, bigarrenik, oso gutxitan egiten dute akats bera bi aldiz.

Izan ere, programatzaile bat daukat ingeniari bikaina zena eta akats bakar bat egiteagatik kaleratu zutena. Horren ostean, Googlen kontratatu zuten (eta laster sustatu zuten) - zintzotasunez hitz egin zuen elkarrizketa batean egindako akatsaz, eta ez zen hilgarritzat jo.

Hori da kontatu Thomas Watson IBMko buru mitikoari buruz:

Milioi bat dolar inguruko gobernu agindua iragarri zen. IBM Corporation - edo hobeto esanda, Thomas Watson Sr. pertsonalki - benetan lortu nahi zuen. Zoritxarrez, salmenta-ordezkariak ezin izan zuen hori egin eta IBMk eskaintza galdu zuen. Hurrengo egunean, langile hau Watson jaunaren bulegora sartu zen eta gutun-azal bat jarri zuen bere mahaian. Watson jaunak ez zuen begiratu ere egin: langile baten zain zegoen eta bazekien dimisio gutuna zela.

Watsonek galdetu zuen zer gertatu zen gaizki.

Salmenta-ordezkariak zehatz-mehatz hitz egin zuen lizitazioaren bilakaerari buruz. Saihestu zitezkeen akatsak izendatu zituen. Azkenik, esan zuen: “Watson jauna, eskerrik asko azaltzen uzteagatik. Badakit zenbat behar genuen agindu hau. Badakit zein garrantzitsua izan zen», eta irteteko prest jarri zen.

Watson atean hurbildu zitzaion, begietara begiratu eta gutun-azala itzuli zion hitz hauekin: «Nola utziko dizut? Milioi bat dolar inbertitu berri ditut zure hezkuntzan.

Nik dioen kamiseta bat daukat: "Benetan akatsetatik ikasten baduzu, orduan maisua naiz jada". Izan ere, akatsei dagokienez, zientzietan doktorea naiz.

Lehen postua: App Inventor API

Benetan akats izugarriek erabiltzaile kopuru handi bati eragiten diote, publiko bihurtzen dira, denbora luzea behar dute zuzentzeko eta egin ezin izan dutenek egiten dituzte. Nire akatsik handiena irizpide guzti hauetara egokitzen da.

Zenbat eta okerrago hobe

irakurtzen dut Richard Gabrielen saiakera laurogeita hamarreko hamarkadan graduondoko ikasle gisa planteamendu horri buruz, eta hainbeste gustatzen zait non ikasleei galdetzen diet. Ondo gogoratzen ez baduzu, freskatu memoria, txikia da. Saiakera honek "ondo ateratzeko" nahia eta "okerrago hobea da" ikuspegia kontrajartzen ditu hainbat modutan, sinpletasuna barne.

Nola izan behar du: diseinuak inplementazioan eta interfazean sinplea izan behar du. Interfazearen sinpletasuna inplementazioaren sinpletasuna baino garrantzitsuagoa da.

Zenbat eta okerragoa, orduan eta hobea: diseinuak inplementazioan eta interfazean sinplea izan behar du. Inplementazioaren sinpletasuna interfazearen sinpletasuna baino garrantzitsuagoa da.

Ahaztu gaitezen horretaz minutu batez. Zoritxarrez, urte askotan ahaztu nuen.

Aplikazioen asmatzailea

Googlen lanean ari nintzenean, taldeko parte izan nintzen Aplikazioen asmatzailea, arrastatu eta jaregin sareko garapen-ingurune bat Android garatzaile nahi dutenentzat. 2009a zen, eta presaka geneukan alfa bertsioa garaiz kaleratzeko, udan udazkenean irakaskuntzan ingurunea erabil zezaketen irakasleentzako klase magistralak egin ahal izateko. Spriteak ezartzeko boluntario aurkeztu nintzen, TI-99/4-n jokoak idazten nituenaren nostalgikoa. Ezagutzen ez dutenentzat, sprite bat bi dimentsioko objektu grafiko bat da, mugitu eta beste software-elementu batzuekin elkarreragin dezakeena. Spriteen adibideak espazio-ontziak, asteroideak, kanikak eta erraketak dira.

Objektuetara zuzendutako App Inventor inplementatu dugu Javan, beraz, objektu mordoa dago bertan. Bolak eta spriteek oso antzeko portaera dutenez, sprite klase abstraktu bat sortu nuen propietateekin (eremuak) X, Y, Abiadura (abiadura) eta Heading (norabidea). Talkak detektatzeko, pantailaren ertzetik errebotatzeko, etab. metodo berdinak zituzten.

Bola eta sprite baten arteko desberdintasun nagusia marrazten dena da: zirkulu bete bat edo raster bat. Sprites lehenik inplementatu nituenez, logikoa zen irudia kokatuta zegoen goiko ezkerreko izkinan x- eta y-koordenatuak zehaztea.

Spriteak lanean ari zirela, bola-objektuak oso kode gutxirekin inplementatu nezakeela erabaki nuen. Arazo bakarra zen biderik errazena hartu nuela (inplementatzailearen ikuspuntutik), pilota enkoadratuz sestraren goiko ezkerreko izkinan x- eta y-koordenatuak adieraziz.

Izan ere, zirkuluaren zentroaren x- eta y-koordenatuak adierazi behar ziren, edozein matematika-liburutan eta zirkuluak aipatzen dituen beste edozein iturritan irakasten den moduan.

Nire iraganeko akatsek ez bezala, honek nire lankideei ez ezik, App Inventor-eko milioika erabiltzaileri ere eragin zien. Horietako asko umeak ziren edo programazioan guztiz berriak ziren. Baloia zegoen aplikazio bakoitzean alferrikako urrats asko egin behar izan zituzten. Nire beste akatsak barrez gogoratzen baditut, honek izerditan jartzen nau gaur ere.

Azkenean, akats hau duela gutxi aldatu nuen, hamar urte geroago. "Adabakia", ez "finkoa", Joshua Blochek dioen bezala, APIak betikoak direlako. Lehendik dauden programetan eragina izango luketen aldaketarik egin ezinik, OriginAtCenter propietatea gehitu dugu programa zaharretan false balioarekin eta etorkizuneko guztietan egia. Erabiltzaileek galdera logiko bat egin dezakete: abiapuntua erdigunea ez den leku batean jartzea pentsatu ere. Nori? Duela hamar urte API normal bat sortzeko alferra zen programatzaile bati.

Ikasgaiak

APIetan lan egiten duzunean (ia programatzaile guztiek egin behar izaten dute batzuetan), Joshua Bloch-en bideoan adierazitako aholku onenak jarraitu behar dituzu "Nola sortu API on bat eta zergatik den hain garrantzitsua"or zerrenda labur honetan:

• API batek onura handia eta kalte handia ekar diezazuke.. API on batek behin eta berriz bezeroak sortzen ditu. Txarra zure betiko amesgaizto bihurtzen da.
• API publikoek, diamanteek bezala, betiko irauten dute. Eman dena: ez da inoiz izango dena ondo egiteko beste aukerarik.
• APIaren eskemak laburrak izan behar dira — Orrialde bat klase eta metodoen sinadurak eta deskribapenak dituena, lerro bat baino gehiago hartzen duena. Horri esker, APIa erraz berregituratuko duzu lehen aldiz perfektua ateratzen ez bada.
• Erabilera kasuak deskribatzeaAPIa inplementatu baino lehen edo bere zehaztapenetan lan egin aurretik. Horrela guztiz funtzionala ez den API bat ezartzea eta zehaztea saihestuko duzu.

Gidoi artifizial batekin sinopsi labur bat ere idatzi izan banu, ziurrenik errorea identifikatu eta zuzenduko nuke. Hala ez bada, nire lankide batek egingo luke zalantzarik gabe. Ondorio zabalak dituen edozein erabaki gutxienez egun batez pentsatu behar da (hori ez da soilik programazioari aplikatzen).

Richard Gabrielen saiakeraren izenburuak, "Worrse Is Better", merkatuan lehena izateak dakarren abantailari egiten dio erreferentzia —nahiz eta produktu inperfektu batekin— beste norbait perfektuaren atzetik eternitate bat igarotzen duen bitartean. Sprite kodeari buruz hausnartuz, konturatzen naiz ez nuela kode gehiago idatzi behar ondo ateratzeko. Norbaitek esan dezakeen guztia ere, oso oker nengoen.

Ondorioa

Programatzaileek egunero akatsak egiten dituzte, akatsen kodea idazten edo haien trebetasuna eta produktibitatea hobetuko dituen zerbait probatu nahi ez izan. Noski, programatzaile izan zaitezke nik egin nuen bezain akats larririk egin gabe. Baina ezinezkoa da programatzaile on bihurtzea zure akatsak ezagutu eta haietatik ikasi gabe.

Etengabe topatzen ditut akats gehiegi egiten dituztela eta, beraz, programaziorako prestatuta ez dauden ikasleekin. Badakit nola ohikoa den inpostorearen sindromea informatikan. Zerrendatu ditudan ikasgaiak ikasiko dituzula espero dut - baina gogoratu nagusia: gutako bakoitzak akatsak egiten ditugu - lotsagarriak, dibertigarriak, izugarriak. Harrituta eta atsekabetuta geratuko naiz etorkizunean artikuluarekin jarraitzeko adina material ez badut.

Iturria: www.habr.com