Kuten he sanovat, jos et häpeä vanhaa koodiasi, et kasva ohjelmoijana - ja olen samaa mieltä tästä mielipiteestä. Aloitin ohjelmoinnin huvikseni yli 40 vuotta sitten ja ammattimaisesti 30 vuotta sitten, joten minulla on paljon virheitä. hyvin paljon. Tietojenkäsittelytieteen professorina opetan oppilaitani oppimaan virheistä – heidän, minun ja muiden virheistä. Mielestäni on aika puhua virheistäni, jotta en menetä vaatimattomuuttani. Toivottavasti niistä on jollekin hyötyä.

Kolmas sija - Microsoft C -kääntäjä

Kouluni opettaja uskoi, että Romeoa ja Juliaa ei voitu pitää tragediana, koska hahmoilla ei ollut traagista syyllisyyttä - he vain käyttäytyivät typerästi, kuten teini-ikäisten kuuluukin. En ollut hänen kanssaan silloin samaa mieltä, mutta nyt näen hänen mielipiteessään rationaalisuutta, varsinkin ohjelmoinnin yhteydessä.

Kun lopetin toisen vuoden MIT:ssä, olin nuori ja kokematon sekä elämässä että ohjelmoinnissa. Kesällä työskentelin Microsoftilla C-kääntäjätiimissä. Aluksi tein rutiininomaisia ​​asioita, kuten profilointitukea, ja sitten minulle uskottiin kääntäjän hauskin osa (kuten ajattelin) - backend-optimointi. Erityisesti minun piti parantaa haaralausekkeiden x86-koodia.

Päättänyt kirjoittaa optimaalisen konekoodin jokaiseen mahdolliseen tapaukseen, joten heittäydyin uima-altaaseen. Jos arvojen jakautumistiheys oli korkea, syötin ne siirtymätaulukko. Jos niillä oli yhteinen jakaja, käytin sitä tiukentamaan pöytää (mutta vain jos jako voidaan tehdä käyttämällä bitin muutos). Kun kaikki arvot olivat kahden potenssit, tein toisen optimoinnin. Jos arvojoukko ei täyttänyt ehtojani, jaoin sen useisiin optimoitaviin tapauksiin ja käytin jo optimoitua koodia.

Se oli painajainen. Monta vuotta myöhemmin minulle kerrottiin, että ohjelmoija, joka peri koodini, vihasi minua.

Läksy opittu

Kuten David Patterson ja John Hennessy kirjoittavat artikkelissa Computer Architecture and Computer Systems Design, yksi arkkitehtuurin ja suunnittelun pääperiaatteista on saada asiat toimimaan mahdollisimman nopeasti.

Yleisten tapausten nopeuttaminen parantaa suorituskykyä tehokkaammin kuin harvinaisten tapausten optimointi. Ironista kyllä, yleiset tapaukset ovat usein yksinkertaisempia kuin harvinaiset. Tämä looginen neuvo olettaa, että tiedät, mikä tapaus katsotaan yleiseksi – ja tämä on mahdollista vain huolellisen testauksen ja mittauksen avulla.

Puolustukseksi yritin selvittää, miltä haaralausekkeet näyttivät käytännössä (kuten kuinka monta haaraa oli ja kuinka vakiot jakautuivat), mutta vuonna 1988 tätä tietoa ei ollut saatavilla. Minun ei kuitenkaan olisi pitänyt lisätä erikoistapauksia aina, kun nykyinen kääntäjä ei pystynyt luomaan optimaalista koodia keksimääni keinotekoiseen esimerkkiin.

Minun piti soittaa kokeneelle kehittäjälle ja miettiä yhdessä hänen kanssaan yleisiä tapauksia ja käsitellä niitä erityisesti. Kirjoittaisin vähemmän koodia, mutta se on hyvä asia. Kuten Stack Overflown perustaja Jeff Atwood kirjoitti, ohjelmoijan pahin vihollinen on ohjelmoija itse:

