5 híres programozási Idézetek, magyarázható

ahhoz, hogy egy programozó, hogy iratkozzon fel az élet állandó tanulás. Az új — új funkciók, új nyelvek, új eszközök, új keretek—szökőkútja soha nem áll meg. De a számítástechnika is meglepően hagyományos terület, amely időben tesztelt elveken alapul. Hozzáadtunk objektum-orientált programozást, modern hardvert és mesterséges intelligenciát. De e változások ellenére, sok olyan felismerés, amelyet először egy generációval ezelőtt fogalmaztak meg, ma is igaz.

ebben a cikkben néhány kedvenc idézetet boncoltam a számítástechnikáról. Az egyetlen feltétel, amelyet beállítottam, az, hogy minden idézetnek legalább húsz évesnek kell lennie. Mert míg a régi technológia gyorsan használhatatlanná válik, a programozási őseink ősi parancsolatai sokkal több kitartással rendelkeznek.

“a számítástechnika minden problémáját egy másik indirekt szinttel lehet megoldani.”- David Wheeler

itt van egy gyakran ismétlődő compsci idézet, amelyet kevés fejlesztő akar megmagyarázni. De ez az egyik kedvenc programozási igazságom, mert a kódolás középpontjában áll.

az indirekcióra való gondolkodás legegyszerűbb módja a rétegek elképzelése. Tegyük fel például, hogy van egy kis projektje, amelynek be kell illesztenie az a komponenst a B komponensbe:

mindkét alkatrész szabványosított, így nem lehet feltörni őket, és megváltoztatni a működésüket. Lehet építeni egy teljesen új komponenst (PlugTwoProngVariant), de ez sok munka és felesleges duplikáció. Jobb megközelítés, ha egy réteget adunk a két darab közé — egy adaptert, amely illeszkedik mindkét alkatrészbe, és lefordítja őket.

most, ha az indirection csak egy új réteg hozzáadásáról szól, hogy illeszkedjen az inkompatibilis darabokhoz, jó lenne, de szűken hasznos. De a problémák megoldásának gondolata körülöttük egy olyan koncepció, amely a számítástechnika aljától a tetejéig terjed. Ezt akkor látja, amikor egy új adatmodellt próbál illeszteni egy régi felhasználói felülethez. Ezt akkor látja, amikor egy örökölt alkalmazást próbál beilleszteni egy új webszolgáltatás háttérrendszerébe. Ezt akkor látja, amikor magasabb szintű funkciókat kell használnia, például naplózást és gyorsítótárazást, vagy magasabb szintű szolgáltatásokat, például üzenetküldést és tranzakciókat kell koordinálnia. A piramis tetején pedig olyan ritka témákhoz jut, mint a gépi tanulás (ha nem tudja kódolni a szükséges viselkedést, írjon egy másik kódréteget, amely kitalálja az Ön számára).

rengeteg ember fogja mondani, hogy a kódolás arról szól, hogy kifejezett utasításokat írunk egy olyan nyelven, amelyet még az idióta számítógépek is megértenek. De David Wheeler idézete jobb betekintést tár fel. A jó programozás arról szól, hogy felmászunk az absztrakció létrájára, hogy elérjük a legáltalánosabb megoldásokat.

bónusz kapcsolódó idézet:

Indirection erős, de van egy költség a komplexitás. Az emberek nagyon ritkán idézik Wheeler azonnali követő megjegyzését az indirekcióról:

“de ez általában újabb problémát okoz.”- David Wheeler

ez az igazság azóta is tartja a programozókat az üzleti életben.

az egyszerűségről

“az egyszerűség a megbízhatóság előfeltétele.”- Edsger Dijkstra

nincs hiány bölcs programozókból, akik figyelmeztetnek minket, hogy ne bonyolítsuk túl a kódunkat. De kevesen teszik a komplexitás költségeit egyértelműbbé, mint a holland Számítástechnika úttörője, Edsger Dijkstra.

itt van a betekintés: nem az egyszerűséget választja a jövő ajándékaként. Nem azért teszi, mert előre látja a kód újrafelhasználásának esélyét, vagy azért, mert azt szeretné, hogy tisztábbnak tűnjön a kód felülvizsgálata során, vagy azért, mert megkönnyíti a módosítást. (Bár ezek az előnyök értékesek!) Azért csinálod, mert az egyszerűség előfeltétele. Egyszerűség nélkül soha nem lehet megbízható kódja, amelyben megbízhat egy vállalkozás működtetésében vagy az adatok kezelésében.

