Eins og þeir segja, ef þú skammast þín ekki fyrir gamla kóðann þinn, þá ertu ekki að vaxa sem forritari - og ég er sammála þessari skoðun. Ég byrjaði að forrita mér til skemmtunar fyrir meira en 40 árum síðan og í atvinnumennsku fyrir 30 árum síðan, þannig að ég á mikið af mistökum. mikið af. Sem tölvunarfræðiprófessor kenni ég nemendum mínum að læra af mistökum – þeirra, mínum og annarra. Ég held að það sé kominn tími til að tala um mistök mín til að missa ekki hógværð. Ég vona að þeir muni nýtast einhverjum.

Þriðja sæti - Microsoft C þýðandi

Skólakennarinn minn taldi að Rómeó og Júlía gætu ekki talist harmleikur vegna þess að persónurnar hefðu enga hörmulega sektarkennd - þær hegðuðu sér einfaldlega heimskulega, eins og unglingar ættu að gera. Ég var ekki sammála honum þá, en núna sé ég skynsemiskorn að hans mati, sérstaklega í sambandi við forritun.

Þegar ég lauk öðru ári í MIT var ég ungur og óreyndur, bæði í lífi og forritun. Í sumar stundaði ég starfsnám hjá Microsoft, í C þýðandateyminu. Fyrst gerði ég venjulega hluti eins og stuðning við prófíla og síðan var mér falið að vinna að skemmtilegasta hluta þýðandans (eins og ég hélt) - fínstillingu bakenda. Sérstaklega þurfti ég að bæta x86 kóðann fyrir greinaryfirlýsingar.

Ég var staðráðinn í að skrifa ákjósanlegasta vélkóðann fyrir hvert mögulegt tilvik og henti mér í laugina. Ef dreifingarþéttleiki gilda var mikill, fór ég inn í þau umskiptatöflu. Ef þeir áttu sameiginlegan deili, notaði ég hann til að gera borðið þéttara (en aðeins ef skiptingin var hægt að gera með því að nota bitaskipti). Þegar öll gildin voru völd tveggja, gerði ég aðra hagræðingu. Ef sett af gildum uppfyllti ekki skilyrði mín skipti ég því í nokkur hagræðanleg tilvik og notaði þegar fínstilltan kóða.

Þetta var martröð. Mörgum árum síðar var mér sagt að forritarinn sem erfði kóðann minn hataði mig.

Lexía lærð

Eins og David Patterson og John Hennessy skrifa í tölvuarkitektúr og tölvukerfahönnun er ein meginregla arkitektúrs og hönnunar að láta hlutina virka eins fljótt og auðið er.

Að flýta fyrir algengum tilfellum mun bæta árangur á skilvirkari hátt en að fínstilla sjaldgæf tilvik. Það er kaldhæðnislegt að algeng tilvik eru oft einfaldari en sjaldgæf. Þetta rökrétta ráð gerir ráð fyrir að þú vitir hvaða tilfelli er talið algengt - og þetta er aðeins mögulegt með því að fara vandlega að prófa og mæla.

Mér til varnar reyndi ég að átta mig á því hvernig greinaryfirlýsingar litu út í reynd (svo sem hversu margar greinar voru og hvernig fastar dreifðust), en árið 1988 lágu þessar upplýsingar ekki fyrir. Hins vegar hefði ég ekki átt að bæta við sérstökum tilvikum þegar núverandi þýðandinn gat ekki búið til ákjósanlegan kóða fyrir gervi dæmið sem ég kom með.

Ég þurfti að hringja í reyndan þróunaraðila og, ásamt honum, velta fyrir mér hver algengu tilvikin væru og taka á þeim sérstaklega. Ég myndi skrifa minna kóða, en það er gott. Eins og Jeff Atwood, stofnandi Stack Overflow skrifaði, er versti óvinur forritara forritarinn sjálfur:

Ég veit að þú hefur bestu fyrirætlanir eins og við öll. Við búum til forrit og elskum að skrifa kóða. Þannig erum við gerð. Við teljum að hægt sé að leysa hvaða vandamál sem er með límbandi, heimagerðri hækju og smá kóða. Eins mikið og það er sársaukafullt fyrir kóðara að viðurkenna það, besti kóðinn er kóðinn sem er ekki til. Hver ný lína þarf kembiforrit og stuðning, það þarf að skilja það. Þegar þú bætir við nýjum kóða ættirðu að gera það með tregðu og viðbjóði vegna þess að allir aðrir möguleikar hafa verið uppurnir. Margir forritarar skrifa of mikinn kóða, sem gerir hann að óvini okkar.

Ef ég hefði skrifað einfaldari kóða sem náði yfir algeng tilvik hefði verið miklu auðveldara að uppfæra ef þörf krefur. Ég skildi eftir mig óreiðu sem enginn vildi takast á við.

Í öðru sæti: auglýsingar á samfélagsnetum

Þegar ég var að vinna hjá Google við auglýsingar á samfélagsmiðlum (manstu eftir Myspace?), skrifaði ég eitthvað á þessa leið í 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)) {
  }
}