Tiedän, että sinulla on parhaat aikomukset, kuten meillä kaikilla. Luomme ohjelmia ja rakastamme koodin kirjoittamista. Näin meidät on tehty. Uskomme, että kaikki ongelmat voidaan ratkaista ilmateipillä, kotitekoisella kainalosauvalla ja ripaus koodia. Niin paljon kuin koodaajille sen myöntäminen tekeekin tuskaa, paras koodi on se koodi, jota ei ole olemassa. Jokainen uusi rivi tarvitsee virheenkorjausta ja tukea, se on ymmärrettävä. Kun lisäät uutta koodia, sinun tulee tehdä se vastahakoisesti ja inhottavasti, koska kaikki muut vaihtoehdot on käytetty loppuun. Monet ohjelmoijat kirjoittavat liikaa koodia, mikä tekee siitä vihollisemme.

Jos olisin kirjoittanut yksinkertaisemman koodin, joka kattaisi yleiset tapaukset, se olisi ollut paljon helpompi päivittää tarvittaessa. Jätin taakseni sotkun, jota kukaan ei halunnut käsitellä.

Toinen paikka: mainonta sosiaalisissa verkostoissa

Kun työskentelin Googlella sosiaalisen median mainonnan parissa (muistatko Myspacen?), kirjoitin jotain tällaista C++:ssa:

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

Ohjelmoijat voivat nähdä virheen välittömästi: viimeisen argumentin tulee olla j, ei i. Yksikkötestaus ei paljastanut virhettä, eikä myöskään arvioijani. Käynnistys suoritettiin, ja eräänä yönä koodini meni palvelimelle ja kaatui kaikki palvelinkeskuksen tietokoneet.

Mitään pahaa ei tapahtunut. Mikään ei mennyt rikki kenellekään, koska ennen maailmanlaajuista julkaisua koodi testattiin yhdessä palvelinkeskuksessa. Elleivät SRE:n insinöörit lopettaneet biljardin pelaamista joksikin aikaa ja tehneet vähän taaksepäin. Seuraavana aamuna sain sähköpostin kaatumisesta, korjasin koodin ja lisäsin yksikkötestejä, jotka havaitsivat virheen. Koska noudatin protokollaa - muuten koodini ei yksinkertaisesti toimisi - muita ongelmia ei ollut.

Läksy opittu

Monet ovat varmoja, että tällainen suuri virhe varmasti maksaa syyllisen irtisanomisen, mutta näin ei ole: ensinnäkin kaikki ohjelmoijat tekevät virheitä, ja toiseksi he tekevät harvoin saman virheen kahdesti.

Itse asiassa minulla on ohjelmoijaystävä, joka oli loistava insinööri ja hänet erotettiin yhden virheen vuoksi. Sen jälkeen hänet palkattiin Googlelle (ja pian ylennettiin) - hän puhui rehellisesti haastattelussa tekemästään virheestä, eikä sitä pidetty kohtalokkaana.

Tässä on mitä kertoa Thomas Watsonista, IBM:n legendaarisesta johtajasta:

Julkistettiin hallituksen noin miljoonan dollarin tilaus. IBM Corporation - tai pikemminkin Thomas Watson Sr. henkilökohtaisesti - halusi todella saada sen. Valitettavasti myyntiedustaja ei pystynyt tekemään tätä ja IBM hävisi tarjouksen. Seuraavana päivänä tämä työntekijä tuli herra Watsonin toimistoon ja asetti kirjekuoren hänen pöydälleen. Mr. Watson ei edes vaivautunut katsomaan sitä - hän odotti työntekijää ja tiesi, että se oli erokirje.

Watson kysyi, mikä meni pieleen.

Myyjä kertoi yksityiskohtaisesti tarjouskilpailun etenemisestä. Hän nimesi tehdyt virheet, jotka olisi voitu välttää. Lopulta hän sanoi: "Herra Watson, kiitos, että annoitte minun selittää. Tiedän kuinka paljon tarvitsimme tätä tilausta. Tiedän kuinka tärkeä hän oli”, ja valmistautui lähtemään.

Watson lähestyi häntä ovella, katsoi häntä silmiin ja palautti kirjekuoren, jossa oli sanat: "Kuinka voin päästää sinut menemään? Investoin juuri miljoona dollaria koulutukseesi.