Dijkstra pontjának elfogadásához újra kell definiálnunk, hogy mit jelent a “jó kód”. Ez nem a legrövidebb kód. Ez nem feltétlenül a leggyorsabb kód. Ez határozottan nem a legokosabb kód. Ez a kód megbízható.

bónusz kapcsolódó idézet:

az egyik legjobb módja annak, hogy a kód egyszerű, hogy ne feledje, hogy kevesebb több. A Dijkstra mutatót kínál, amely segít ezt szem előtt tartani:

“ha kódsorokat akarunk számolni, akkor azokat nem ‘előállított’ soroknak, hanem ‘elhasznált soroknak kell tekintenünk.'”- Edsger Dijkstra

az Olvashatóságról és az Újraírásról

“nehezebb olvasni a kódot, mint írni.”- Joel Spolsky

első pillantásra a szoftverlegenda és a StackOverflow társalkotója, Joel Spolsky idézete igaznak tűnik, de megtévesztően sekélynek. Igen, a kód lehet sűrű, tömör és unalmasan hosszú. És ez nem csak mások kódja. Ha megnézed a saját munkádat egy évvel ezelőtt, valószínűleg szükséged lesz egy kis időre, hogy átnézze azt a logikát, amelyet egykor bensőségesen ismert.

de Spolsky betekintése csavarral jár. A kód nem olvasható veszélye nem csak nyilvánvaló(nehéz megváltoztatni és javítani). Ehelyett a nagyobb veszély az, hogy a komplex kód rosszabbnak tűnik, mint amilyen valójában. Valójában olyan nagy a teher, hogy megpróbáljuk megérteni valaki más már megírt kódját, hogy kísértésbe eshet, hogy Spolsky a lehető legrosszabb hibának nevezi—úgy dönt, hogy átírja ezt a kódot a semmiből.

nem arról van szó, hogy az átírások nem javíthatják a rendszer architektúráját. Biztosan tudnak. De ezek a fejlesztések nagy költségekkel járnak. Visszaállítják az órát a tesztelésre és a hibajavításra, két olyan tevékenységre, amelyek sokkal tovább tartanak, mint a puszta kódolás. Az átírások csábítóak, mert a szoftverfejlesztés egyik leggyakoribb elfogultságán játszanak: alábecsüljük a fogalmilag egyszerű dolgok elvégzésére irányuló erőfeszítéseket. Ezért a projekt végső 5% – a az idő 50% – át veszi igénybe. Az egyszerű dolgok meglepően időigényesek lehetnek! És semmi sem tűnik könnyebbnek, mint megoldani egy már megoldott problémát.

tehát ha nem kellene mindent átírni, hogy tökéletes legyen, mi a jobb megoldás? A válasz az, hogy minden fejlesztőt bevonunk az állandó harapás méretű refaktorálásba. Ez kicsi, folyamatos kódfejlesztést biztosít — valódi jutalmakat minimális kockázatokkal. Javíthatja az olvashatóságot az úton.

bónusz kapcsolódó idézet:

ha még mindig kétségei vannak az olvashatóság fontosságával kapcsolatban, Martin Fowler segít perspektívába helyezni:

“bármely bolond képes olyan kódot írni, amelyet a számítógép megért. A jó programozók olyan kódot írnak, amelyet az emberek megértenek.”- Martin Fowler

más szavakkal, a programozó feladata nem csak az, hogy a dolgok működjenek, hanem hogy a dolgok értelmesek legyenek.

Ismétléskor

“ne ismételd magad. Minden tudásnak egyetlen, egyértelmű, hiteles reprezentációval kell rendelkeznie egy rendszeren belül.”Andy Hunt és Dave Thomas

minden magára valamit is adó programozó tudja, hogy az ismétlés a gonoszság szíve. Ha ugyanazt írja különböző helyeken, akkor extra munkát végez az írás, a tesztelés és a hibakeresés. Még ennél is rosszabb, hogy bevezeti a következetlenségek lehetőségét — például, ha a kód egyik része frissül, de más, hasonló rutinokat nem hoznak megállapodásba. Az inkonzisztens program olyan program, amelyben nem bízhat, és az a program, amelyben nem bízhat, már nem életképes megoldás.

azonban a kód nem az egyetlen hely, ahol az ismétlés pusztítást okoz. A híres “ne ismételje meg magát” (száraz) szabály ezen verziója kiterjeszti a duplikáció tilalmának elvét, hogy lefedje azokat a helyeket, ahol az ellentmondások elrejthetők. Már nem beszélünk kód duplikációról. Ismétlésről is beszélünk egy rendszerben — és a rendszernek sokféle módja van a tudás kódolására. Ezek közé tartozik:

• Kódutasítások
• Kódmegjegyzések
• fejlesztői vagy ügyféldokumentációk
• Adatsémák (például adatbázis-táblák)
• egyéb specifikációk, például teszttervek, munkafolyamat-dokumentumok és építési szabályok

ezek a szintek átfedésben lehetnek egymással. És amikor megteszik, kockáztatják, hogy ugyanazon valóság különböző verzióit mutatják be. Például, mi történik, ha a dokumentáció leírja az egyik munkamódszert, de az alkalmazás követi a másikat? Ki birtokolja az igazságot? Mi történik, ha az adatbázis táblák nem egyeznek meg a kód adatmodelljével? Vagy a megjegyzések egy olyan algoritmus működését írják le, amely nem felel meg a tényleges megvalósításának? Minden rendszernek egyetlen, hiteles reprezentációra van szüksége, amelyből minden más származik.

egyébként az igazság versengő verziói nem csak kis léptékű projektekben vagy rosszul megtervezett kódokban jelentenek problémát. Az egyik legjobb példa az XHTML és a HTML5 közötti csatával robbant ki a nyilvánosság előtt. Az egyik tábor azzal érvelt, hogy a specifikáció a hivatalos igazság, és a böngészőket ki kell javítani, hogy kövessék. A másik frakció azt állította, hogy a böngésző viselkedése volt a de facto szabvány, mert erre gondoltak a tervezők, amikor weboldalakat írtak. Végül az igazság böngésző verziója nyert. Ettől kezdve a HTML5 volt az, amit a böngészők tettek — beleértve az általuk engedélyezett parancsikonokat és az általuk elfogadott hibákat.

bónusz kapcsolódó idézet:

az a lehetőség, hogy a kód és a Megjegyzések ellentmondanak egymásnak, heves vitát váltott ki arról, hogy a Megjegyzések többet ártanak-e, mint hasznot. Az extrém programozás támogatói nyílt gyanakvással kezelik őket:

“a kód soha nem hazudik; a Megjegyzések néha igen.”- Ron Jeffries

a nehéz problémákról

“csak két nehéz dolog van a számítástechnikában: a gyorsítótár érvénytelenítése és a dolgok elnevezése.”- Phil Karlton

első pillantásra ez az idézet szórakoztató, de hétköznapi programozási viccnek tűnik. A kontraszt között egy valami, ami úgy hangzik, nehéz (cache érvénytelenítése), és valami, ami úgy hangzik, fájdalommentes (elnevezési dolgok) azonnal relatable. Minden programozó órákat fektetett be egy nevetségesen triviális probléma kijavításába, például egy rossz sorrendben átadott paraméterpárba vagy egy következetlenül nagybetűs változóba (köszönet JavaScript). Mindaddig, amíg az embereknek gépekkel kell együttműködniük a dolgok elvégzéséhez, a programozás magas szintű rendszertervezés és triviális elírások mashupja lesz.

de ha egy második pillantást vet Phil Karlton idézetére, van még mit kicsomagolni. A dolgok megnevezése nem nehéz csak azért, mert a programozó életét rendszeresen tönkreteszik apró fejfájások. Azért is, mert az elnevezés kérdése valójában minden programozó legfontosabb munkájának éle: a szoftvertervezés. Más szavakkal, hogyan írhatsz tiszta, tiszta és következetes kódot?

rengeteg módja van a rossz elnevezésnek. Mindannyian láttunk már adattípusokról elnevezett változókat(myString, obj), rövidítések (pc a termékkatalógushoz), néhány triviális megvalósítási részlet (swappable_name, formUserInput), vagy egyáltalán semmi (ret_value, tempArray). Könnyű abba a csapdába esni, hogy egy változót elnevezünk annak alapján, hogy mit csinálunk vele abban a pillanatban, nem pedig azt, amit tartalmaz. A logikai értékek pedig különösen trükkösek — a progress beállítása a haladás megkezdésekor azt jelzi, hogy meg kell jelenítenie az előrehaladási információkat a felhasználói felületen, vagy valami teljesen mást kell megjelölnie?

de a változónevek csak a kezdet. Az osztályok elnevezése felveti a kérdést, hogy hogyan osztja a kódot független részekre. A nyilvános tagok elnevezése alakítja ki azt a felületet, amely lehetővé teszi az alkalmazás egyik részének interakcióját a másikkal. Ezeknek a neveknek a lezárása nem csak azt írja le, hogy egy kóddarab mire képes, hanem azt is meghatározza, hogy mit fog tenni.

bónusz kapcsolódó idézet:

“két nehéz dolog van a számítástechnikában: a gyorsítótár érvénytelenítése, a dolgok elnevezése és az egyes hibák.”- Leon Bambrick