Forritarar gætu strax séð villuna: síðustu rökin ættu að vera j, ekki i. Einingapróf leiddi ekki í ljós villuna og það gerði gagnrýnandi minn ekki heldur. Ræsingin var framkvæmd og eitt kvöldið fór kóðinn minn á netþjóninn og hrundi öllum tölvum í gagnaverinu.

Ekkert slæmt gerðist. Ekkert bilaði fyrir neinn, því fyrir alþjóðlegt ræsingu var kóðinn prófaður í einu gagnaveri. Nema SRE verkfræðingar hættu að spila billjard í smá tíma og gerðu smá rollback. Morguninn eftir fékk ég tölvupóst með hrundumpi, leiðrétti kóðann og bætti við einingaprófum sem myndu ná villunni. Þar sem ég fylgdi siðareglunum - annars myndi kóðann minn einfaldlega ekki keyra - voru engin önnur vandamál.

Lexía lærð

Margir eru vissir um að svo mikil mistök muni örugglega kosta sökudólginn uppsögn, en svo er ekki: Í fyrsta lagi gera allir forritarar mistök og í öðru lagi gera þeir sjaldan sömu mistökin tvisvar.

Reyndar á ég forritaravin sem var frábær verkfræðingur og var rekinn fyrir að gera ein mistök. Eftir það var hann ráðinn til Google (og fljótlega settur upp) - hann talaði heiðarlega um mistökin sem hann gerði í viðtali og þau voru ekki talin banvæn.

Þetta er hvað segja um Thomas Watson, hinn goðsagnakennda yfirmann IBM:

Tilkynnt var um pöntun stjórnvalda að verðmæti um milljón dollara. IBM Corporation - eða réttara sagt, Thomas Watson eldri persónulega - vildi endilega fá það. Því miður gat sölufulltrúinn ekki gert þetta og IBM tapaði tilboðinu. Daginn eftir kom þessi starfsmaður inn á skrifstofu Herra Watsons og lagði umslag á borðið hans. Herra Watson nennti ekki einu sinni að skoða það - hann beið eftir starfsmanni og vissi að þetta var uppsagnarbréf.

Watson spurði hvað hefði farið úrskeiðis.

Sölufulltrúi ræddi ítarlega um gang útboðsins. Hann nefndi mistök sem hefðu verið hægt að forðast. Að lokum sagði hann: „Herra Watson, takk fyrir að leyfa mér að útskýra. Ég veit hversu mikið við þurftum þessa pöntun. Ég veit hversu mikilvægur hann var,“ og bjó sig undir að fara.

Watson gekk að honum við dyrnar, horfði í augu hans og skilaði umslaginu með orðunum: „Hvernig get ég sleppt þér? Ég fjárfesti bara milljón dollara í menntun þína.

Ég á stuttermabol sem segir: "Ef þú lærir virkilega af mistökum, þá er ég nú þegar meistari." Reyndar, þegar kemur að villum, er ég doktor í vísindum.

Fyrsta sæti: App Inventor API

Sannarlega hræðilegar villur hafa áhrif á gríðarlegan fjölda notenda, verða opinberar, taka langan tíma að leiðrétta og eru gerðar af þeim sem hefðu ekki getað gert þær. Stærstu mistökin mín passa við öll þessi skilyrði.

Því verra því betra

ég les ritgerð eftir Richard Gabriel um þessa nálgun á tíunda áratugnum sem framhaldsnemi og mér líkar það svo vel að ég spyr nemendur mína um það. Ef þú manst það ekki vel, endurnærðu minnið, það er lítið. Þessi ritgerð stangast á við löngunina til að „fá það rétt“ og „verra er betra“ nálgunin á margan hátt, þar á meðal einfaldleika.

Hvernig það ætti að vera: hönnunin ætti að vera einföld í útfærslu og viðmóti. Einfaldleiki viðmótsins er mikilvægari en einfaldleiki í útfærslu.

Því verra, því betra: hönnunin ætti að vera einföld í útfærslu og viðmóti. Einfaldleiki útfærslu er mikilvægari en einfaldleiki viðmótsins.

Gleymum því í eina mínútu. Því miður gleymdi ég því í mörg ár.

App uppfinningamaður

Þegar ég vann hjá Google var ég hluti af teyminu App uppfinningamaður, drag-and-drop þróunarumhverfi á netinu fyrir upprennandi Android forritara. Það var árið 2009 og við vorum að flýta okkur að gefa út alfa útgáfuna í tæka tíð svo að á sumrin gætum við haldið meistaranámskeið fyrir kennara sem gætu notað umhverfið við kennslu á haustin. Ég bauðst til að innleiða sprites, nostalgíska fyrir hvernig ég var vanur að skrifa leiki á TI-99/4. Fyrir þá sem ekki vita er sprite tvívíður grafískur hlutur sem getur hreyft sig og haft samskipti við aðra hugbúnaðarþætti. Dæmi um sprites eru geimskip, smástirni, marmara og spaðar.