Minulla on T-paita, jossa lukee: "Jos todella oppii virheistä, olen jo mestari." Itse asiassa, mitä tulee virheisiin, olen tieteiden tohtori.

Ensimmäinen paikka: App Inventor API

Todella hirvittävät virheet vaikuttavat valtavaan määrään käyttäjiä, tulevat julkisiksi, niiden korjaaminen kestää kauan, ja niitä tekevät ne, jotka eivät olisi voineet tehdä niitä. Suurin virheeni sopii kaikkiin näihin kriteereihin.

Mitä huonompi sen parempi

luen Richard Gabrielin essee tästä lähestymistavasta XNUMX-luvulla jatko-opiskelijana, ja pidän siitä niin paljon, että kysyn sitä opiskelijoiltani. Jos et muista sitä hyvin, virkistä muistisi, se on pieni. Tämä essee asettaa vastakkain halun "saada se oikein" ja "huonompi on parempi" -lähestymistapaan monin tavoin, mukaan lukien yksinkertaisuus.

Miten sen pitäisi olla: suunnittelun tulee olla yksinkertainen toteutuksen ja käyttöliittymän suhteen. Käyttöliittymän yksinkertaisuus on tärkeämpää kuin toteutuksen yksinkertaisuus.

Mitä huonompi, sitä parempi: suunnittelun tulee olla yksinkertainen toteutuksen ja käyttöliittymän osalta. Toteutuksen yksinkertaisuus on tärkeämpää kuin käyttöliittymän yksinkertaisuus.

Unohdetaan se hetkeksi. Valitettavasti unohdin sen moneksi vuodeksi.

Sovellusten keksijä

Työskennellessäni Googlella olin osa tiimiä Sovellusten keksijä, vedä ja pudota verkkokehitysympäristö aloitteleville Android-kehittäjille. Elettiin vuotta 2009, ja meillä oli kiire julkaista alfaversio ajoissa, jotta kesällä voisimme järjestää mestarikursseja opettajille, jotka voisivat käyttää ympäristöä opettaessaan syksyllä. Ilmoittauduin vapaaehtoiseksi toteuttamaan spriteja, nostalgisena siitä, miten kirjoitin pelejä TI-99/4:llä. Niille, jotka eivät tiedä, sprite on kaksiulotteinen graafinen objekti, joka voi liikkua ja olla vuorovaikutuksessa muiden ohjelmistoelementtien kanssa. Esimerkkejä spriteistä ovat avaruusalukset, asteroidit, marmorit ja mailat.

Otimme oliopohjaisen App Inventorin Javassa, joten siellä on vain joukko objekteja. Koska pallot ja spritet käyttäytyvät hyvin samalla tavalla, loin abstraktin sprite-luokan ominaisuuksilla (kentät) X, Y, Speed ​​​​(nopeus) ja Heading (suunta). Heillä oli samat menetelmät törmäysten havaitsemiseen, näytön reunasta pomppimiseen jne.

Suurin ero pallon ja spriten välillä on se, mikä tarkalleen piirretään - täytetty ympyrä vai rasteri. Koska toteutin spritet ensin, oli loogista määrittää kuvan sijaintipaikan vasemman yläkulman x- ja y-koordinaatit.

Kun spritet toimivat, päätin, että voisin toteuttaa palloobjekteja hyvin pienellä koodilla. Ainoa ongelma oli se, että valitsin yksinkertaisimman reitin (toteuttajan näkökulmasta), osoitin palloa kehystävän ääriviivan vasemman yläkulman x- ja y-koordinaatit.

Itse asiassa piti osoittaa ympyrän keskipisteen x- ja y-koordinaatit, kuten opetetaan missä tahansa matematiikan oppikirjassa ja muissa ympyröitä mainitsevissa lähteissä.

Toisin kuin aiemmat virheeni, tämä ei koskenut vain kollegoitani vaan myös miljoonia App Inventor -käyttäjiä. Monet heistä olivat lapsia tai täysin uusia ohjelmoinnin parissa. Heidän täytyi suorittaa monia tarpeettomia vaiheita työskennellessään jokaisessa sovelluksessa, jossa pallo oli läsnä. Jos muistan muita virheitäni nauraen, niin tämä saa minut hikoilemaan tänäkin päivänä.

