5 slavných programovacích nabídek, vysvětleno

být programátorem znamená přihlásit se k životu neustálého učení. Fontána nových-nové funkce, nové jazyky, nové nástroje, nové rámce-nikdy nepřestane tryskat. Ale informatika je také překvapivě tradiční obor, který je založen na osvědčených principech. Přidali jsme objektově orientované programování, moderní hardware a umělou inteligenci. Ale i přes tyto změny, mnoho poznatků, které byly první kloubové generací, stále platí dnes.

v tomto článku jsem rozebral několik mých oblíbených citátů o informatice. Jedinou podmínkou, kterou jsem si stanovil, je, že každý citát musí být alespoň dvacet let starý. Protože zatímco stará technologie se rychle stává zbytečnou, starodávná přikázání našich programovacích předků mají mnohem větší sílu.

“všechny problémy v informatice lze vyřešit jinou úrovní nepřímosti.”- David Wheeler

zde je často opakovaný compsci citát, který jen málo vývojářů chce vysvětlit. Ale je to jedna z mých oblíbených programovacích pravd, protože zasahuje do jádra toho, o čem kódování je.

nejjednodušší způsob, jak začít přemýšlet o dereference je představit vrstev. Například, řekněme, že máte malý projekt, který potřebuje, aby se vešly složky A do složky B:

Obě složky jsou standardizované, takže nemůžete rozbít jim otevřít a změnit způsob, jakým pracují. Můžete vytvořit zcela novou komponentu (PlugTwoProngVariant), ale to je spousta práce a zbytečné duplikace. Lepším přístupem je přidání vrstvy mezi dva kusy-adaptér, který zapadá do obou komponent a překládá se mezi nimi.

nyní, pokud indirection byl jen o přidání nové vrstvy, aby se vešly nekompatibilní kusy dohromady, bylo by to hezké, ale úzce užitečné. Myšlenka řešení problémů budováním kolem nich je však koncept, který se táhne od dna k vrcholu výpočetní techniky. Vidíte to, když se pokoušíte přizpůsobit nový datový model starému uživatelskému rozhraní. Vidíte to, když se snažíte, aby se vešly starší aplikace do nové webové služby backend. Vidíte to, když potřebujete připoutat funkce vyšší úrovně, jako je protokolování a ukládání do mezipaměti, nebo koordinovat služby vyšší úrovně, jako jsou zasílání zpráv a transakce. A na vrcholu pyramidy, dostanete řidší témata, jako je strojové učení (pokud nemůžete kód chování, který potřebujete, napište další vrstvu kód, který to vyřeší za vás).

Spousta lidí vám řekne, že kódování je o psaní explicitní instrukce v jazyce, že i idiot počítače může pochopit. Ale citát Davida Wheelera odhaluje lepší vhled. Dobré programování je o lezení po žebříku abstrakce, abychom se dostali k nejobecnějším řešením.

bonus související citace:

Indirection je silný, ale je tu náklady na složitost. Lidé jen velmi zřídka citát Wheeler bezprostřední reakci na poznámku o dereference:

“Ale to obvykle vytvoří další problém.”- David Wheeler

tato pravda udržuje programátory v podnikání od té doby.

o jednoduchosti

“jednoduchost je předpokladem spolehlivosti.”— Edsger Dijkstra

Neexistuje žádný nedostatek moudrých programátorů varování nás, abychom to zbytečně komplikovat náš kód. Jen málokdo však dal náklady na složitost o něco jasnější než nizozemský průkopník informatiky Edsger Dijkstra.

zde je náhled: jednoduchost si nevyberete jako dárek do budoucnosti. To neuděláš, protože jsi předvídání šanci znovu použít kód, nebo proto, že chcete, aby to vypadalo čistší kód, recenze, nebo proto, že chcete, aby bylo snadnější změnit. (I když všechny tyto výhody jsou cenné!) Děláte to proto, že jednoduchost je předpokladem. Bez jednoduchosti nikdy nemůžete mít spolehlivý kód, kterému můžete důvěřovat při podnikání nebo zpracování dat.

