5 kuuluisaa Ohjelmointilainausta, selitetty

ohjelmoijaksi ryhtyminen on itsensä ilmoittautumista jatkuvan oppimisen elämään. Uusien ominaisuuksien, uusien kielten, uusien työkalujen, uusien puitteiden lähde ei koskaan lakkaa pulppuamasta. Mutta tietojenkäsittelytiede on myös yllättävän perinteinen ala, joka perustuu aika-testattuihin periaatteisiin. Olemme lisänneet olio-ohjelmointia, modernia laitteistoa ja tekoälyä. Mutta näistä muutoksista huolimatta monet niistä oivalluksista, jotka esitettiin ensimmäisen kerran sukupolvi sitten, pitävät paikkansa vielä nykyäänkin.

tässä artikkelissa olen leikellyt muutamia lempilainauksiani tietojenkäsittelytieteestä. Ainoa ehto, jonka asetan, on, että jokaisen sitaatin on oltava vähintään kaksikymmentä vuotta vanha. Koska vaikka vanha teknologia muuttuu nopeasti hyödyttömäksi, ohjelmointi-esi-isiemme muinaisilla käskyillä on paljon pysyvämpi voima.

“kaikki tietojenkäsittelytieteen ongelmat voidaan ratkaista toisen tason harhautuksella.”- David Wheeler

tässä on usein toistettu compsci-sitaatti, jota harva kehittäjä haluaa selittää. Mutta se on yksi lempiohjelmointitotuuksistani, koska se iskee koodauksen ytimeen.

helpoin tapa alkaa ajatella indirektiota on kuvitella kerroksia. Esimerkiksi sanoa, että sinulla on pieni projekti, jonka on sovitettava komponentti a komponenttiin B:

molemmat osat on standardoitu, joten niitä ei voi murtaa auki ja muuttaa työskentelytapaa. Voisi rakentaa kokonaan uuden komponentin (PlugTwoProngVariant), mutta se on paljon työtä ja turhaa päällekkäisyyttä. Parempi lähestymistapa on lisätä kerros kahden kappaleen väliin — sovitin, joka sopii molempiin komponentteihin ja kääntää niiden välillä.

nyt, jos indirection olisi vain uuden kerroksen lisäämistä yhteensopimattomien kappaleiden sovittamiseksi yhteen, se olisi mukavaa, mutta kapeasti hyödyllistä. Mutta ajatus ongelmien ratkaisemisesta rakentamalla niiden ympärille on käsite, joka ulottuu alhaalta tietojenkäsittelyn huipulle. Sen näkee, kun uutta tietomallia yritetään sovittaa vanhaan käyttöliittymään. Näet sen, kun yrität sovittaa vanhaa sovellusta uuteen verkkopalvelun taustajärjestelmään. Näet sen, kun tarvitset korkeamman tason ominaisuuksia, kuten kirjaamista ja välimuistiin tallentamista, tai koordinoida korkeamman tason palveluja, kuten sanomanvälitystä ja tapahtumia. Ja pyramidin huipulla pääset harvinaisiin aiheisiin, kuten koneoppimiseen (kun et voi koodata tarvitsemaasi käyttäytymistä, kirjoita toinen koodikerros, joka selvittää sen puolestasi).

moni kertoo, että koodaamisessa on kyse eksplisiittisten ohjeiden kirjoittamisesta kielellä, jota idioottitkin tietokoneet ymmärtävät. Mutta David Wheelerin sitaatti paljastaa paremman näkemyksen. Hyvä ohjelmointi on abstraktion tikkaiden kiipeämistä yleisimpiin ratkaisuihin.

bonukseen liittyvä lainaus:

Indirection on voimakas, mutta monimutkaisuuteen liittyy kustannuksia. Ihmiset lainaavat hyvin harvoin Wheelerin välitöntä jatkohuomautusta indirectionista:

“mutta se yleensä luo uuden ongelman.”- David Wheeler

että totuus on pitänyt ohjelmoijat bisneksessä siitä lähtien.

yksinkertaisuudesta

“yksinkertaisuus on luotettavuuden edellytys.”- Edsger Dijkstra

ei ole pulaa viisaista ohjelmoijista, jotka varoittavat meitä liian monimutkaisista koodeistamme. Mutta harvat asettavat monimutkaisuuden kustannukset yhtään selvemmäksi kuin hollantilainen tietojenkäsittelytieteen uranuurtaja Edsger Dijkstra.

tässä oivallus: yksinkertaisuutta ei valita lahjaksi tulevaisuudelle. Et tee sitä siksi, että ennakoit mahdollisuutta käyttää koodia uudelleen, tai koska haluat sen näyttävän puhtaammalta koodin arvostelussa, tai koska haluat helpottaa muokkaamista. (Vaikka kaikki nämä edut ovat arvokkaita!) Teet sen, koska yksinkertaisuus on edellytys. Ilman yksinkertaisuutta, et voi koskaan olla luotettavaa koodia, johon voit luottaa pyörittämään liiketoimintaa tai käsittelemään tietojasi.