Við innleiddum hlutbundinn App Inventor í Java, þannig að það er bara fullt af hlutum þarna inni. Þar sem kúlur og sprites hegða sér mjög svipað, bjó ég til abstrakt sprite flokk með eiginleikum (reitum) X, Y, Speed ​​​​(hraði) og Heading (stefna). Þeir höfðu sömu aðferðir til að greina árekstra, skoppa af brún skjásins o.s.frv.

Helsti munurinn á bolta og sprite er hvað nákvæmlega er teiknað - fylltur hringur eða raster. Þar sem ég útfærði sprites fyrst var rökrétt að tilgreina x- og y-hnit efra vinstra hornsins þar sem myndin var staðsett.

Þegar sprites voru að vinna ákvað ég að ég gæti útfært kúluhluti með mjög litlum kóða. Eina vandamálið var að ég fór einföldustu leiðina (frá sjónarhóli framkvæmdaraðilans) og sýndi x- og y-hnit efra vinstra hornsins á útlínunni sem rammar inn boltann.

Reyndar var nauðsynlegt að gefa til kynna x- og y-hnit miðpunkts hringsins, eins og kennd er í hvaða stærðfræðikennslubók sem er og hvers kyns önnur heimild sem nefnir hringi.

Ólíkt fyrri mistökum mínum hafði þetta ekki aðeins áhrif á samstarfsmenn mína, heldur einnig milljónir App Inventor notenda. Mörg þeirra voru börn eða alveg ný í forritun. Þeir þurftu að framkvæma fullt af óþarfa skrefum þegar unnið var að hverju forriti þar sem boltinn var til staðar. Ef ég man eftir öðrum mistökum mínum með hlátri, þá svitnar þessi enn í dag.

Ég lagaði loksins þennan galla aðeins nýlega, tíu árum síðar. „Patched“, ekki „fixed“, því eins og Joshua Bloch segir, API eru eilíf. Ekki tókst að gera breytingar sem myndu hafa áhrif á núverandi forrit, við bættum við OriginAtCenter eigninni með gildinu falskt í gömlum forritum og satt í öllum framtíðarforritum. Notendur gætu spurt rökréttrar spurningar: hverjum datt í hug að setja upphafspunktinn annars staðar en miðjuna. Til hvers? Til eins forritara sem var of latur til að búa til venjulegt API fyrir tíu árum.

Lexía lærð

Þegar þú vinnur að API (sem nánast allir forritarar þurfa að gera stundum), ættir þú að fylgja bestu ráðunum sem lýst er í myndbandi Joshua Bloch "Hvernig á að búa til gott API og hvers vegna það er svo mikilvægt“eða í þessum stutta lista:

• API getur fært þér bæði mikinn ávinning og mikinn skaða.. Gott API skapar endurtekna viðskiptavini. Sá vondi verður að eilífu martröð þinni.
• Opinber API, eins og demantar, endast að eilífu. Gefðu þér allt: það verður aldrei annað tækifæri til að gera allt rétt.
• API útlínur ættu að vera stuttar — ein síða með flokka- og aðferðamerkjum og lýsingum, sem tekur ekki meira en eina línu. Þetta gerir þér kleift að endurskipuleggja API auðveldlega ef það reynist ekki fullkomið í fyrsta skipti.
• Lýstu notkunartilvikumáður en þú innleiðir API eða jafnvel vinnur að forskrift þess. Þannig muntu forðast að innleiða og tilgreina algjörlega óvirkt API.

Ef ég hefði skrifað jafnvel stutt yfirlit með gervihandriti, hefði ég líklegast borið kennsl á villuna og leiðrétt hana. Ef ekki, þá myndi einn af samstarfsmönnum mínum örugglega gera það. Allar ákvarðanir sem hafa víðtækar afleiðingar þarf að hugsa í að minnsta kosti einn dag (þetta á ekki aðeins við um forritun).

Titill ritgerðar Richards Gabriels, „Verra er betra,“ vísar til þess kosts sem felst í því að vera fyrstur á markað – jafnvel með ófullkomna vöru – á meðan einhver annar eyðir eilífð í að elta hina fullkomnu. Þegar ég velti fyrir mér sprite kóðanum geri ég mér grein fyrir því að ég þurfti ekki einu sinni að skrifa fleiri kóða til að fá hann rétt. Hvað sem maður segir, þá skjátlaðist mér stórlega.

Ályktun

Forritarar gera mistök á hverjum degi, hvort sem það er að skrifa gallakóða eða vilja ekki prófa eitthvað sem mun bæta færni þeirra og framleiðni. Auðvitað geturðu verið forritari án þess að gera svona alvarleg mistök og ég. En það er ómögulegt að verða góður forritari án þess að viðurkenna mistök þín og læra af þeim.

Ég lendi stöðugt í nemendum sem finnst þeir gera of mikið af mistökum og eru þar af leiðandi ekki skornir í forritun. Ég veit hversu algengt blekkingarheilkenni er í upplýsingatækni. Ég vona að þú lærir lexíuna sem ég hef talið upp - en mundu það helsta: hvert og eitt okkar gerir mistök - vandræðaleg, fyndin, hræðileg. Ég verð hissa og í uppnámi ef ég hef ekki nóg efni í framtíðinni til að halda greininni áfram.

Heimild: www.habr.com