abychom přijali bod Dijkstry, musíme předefinovat, co znamená “dobrý kód”. Není to nejkratší kód. Není to nutně nejrychlejší kód. Rozhodně to není nejchytřejší kód. Je to kód, kterému se dá věřit.

bonus související citace:

jedním z nejlepších způsobů, jak udržet kód jednoduchý je mít na paměti, že méně je více. Dijkstra nabízí metriku, která nám to pomůže mít na paměti:

“chceme – li počítat řádky kódu, neměli bychom je považovat za “vyrobené řádky”, ale za “vynaložené řádky”.'”- Edsger Dijkstra

o čitelnosti a přepisování

“je těžší číst kód než psát.”- Joel Spolsky

na první pohled se tato citace softwarové legendy a spolutvůrce StackOverflow Joela Spolského zdá pravdivá, ale klamně mělká. Ano, kód může být hustý, strohý a zdlouhavě dlouhý. A není to jen kód jiných lidí. Pokud se podíváte na svou vlastní práci před rokem, pravděpodobně budete potřebovat nějaký čas na vyřešení logiky, kterou jste kdysi důvěrně znali.

ale Spolskyho pohled přichází s obratem. Nebezpečí kódu, který nemůžete přečíst, není jen zřejmé (je těžké jej změnit a vylepšit). Místo toho je větší nebezpečí, že komplexní kód se zdá být horší, než ve skutečnosti je. Ve skutečnosti je břemeno snahy porozumět již napsanému kódu někoho jiného tak velké, že byste mohli být v pokušení udělat to, co Spolsky nazývá nejhorší možnou chybou—rozhodnout se přepsat tento kód od nuly.

není to tak, že přepisy nemohou zlepšit architekturu systému. Určitě mohou. Ale tato vylepšení přicházejí s velkými náklady. Resetují hodiny při testování a opravě chyb, dvě činnosti, které trvají mnohem déle než pouhé kódování. Přepisy jsou lákavé, protože hrají na jedné z nejčastějších předsudků ve vývoji softwaru: podceňujeme snahu dělat věci, které jsou koncepčně jednoduché. Proto posledních 5% projektu zabere 50% času. Snadné věci mohou být překvapivě časově náročné! A nic se nezdá být snazší než vyřešit problém, který jste již vyřešili.

takže pokud byste neměli přepsat vše, aby bylo perfektní, jaké je lepší řešení? Odpovědí je, aby se každý vývojář zapojil do neustálého refaktorování velikosti kousnutí. To vám dává malé, neustálé zlepšování kódu-skutečné odměny s minimálními riziky. Můžete zlepšit čitelnost na cestě.

Bonus související citace:

Pokud jste stále na pochybách o významu čitelnost, Martin Fowler pomáhá, aby to v perspektivě:

“každý hlupák může napsat kód, který počítač může pochopit. Dobří programátoři píší kód, kterému lidé rozumějí.”- Martin Fowler

jinými slovy, úkolem programátora není jen to, aby věci fungovaly, ale aby věci dávaly smysl.

při opakování

“neopakuj se. Každý kus znalostí musí mít jediné, jednoznačné, autoritativní zastoupení v systému.”- Andy Hunt a Dave Thomas

každý sebeúcty programátor ví, že opakování je srdcem hodně zla. Pokud píšete totéž na různých místech, děláte práci navíc psaní, testování a ladění. Ještě horší je, že zavádíte možnost nesrovnalostí – například pokud je jedna část kódu aktualizována, ale jiné podobné rutiny nejsou dohodnuty. Nekonzistentní program je program, nemůžete věřit, a program, nemůžete věřit, je již schůdné řešení.

Nicméně, kód není jediným místem, kde se opakování způsobí těžkou újmu. Tato verze slavného pravidla” neopakujte se ” (suché) rozšiřuje princip bez duplikace tak, aby pokrýval další místa, kde se mohou skrýt nesrovnalosti. Už nemluvíme o duplikaci kódu. Mluvíme také o opakování v systému – a systém má mnoho různých způsobů kódování znalostí. Patří mezi ně:

• příkazy Kódu
• Kód komentáře
• Vývojář nebo klientské dokumentace
• Data schémata (například databáze, tabulky)
• Další specifikace, jako zkušební plány, workflow dokumentů, a vytvořit pravidla

Všechny tyto vrstvy se mohou překrývat s ostatními. A když to udělají, riskují zavedení různých verzí stejné reality. Co se například stane, pokud dokumentace popisuje jeden způsob práce, ale aplikace následuje jiný? Kdo má vlastnictví pravdy? Co se stane, když databázové tabulky neodpovídají datovému modelu v kódu? Nebo komentáře popisují fungování algoritmu, který neodpovídá jeho skutečné implementaci? Každý systém potřebuje jediné, autoritativní zastoupení, ze kterého pochází vše ostatní.

mimochodem, konkurenční verze pravdy nejsou jen problémem v malých projektech nebo špatně navrženém kódu. Jeden z nejlepších příkladů propukl na veřejnost bitvou mezi XHTML a HTML5. Jeden tábor tvrdil, že specifikace byla oficiální pravda, a prohlížeče je třeba opravit, aby se ji řídily. Druhá frakce tvrdila, že chování prohlížeče bylo de facto standardem, protože to měli designéři na mysli, když psali webové stránky. Nakonec zvítězila prohlížečová verze pravdy. Od tohoto bodu na, HTML5 bylo to, co prohlížeče, udělal — včetně zkratky jsou povoleny a chyby přijali.

bonus související citace:

možnost kód a komentáře v rozporu se navzájem otevřel vášnivou debatu o tom, zda připomínky udělat více škody než užitku. Zastánci extrémního programování s nimi zacházejí s otevřeným podezřením:

“kód nikdy nelže; Komentáře někdy ano.— – Ron Jeffries

o tvrdých problémech

“v informatice jsou jen dvě těžké věci: zneplatnění mezipaměti a pojmenování věcí.”- Phil Karlton

na první pohled se tato citace jeví jako zábavný, ale obyčejný programovací vtip. Kontrast mezi něčím, co zní obtížně (zneplatnění mezipaměti) a něčím, co zní bezbolestně (pojmenování věcí), je okamžitě relatable. Každý programátor investovala hodin práce, kterým směšně triviální záležitost, jako dvojice parametrů předaných v nesprávném pořadí nebo nekonzistentně vydělával variabilní (díky Javascriptu). Dokud lidé potřebují spolupracovat se stroji, aby mohli věci udělat, programování bude mashupem systémového plánování na vysoké úrovni a triviálních překlepů.

ale pokud se znovu podíváte na citát Phila Karltona, je tu ještě rozbalit. Pojmenovat věci není těžké jen proto, že život programátora pravidelně ničí drobné bolesti hlavy. Je to také proto, že otázka pojmenování je ve skutečnosti hranou nejdůležitější práce každého programátora: návrh softwaru. Jinými slovy, jak píšete kód, který je jasný, čistý a konzistentní?

existuje spousta způsobů, jak pojmenovat špatně. Všichni jsme viděli proměnné pojmenované po datové typy (myString, obj), zkratky (pc katalog produktů), některé triviální implementace detail (swappable_name, formUserInput), nebo dokonce vůbec nic (ret_value, tempArray). Je snadné se dostat do pasti pojmenování proměnné na základě toho, co s ní v daném okamžiku děláte, spíše než toho, co obsahuje. A booleovské hodnoty jsou obzvláště složité-nastaví progress při spuštění pokroku, znamená to, že potřebujete zobrazit informace o pokroku v uživatelském rozhraní nebo označit něco úplně jiného?

Ale názvy proměnných jsou jen začátek. Pojmenování tříd vyvolává otázku, jak rozdělíte kód na nezávislé části. Pojmenování veřejných členů utváří způsob prezentace rozhraní, které umožňuje jedné části aplikace komunikovat s jinou. Uzamčení těchto jmen nepopisuje pouze to, co může kus kódu udělat, ale určuje, co bude dělat.

bonus související citace:

“v informatice existují dvě těžké věci: zneplatnění mezipaměti, pojmenování věcí a chyby po jednom.”- Leon Bambrick