Kiel oni diras, se vi ne hontas pri via malnova kodo, tiam vi ne kreskas kiel programisto - kaj mi konsentas kun ĉi tiu opinio. Mi komencis programi por amuzo antaŭ pli ol 40 jaroj, kaj profesie antaŭ 30 jaroj, do mi havas multajn erarojn. tre multe. Kiel komputika profesoro, mi instruas miajn studentojn lerni de eraroj—iliaj, miaj kaj aliaj. Mi pensas, ke estas tempo paroli pri miaj eraroj por ne perdi mian modestecon. Mi esperas, ke ili estos utilaj al iu.

Tria loko - Microsoft C-kompililo

Mia lerneja instruisto kredis, ke Romeo kaj Julieta ne povas esti konsiderataj kiel tragedio, ĉar la roluloj ne havis tragikan kulpon – ili simple kondutis stulte, kiel devus adoleskantoj. Mi tiam ne konsentis kun li, sed nun mi vidas grajnon de racieco laŭ lia opinio, precipe rilate al programado.

Kiam mi finis mian duan jaron ĉe MIT, mi estis juna kaj nesperta, kaj en vivo kaj en programado. Somere mi internigis ĉe Mikrosofto, en la teamo de kompililo C. Komence mi faris rutinajn aferojn kiel profilado de subteno, kaj poste mi estis konfidita labori pri la plej amuza parto de la kompililo (kiel mi pensis) - backend-optimumigo. Aparte, mi devis plibonigi la x86-kodon por branĉaj deklaroj.

Decidite skribi la optimuman maŝinkodon por ĉiu ebla kazo, mi ĵetis min en la naĝejon kapantaŭen. Se la distribua denseco de valoroj estis alta, mi enigis ilin transirtabelo. Se ili havis komunan dividon, mi uzis ĝin por igi la tabelon pli strikta (sed nur se la divido povus esti farita uzante bita movo). Kiam ĉiuj valoroj estis potencoj de du, mi faris alian optimumigon. Se aro da valoroj ne kontentigis miajn kondiĉojn, mi dividis ĝin en plurajn optimumeblajn kazojn kaj uzis la jam optimumigitan kodon.

Estis koŝmaro. Multajn jarojn poste oni diris al mi, ke la programisto, kiu heredis mian kodon, malamas min.

Leciono lernita

Kiel David Patterson kaj John Hennessy skribas en Komputila Arkitekturo kaj Komputila Sistemo-Dezajno, unu el la ĉefaj principoj de arkitekturo kaj dezajno estas ĝenerale igi aferojn funkcii kiel eble plej rapide.

Akceli oftajn kazojn plibonigos rendimenton pli efike ol optimumigi maloftajn kazojn. Ironie, oftaj kazoj ofte estas pli simplaj ol maloftaj. Ĉi tiu logika konsilo supozas, ke vi scias, kiu kazo estas konsiderata ofta - kaj tio eblas nur per procezo de zorga testado kaj mezurado.

En mia defendo, mi provis eltrovi kiel branĉaj deklaroj aspektis en la praktiko (kiel kiom da branĉoj estis kaj kiel konstantoj estis distribuitaj), sed en 1988 ĉi tiu informo ne estis havebla. Tamen, mi ne devus esti aldoninta specialajn kazojn kiam ajn la nuna kompililo ne povis generi optimuman kodon por la artefarita ekzemplo, kiun mi elpensis.

Mi devis voki spertan programiston kaj, kune kun li, pensi pri kio estas la oftaj kazoj kaj trakti ilin specife. Mi skribus malpli da kodo, sed tio estas bona afero. Kiel skribis la fondinto de Stack Overflow Jeff Atwood, la plej malbona malamiko de programisto estas la programisto mem:

Mi scias, ke vi havas la plej bonajn intencojn, same kiel ni ĉiuj. Ni kreas programojn kaj amas skribi kodon. Tiel ni estas faritaj. Ni pensas, ke ajna problemo povas esti solvita per glubendo, memfarita lambastono kaj pinĉo da kodo. Kiom ajn dolorigas kodistojn konfesi ĝin, la plej bona kodo estas la kodo, kiu ne ekzistas. Ĉiu nova linio bezonas elpurigon kaj subtenon, ĝi devas esti komprenata. Kiam vi aldonas novan kodon, vi faru tion kun malemo kaj abomeno ĉar ĉiuj aliaj elektoj estas elĉerpitaj. Multaj programistoj skribas tro da kodo, igante ĝin nia malamiko.

Se mi estus skribinta pli simplan kodon kiu kovris oftajn kazojn, estus multe pli facile ĝisdatigi se necese. Mi postlasis ĥaoson, kiun neniu volis trakti.

Dua loko: reklamado en sociaj retoj

Kiam mi laboris ĉe Google pri reklamado pri sociaj amaskomunikiloj (memoru Myspace?), mi skribis ion tian en 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)) {
  }
}

Programistoj povas tuj vidi la eraron: la lasta argumento estu j, ne i. Unutestado ne malkaŝis la eraron, kaj ankaŭ mia recenzisto. La lanĉo estis efektivigita, kaj unu nokton mia kodo iris al la servilo kaj kraŝis ĉiujn komputilojn en la datumcentro.