Dijkstran pisteen hyväksymiseksi on määriteltävä uudelleen, mitä “hyvä koodi” tarkoittaa. Se ei ole Lyhin koodi. Se ei ole välttämättä nopein koodi. Se ei ole fiksuin koodi. Se on koodi, johon voi luottaa.

bonukseen liittyvä lainaus:

yksi parhaista tavoista pitää koodi yksinkertaisena on muistaa, että vähemmän on enemmän. Dijkstra tarjoaa mittarin, joka auttaa pitämään sen mielessä:

“jos haluamme laskea koodirivejä, meidän ei pitäisi pitää niitä “tuotettuina riveinä” vaan “käytettyinä riveinä”.””- Edsger Dijkstra

luettavuudesta ja Uudelleenkirjoituksista

“koodin lukeminen on vaikeampaa kuin sen kirjoittaminen.”- Joel Spolsky

ensi silmäyksellä tämä ohjelmistolegendan ja StackOverflow ‘ n luojan Joel Spolskyn sitaatti vaikuttaa todelta mutta petollisen pinnalliselta. Kyllä, koodi voi olla tiheä, lyhyt, ja tediously pitkä. Eikä se ole vain muiden ihmisten koodi. Jos katsot omaa työtäsi vuoden takaa, tarvitset todennäköisesti aikaa käydä läpi logiikkaa, jonka kerran tunsit intiimisti.

, mutta Spolskyn oivalluksessa on käänne. Vaara koodi et voi lukea ei ole vain ilmeinen (se on vaikea muuttaa ja parantaa sitä). Sen sijaan suurempi vaara on, että monimutkainen koodi näyttää olevan huonompi kuin se todellisuudessa on. Itse asiassa, taakka yrittää ymmärtää jonkun toisen jo kirjoitettu koodi on niin suuri, että saatat tuntea kiusaus tehdä, mitä Spolsky kutsuu pahin mahdollinen virhe—päättää kirjoittaa koodin uudelleen tyhjästä.

kyse ei ole siitä, etteivätkö uudelleenkirjoitukset voisi parantaa järjestelmän arkkitehtuuria. Ehdottomasti. Nämä parannukset tulevat kuitenkin kalliiksi. He nollaavat testauksen ja vikojen korjaamisen kellon, kaksi toimintaa, jotka kestävät paljon kauemmin kuin pelkkä koodaaminen. Rewrites ovat houkuttelevia, koska ne pelata yksi yleisimmistä harhat ohjelmistokehityksen: me aliarvioida vaivaa tehdä asioita, jotka ovat käsitteellisesti yksinkertaisia. Siksi projektin lopullinen 5% vie 50% ajasta. Helpot asiat voivat olla yllättävän aikaa vieviä! Mikään ei tunnu helpommalta kuin ratkaista ongelma, jonka olet jo ratkaissut.

joten jos kaikkea ei pitäisi kirjoittaa uusiksi, niin mikä olisi parempi ratkaisu? Vastaus on saada jokainen kehittäjä mukaan jatkuvaan bite-kokoinen refactoring. Tämä antaa sinulle pieniä, jatkuvia koodinparannuksia-todellisia palkintoja minimaalisilla riskeillä. Voit parantaa luettavuutta matkalla.

bonukseen liittyvä lainaus:

jos vielä epäilet luettavuuden merkitystä, Martin Fowler auttaa laittamaan sen perspektiiviin:

“kuka tahansa hölmö osaa kirjoittaa koodia, jonka tietokone ymmärtää. Hyvät ohjelmoijat kirjoittavat koodia, jota ihmiset ymmärtävät.”- Martin Fowler

toisin sanoen ohjelmoijan tehtävä ei ole vain saada asioita toimimaan, vaan tehdä asioista järkeviä.

toistoon

“älä toista itseäsi. Jokaisella tiedolla on oltava yksi, yksiselitteinen ja arvovaltainen edustus järjestelmässä.”- Andy Hunt ja Dave Thomas

jokainen itseään kunnioittava ohjelmoija tietää, että toisto on suuren pahan sydän. Jos kirjoitat samaa asiaa eri paikoissa, teet ylimääräistä työtä kirjoittaminen, testaus, ja virheenkorjaus. Mikä vielä pahempaa, otat käyttöön mahdollisuuden epäjohdonmukaisuuksiin — esimerkiksi, jos yksi osa koodia päivitetään, mutta muut, vastaavia rutiineja ei tuoda sopimukseen. Epäjohdonmukainen ohjelma on ohjelma, johon ei voi luottaa, eikä ohjelma, johon ei voi luottaa, ole enää toimiva ratkaisu.

, mutta koodi ei ole ainoa paikka, jossa toisto aiheuttaa tuhoa. Tämä versio kuuluisasta “älä toista itseäsi” (kuiva) – säännöstä laajentaa Ei-päällekkäisyysperiaatetta kattamaan muut paikat, joissa epäjohdonmukaisuudet voivat piiloutua. Emme puhu enää koodien päällekkäisyydestä. Puhumme myös toistosta järjestelmässä-ja järjestelmällä on monia erilaisia tapoja koodata tietoa. Niitä ovat:

• Koodilauseet
• Koodikommentit
• kehittäjän tai asiakkaan dokumentaatio
• tietojärjestelmät (esimerkiksi tietokantataulukot)
• Muut eritelmät, kuten testaussuunnitelmat, työnkulkuasiakirjat ja rakentamissäännöt

kaikki nämä tasot voivat olla päällekkäisiä keskenään. Ja kun he tekevät niin, he ottavat riskin, että he esittelevät eri versioita samasta todellisuudesta. Mitä tapahtuu esimerkiksi, jos dokumentaatiossa kuvataan yhtä tapaa toimia, mutta hakemus seuraa toista? Kuka omistaa totuuden? Mitä tapahtuu, jos tietokantataulukot eivät vastaa koodissa olevaa tietomallia? Tai kommenteissa kuvataan algoritmin toimintaa, joka ei vastaa sen todellista toteutusta? Jokainen järjestelmä tarvitsee yhden, arvovaltaisen edustuksen, josta kaikki muu juontuu.

muuten totuuden kilpailevat versiot eivät ole ongelma vain pienimuotoisissa projekteissa tai huonosti suunnitellussa koodissa. Yksi parhaista esimerkeistä purkautui julkisuuteen XHTML: n ja HTML5: n välisen taistelun myötä. Erään leirin mukaan eritelmä oli virallinen totuus, ja selaimet piti korjata, jotta ne noudattaisivat sitä. Toinen ryhmä väitti, että selaimen käyttäytyminen oli de facto standardi, koska se mitä suunnittelijat olivat mielessä, kun he kirjoittivat web-sivuja. Lopulta selainversio totuudesta voitti. Siitä lähtien HTML5 oli mitä selaimet tekivät – mukaan lukien niiden sallimat pikakuvakkeet ja niiden hyväksymät virheet.

bonuksiin liittyvä lainaus:

koodin ja kommenttien mahdollisuus olla ristiriidassa keskenään on avannut kiivaan keskustelun siitä, onko kommenteista enemmän haittaa kuin hyötyä. Äärimmäisen ohjelmoinnin kannattajat suhtautuvat heihin avoimen epäluuloisesti:

“koodi ei koskaan valehtele, Kommentit joskus valehtelevat.”—Ron Jeffries

vaikeista ongelmista

“tietojenkäsittelytieteessä on vain kaksi kovaa asiaa: välimuistin mitätöinti ja asioiden nimeäminen.”- Phil Karlton

ensi silmäyksellä tämä sitaatti vaikuttaa huvittavalta, mutta tavalliselta ohjelmointivitsiltä. Kontrasti jonkin vaikealta kuulostavan asian (välimuistin mitätöinti) ja jonkin kivuttomalta kuulostavan (asioiden nimeäminen) välillä on heti samaistuttava. Jokainen ohjelmoija on investoinut työtuntien vahvistamisesta naurettavan triviaali asia, kuten pari parametrit läpäissyt väärässä järjestyksessä tai epäjohdonmukaisesti Isolla muuttuja (Kiitos JavaScript). Niin kauan kuin ihmisten täytyy tehdä yhteistyötä koneiden kanssa, ohjelmointi tulee olemaan korkean tason järjestelmäsuunnittelun ja vähäpätöisten kirjoitusvirheiden mashup.

mutta jos vilkaisee Phil Karltonin sitaattia, purettavaa on enemmänkin. Asioiden nimeäminen ei ole vaikeaa vain siksi, että ohjelmoijan elämää pilaavat säännöllisesti pienet päänsäryt. Se johtuu myös siitä, että kysymys nimeäminen on itse asiassa reuna jokaisen ohjelmoijan tärkein työ: ohjelmistosuunnittelu. Toisin sanoen, miten kirjoitat koodia, joka on selkeä, puhdas ja johdonmukainen?

on monia tapoja saada nimeäminen väärin. Olemme kaikki nähneet muuttujia nimetty tietotyypit (myString, obj), lyhenteet (pc tuoteluettelossa), joitakin triviaaleja toteutusyksityiskohtia (swappable_name, formUserInput), tai ei yhtään mitään (ret_value, tempArray). On helppo langeta ansaan nimeämällä muuttuja sen perusteella, mitä teet sillä hetkellä sen sijaan, mitä se sisältää. Ja Boolen arvot ovat erityisen hankalia-asettaako progress kun edistyminen alkaa, osoittaako se, että sinun on näytettävä edistymistiedot käyttöliittymässä, tai merkitseekö se jotain aivan muuta?

mutta muuttuvat nimet ovat vasta alkua. Luokkien nimeäminen herättää kysymyksen siitä, miten koodin jakaa itsenäisiin osiin. Julkisten jäsenten nimeäminen muokkaa sitä, miten esität käyttöliittymän, jonka avulla sovelluksen yksi osa voi olla vuorovaikutuksessa toisen kanssa. Näiden nimien lukitseminen ei vain kuvaa, mitä koodinpätkä voi tehdä, se määrittää, mitä se tekee.

bonuksiin liittyvä lainaus:

“tietojenkäsittelytieteessä on kaksi kovaa asiaa: välimuistin mitätöinti, asioiden nimeäminen ja off-by-one virheet.”—Leon Bambrick