Umění programování v Unixu - Kapitola 1

Technická polemika - Po zhodnocení formální stránky knihy, bych se rád dostal k zajímavým myšlenkám v knize obsaženým.

Úvodní kapitola se zabývá historií UNIXu jeho postavením mezi ostatními operačními systémy. Snaží se ukázat, že UNIX jako technologie i filozofie musela přijmout spoustu změn a překonat změny trendů. Přechod z prostředí mainframe na osobní počítače, dále do distribuovaného prostředí internetu a nakonec i překonat změnu související se zavedením GUI. Kniha se snaží popsat základní trendy, které si UNIX zachovává a v podstatě dochází k tomu, že je to svoboda práce se zdrojovým kódem systému i programů a dobrý inženýrský návrh, postavený na spoustě malých spolupracujících programů. IMHO: Pravidla uvedená v této kapitole se hodí k návrhu libovolného software a lze je označit za pravidla dobrého návrhu aplikace. Pravidla jsem trošku přeformuloval a mnohdy doplnil svým pohledem, takže se nejedná o překlad knihy, jde spíš rozvití myšlenek v knize obsažených.

Ke konci kapitoly je je uveden krátký popis jiných systémů a v čem se liší. Přijde mi, že tento popis je trošku zaujatý a nejde moc do hloubky, ale nejsem odborníkem na operační systémy.

Pravidla psaní software

Držte se jednoduchých, propojitelných rozhraní – Zde jsou myšlena hlavně rozhraní textová, popř. založená na XML. Rozhraní je to co určuje zda program bude použitelný ve větším kontextu nebo zůstane zastrčený v šuplíku. Složité rozhraní znesnadňuje použití programu v kontextu ostatních programů.

Srozumitelnost je důležitější než efektivita – Prostě jen přeformulované tvrzení D.Knutha: “Předčasná optimalizace je kořenem všeho zla.”. Složitý algoritmus obsahuje více místa pro chyby a hůře se opravuje i rozšiřuje. Zdrojový kód by měl být opatřen komentáři. V knize lze dokonce potkat i myšlenku literárního programování a to v té podobě, že každý algoritmus by měl být snadno vysvětlitelný pomocí přirozeného jazyka a podobným způsobem i zapsán ve zdrojovém kódu.

Navrhuje programy propojitelné s jinými programy – V duchu zásady program má dělat jednu věc dobře a nesnažit se řešit vše. Dokládané je to na možnosti zvolit si editor, který jiné programy budou používat pro vstup a editaci textu. Jiným příkladem je realizace stránkování výpisu na obrazovku, přes příkazy more, less.

Navrhujte jednoduché programy, složité piště jen v případě nutnosti – Zde se lze odkázat na knihu Steve McConell: Odhadování softwarových projektů, kde se dozvíte, že s velikostí programu roste pravděpodobnost překročení rozpočtu i toho, že se program nepodaří dokončit. Přičemž náročnost vývoje s velikostí programu roste kvadraticky! (protože tímto způsobem roste počet možných vazeb v programu)

Navrhujte transparentní programy – Tedy programy, ze kterých lze na základě vstupu snadno zkontrolovat výstup a ověřit, že program plní to co má.

Pravidlo robustnosti – Program se musí vypořádat i s krajními případy a vyprodukovat smysluplný výstup. Při propojení s jinými programy se na vstupu může objevit skoro cokoliv. V podstatě se jedná o defenzivní programování.

Volte deklarativní zápisy ne procedurální – Zápis gramatiky v BNF je daleko snazší než její zápis v syntaktickém analyzátoru. Stejně tak je tabulka jednodušší reprezentací, než složitý příkaz switch nebo mnoho konstrukcí if, else.

Pravidlo nejmenšího překvapení – Rozhraní by uživatele nemělo překvapovat. Snaha dodržovat běžnou kulturu zápisů – způsob značení komentářů, zápisu programu, … Rozhodně se však vyvarujte označování rozdílných věcí stejným způsobem. Příkaz return, který by místo ukončení funkce ukončil program, je takovým příkladem.

Mluvte jen když je třeba – Program má mluvit, jen když je potřeba sdělit něco důležitého. Ukecané programy nikdo neposlouchá. Pokud je však třeba upozornit na chybu, tak nejlépe hlasitě a co nejdříve! Informace o chybě by měla být dostatečně konkrétní. Je velký rozdíl mezi hláškou “Hups chyba!” a “Chyba soubor config.ini: Na řádku 35, je uveden neexistující uživatel pepa3”.

Programátorův čas je dražší než čas CPU – Za 2 roky poběží vaše programy 2x rychleji. A to bez námahy. V podstatě zas odkaz na předčasnou optimalizaci. Optimalizace se totiž řeší až naposled, kdy je jasné jaké části (cca 20% programu) zpomalení způsobují. 80% programu nemá smysl optimalizovat, dokonce to škodí přehlednosti, rozšiřitelnosti a poštu chyb v programu. Pokud program běží dost rychle i tak, lze si ušetřit i optimalizaci těch 20% ;).

Pravidlo generování – Počet chyb na řádku je v podstatě nezávislý na jazyce, snažte se tedy psát úsporně a manuální úkony (jako generování kódu) nechat na počítači. Věřte, že je spolehlivější. Pozn. Výstup generátorů pokud možno neupravujeme! (to bychom se o výhodu malého počtu řádek připravili)

Optimalizace až na konec – už bylo řečeno, ale je potřeba opakovat do zblbnutí ;)

Není jen jeden správný způsob – Snažte se vymyslet různá řešení a vyberte nejlepší ne to první. Nespadněte do pasti prvního návrhu. Nebojte se vymyslet spoustu návrhů a ty ohodnotit.

Navrhujte pro budoucnost – Nechte si otevřená vrátka pro budoucí rozšíření (datových formátů a struktur, protokolů i funkcí). Zde se třeba poznamenat, že váš program se může hodně rozšířit a pak už se zpětně nekompatibilní změny neprovádí bezbolestně.