Nenio malbona okazis. Nenio rompiĝis por iu ajn, ĉar antaŭ la tutmonda lanĉo la kodo estis provita ene de unu datumcentro. Krom se la inĝenieroj de SRE ne ĉesis ludi bilardon dum iom da tempo kaj faris iom da retroiro. La sekvan matenon mi ricevis retmesaĝon kun kraŝ-dump, korektis la kodon kaj aldonis unutestojn, kiuj kaptus la eraron. Ĉar mi sekvis la protokolon - alie mia kodo simple malsukcesus ruliĝi - ne estis aliaj problemoj.

Leciono lernita

Multaj certas, ke tia grava eraro certe kostos la kulpan maldungon, sed ĉi tio ne estas tiel: unue, ĉiuj programistoj faras erarojn, kaj due, ili malofte faras la saman eraron dufoje.

Fakte, mi havas programistamikon, kiu estis genia inĝeniero kaj estis maldungita pro unu eraro. Post tio, li estis dungita ĉe Guglo (kaj baldaŭ promociita) - li honeste parolis pri la eraro, kiun li faris en intervjuo, kaj ĝi ne estis konsiderata fatala.

Jen kio rakontu pri Thomas Watson, la legenda estro de IBM:

Registara ordono kun valoro de ĉirkaŭ miliono da dolaroj estis anoncita. IBM Corporation - aŭ pli ĝuste, Thomas Watson Sr. persone - vere volis akiri ĝin. Bedaŭrinde, la venda reprezentanto ne povis fari tion kaj IBM perdis la oferton. La sekvan tagon, tiu ĉi dungito venis en la oficejon de sinjoro Watson kaj metis koverton sur sian skribotablon. Sinjoro Watson eĉ ne ĝenis ĝin rigardi – li atendis dungiton kaj sciis, ke tio estas letero de eksiĝo.

Watson demandis kio misfunkciis.

La venda reprezentanto parolis detale pri la progreso de la oferto. Li nomis erarojn faritajn, kiuj povus esti evititaj. Fine, li diris, “Sinjoro Watson, dankon pro lasi min klarigi. Mi scias kiom ni bezonis ĉi tiun mendon. Mi scias kiom grava li estis,” kaj pretiĝis foriri.

Watson alproksimiĝis al li ĉe la pordo, rigardis lin en la okulojn kaj resendis la koverton kun la vortoj: “Kiel mi povas lasi vin iri? Mi ĵus investis milionon da dolaroj en via edukado.

Mi havas T-ĉemizon kiu diras: "Se vi vere lernas de eraroj, tiam mi jam estas majstro." Fakte, kiam temas pri eraroj, mi estas doktoro pri scienco.

Unua loko: App Inventor API

Vere teruraj eraroj influas grandegan nombron da uzantoj, fariĝas publika scio, bezonas longan tempon por korekti, kaj estas faritaj de tiuj, kiuj ne povus ilin fari. Mia plej granda eraro taŭgas por ĉiuj ĉi tiuj kriterioj.

Ju pli malbona des pli bone

Mi legas eseo de Richard Gabriel pri ĉi tiu aliro en la naŭdekaj kiel diplomiĝa studento, kaj mi tiel ŝatas ĝin, ke mi demandas ĝin al miaj studentoj. Se vi ne bone memoras ĝin, refreŝigu vian memoron, ĝi estas malgranda. Ĉi tiu eseo kontrastas la deziron "ĝustigi" kaj la "pli malbona estas pli bona" ​​aliro en multaj manieroj, inkluzive de simpleco.

Kiel ĝi devus esti: la dezajno devus esti simpla en efektivigo kaj interfaco. Simpleco de la interfaco estas pli grava ol simpleco de efektivigo.

Ju pli malbona, des pli bone: la dezajno devus esti simpla en efektivigo kaj interfaco. Simpleco de efektivigo estas pli grava ol simpleco de la interfaco.

Ni forgesu pri tio dum minuto. Bedaŭrinde, mi forgesis pri ĝi dum multaj jaroj.

Programinventisto

Laborante ĉe Google, mi estis parto de la teamo Programinventisto, tren-kaj-faligi reta evolumedio por aspirantaj Android-programistoj. Estis 2009, kaj ni hastis publikigi la alfa-version ĝustatempe, por ke somere ni povu okazigi majstrajn klasojn por instruistoj, kiuj povus uzi la medion dum la instruado aŭtune. Mi volontulis por efektivigi spritojn, nostalgiajn pri kiel mi kutimis verki ludojn sur la TI-99/4. Por tiuj, kiuj ne scias, sprite estas dudimensia grafika objekto, kiu povas moviĝi kaj interagi kun aliaj softvarelementoj. Ekzemploj de spritoj inkludas kosmoŝipojn, asteroidojn, rulglobetojn, kaj rakedojn.

Ni efektivigis objekt-orientitan App Inventor en Java, do estas nur amaso da objektoj tie. Ĉar pilkoj kaj spritaĵoj kondutas tre simile, mi kreis abstraktan spritklason kun propraĵoj (kampoj) X, Y, Rapido (rapideco) kaj Titolo (direkto). Ili havis la samajn metodojn por detekti koliziojn, resalti de la rando de la ekrano, ktp.