Lopulta korjasin tämän bugin vasta äskettäin, kymmenen vuotta myöhemmin. "Pakattu", ei "korjattu", koska kuten Joshua Bloch sanoo, API:t ovat ikuisia. Emme voineet tehdä muutoksia, jotka vaikuttaisivat olemassa oleviin ohjelmiin, vaan lisäsimme OriginAtCenter-ominaisuuden arvolla false vanhoissa ohjelmissa ja true kaikissa tulevissa ohjelmissa. Käyttäjät voivat esittää loogisen kysymyksen: kuka edes ajatteli sijoittaa lähtökohtaa muualle kuin keskustaan. Kenelle? Yhdelle ohjelmoijalle, joka oli liian laiska luomaan normaalia API:ta kymmenen vuotta sitten.

Opittua

Kun työskentelet API:iden parissa (mitä melkein jokaisen ohjelmoijan on joskus tehtävä), sinun tulee noudattaa parhaita neuvoja, jotka on esitetty Joshua Blochin videossa "Kuinka luoda hyvä API ja miksi se on niin tärkeä"tai tässä lyhyessä listassa:

• API voi tuoda sinulle sekä suurta hyötyä että suurta haittaa.. Hyvä API luo toistuvia asiakkaita. Pahasta tulee ikuinen painajainen.
• Julkiset API:t, kuten timantit, kestävät ikuisesti. Anna kaikkesi: koskaan ei tule toista mahdollisuutta tehdä kaikki oikein.
• API-ääriviivat tulee olla lyhyitä — yksi sivu, jossa on luokka- ja menetelmäallekirjoituksia ja kuvauksia, jotka eivät saa olla enempää kuin riviä. Tämän avulla voit helposti järjestää API:n uudelleen, jos se ei ole täydellinen ensimmäisellä kerralla.
• Kuvaile käyttötapauksiaennen API:n käyttöönottoa tai jopa sen määrittelyn parissa työskentelemistä. Näin vältyt toteuttamasta ja määrittämästä täysin toimimatonta sovellusliittymää.

Jos olisin kirjoittanut edes lyhyen yhteenvedon keinotekoisella käsikirjoituksella, olisin todennäköisesti tunnistanut virheen ja korjannut sen. Jos ei, niin yksi kollegani tekisi sen ehdottomasti. Jokaista päätöstä, jolla on kauaskantoisia seurauksia, on mietittävä vähintään päivä (tämä ei koske vain ohjelmointia).

Richard Gabrielin esseen otsikko "Worse Is Better" viittaa siihen etuun, joka liittyy ensimmäisenä markkinoille - jopa epätäydellisen tuotteen kanssa - kun joku muu viettää ikuisuuden jahtaaessaan täydellistä tuotetta. Sprite-koodia pohtiessani ymmärrän, että minun ei tarvinnut edes kirjoittaa enempää koodia saadakseni sen oikein. Mitä tahansa voi sanoa, olin pahasti väärässä.

Johtopäätös

Ohjelmoijat tekevät virheitä joka päivä, olipa kyseessä bugisen koodin kirjoittaminen tai haluttomuus kokeilla jotain, joka parantaa heidän taitojaan ja tuottavuuttaan. Tietysti voit olla ohjelmoija tekemättä niin vakavia virheitä kuin minä. Mutta on mahdotonta tulla hyväksi ohjelmoijaksi tunnustamatta virheitä ja oppimatta niistä.

Tapaan jatkuvasti opiskelijoita, jotka kokevat tekevänsä liikaa virheitä ja siksi he eivät ole valmiita ohjelmoimaan. Tiedän kuinka yleinen huijarisyndrooma on IT:ssä. Toivon, että opit luettelemani opetukset - mutta muista tärkein: jokainen meistä tekee virheitä - kiusallisia, hauskoja, kauheita. Olen yllättynyt ja järkyttynyt, jos minulla ei ole tulevaisuudessa tarpeeksi materiaalia jatkaakseni artikkelia.

Lähde: will.com