La ĉefa diferenco inter pilko kaj sprite estas tio, kio estas ĝuste desegnita - plenigita cirklo aŭ rastrumo. Ĉar mi unue efektivigis spritojn, estis logike specifi la x- kaj y-koordinatojn de la supra maldekstra angulo de kie la bildo troviĝas.

Post kiam la spritoj funkciis, mi decidis, ke mi povus efektivigi pilkajn objektojn kun tre malmulte da kodo. La nura problemo estis, ke mi prenis la plej simplan vojon (de la vidpunkto de la efektiviginto), indikante la x- kaj y-koordinatojn de la supra maldekstra angulo de la konturo enkadriganta la pilkon.

Fakte, estis necese indiki la x- kaj y-koordinatojn de la centro de la cirklo, kiel instruite en iu matematika lernolibro kaj ajna alia fonto kiu mencias cirklojn.

Male al miaj pasintaj eraroj, ĉi tiu influis ne nur miajn kolegojn, sed ankaŭ milionojn da uzantoj de App Inventor. Multaj el ili estis infanoj aŭ tute novaj pri programado. Ili devis plenumi multajn nenecesajn paŝojn kiam ili laboras pri ĉiu aplikaĵo, en kiu ĉeestis la pilko. Se mi memoras miajn aliajn erarojn kun ridado, tiam ĉi tiu ŝvigas min eĉ hodiaŭ.

Mi finfine flikis ĉi tiun cimon nur lastatempe, dek jarojn poste. "Flikitaj", ne "fiksitaj", ĉar kiel diras Joshua Bloch, APIoj estas eternaj. Ne povante fari ŝanĝojn, kiuj influus ekzistantajn programojn, ni aldonis la posedaĵon OriginAtCenter kun la valoro malvera en malnovaj programoj kaj vera en ĉiuj estontaj. Uzantoj povas fari logikan demandon: kiu eĉ pensis meti la deirpunkton ien alian ol la centron. Al kiu? Al unu programisto, kiu estis tro maldiligenta por krei normalan API antaŭ dek jaroj.

Lecionoj lernitaj

Kiam vi laboras pri API-oj (kion preskaŭ ĉiu programisto devas fari foje), vi devus sekvi la plej bonajn konsilojn skizitajn en la video de Joshua Bloch "Kiel krei bonan API kaj kial ĝi estas tiel grava"aŭ en ĉi tiu mallonga listo:

• API povas alporti al vi kaj grandan utilon kaj grandan damaĝon.. Bona API kreas ripetajn klientojn. La malbona fariĝas via eterna koŝmaro.
• Publikaj APIoj, kiel diamantoj, daŭras eterne. Donu ĉion: neniam estos alia ŝanco fari ĉion ĝuste.
• API-skizoj devus esti mallongaj — unu paĝo kun klasaj kaj metodoj subskriboj kaj priskriboj, okupante ne pli ol linion. Ĉi tio permesos al vi facile restrukturi la API se ĝi ne rezultas perfekta la unuan fojon.
• Priskribu uzkazojnantaŭ efektivigi la API aŭ eĉ labori pri ĝia specifo. Tiel vi evitos efektivigi kaj specifi tute nefunkcian API.

Se mi estus verkinta eĉ mallongan sinoptikon per artefarita skribo, plej verŝajne mi estus identiginta la eraron kaj korektus ĝin. Se ne, tiam unu el miaj kolegoj certe farus ĝin. Ĉiu decido, kiu havas ampleksajn sekvojn, devas esti pripensita almenaŭ unu tagon (ĉi tio validas ne nur por programado).

La titolo de la eseo de Richard Gabriel, "Worrse Is Better", rilatas al la avantaĝo kiu iras al esti unua surmerkatigi - eĉ kun neperfekta produkto - dum iu alia pasigas eternecon postkurante la perfektan. Pripensante la sprite-kodon, mi rimarkas, ke mi eĉ ne devis skribi pli da kodo por ĝin ĝuste. Kion ajn oni povas diri, mi ege eraris.

konkludo

Programistoj faras erarojn ĉiutage, ĉu ĝi skribas bugan kodon aŭ ne volas provi ion, kio plibonigos ilian kapablon kaj produktivecon. Kompreneble, vi povas esti programisto sen fari tiajn gravajn erarojn kiel mi. Sed estas neeble fariĝi bona programisto sen rekoni viajn erarojn kaj lerni de ili.

Mi konstante renkontas studentojn, kiuj sentas, ke ili faras tro da eraroj kaj tial ne estas ellaboritaj por programado. Mi scias, kiom ofta trompsindromo estas en IT. Mi esperas, ke vi lernos la lecionojn, kiujn mi listigis – sed memoru la ĉefan: ĉiu el ni faras erarojn – embarasajn, amuzajn, terurajn. Mi estos surprizita kaj ĉagrenita, se estonte mi ne havos sufiĉe da materialo por daŭrigi la artikolon.

fonto: www.habr.com