Zásady vývoje softwaru jsou souborem konkrétních pravidel a doporučení, kterými by se měli inženýři řídit při realizaci programu, pokud chtějí psát krásný, přehledný a udržovatelný kód. Neexistuje žádná kouzelná hůlka, která by změnila změť proměnných, tříd a funkcí v dokonalý kód, ale existuje několik tipů a rad, které mohou inženýrovi pomoci určit, zda postupuje správně.
Podívejme se na tato základní doporučení. Některé z níže uvedených zásad jsou specifické pro Python, ale většina z nich není.
Dvakrát měř a jednou řež
Myslím, že to je nejdůležitější zásada ze všech. Pokud se z tohoto příspěvku naučíte jen jednu zásadu, měla by to být právě tato. My, vývojáři /architekti/ manažeři, lidé bojujeme s nedostatkem pozornosti, hloupými chybami a překlepy, osobními problémy, špatnou náladou a studenou kávou. Nic z toho není podstatné – problém je třeba vyřešit. Pro mě jako inženýra tento princip znamená volbu správného řešení problému, volbu správného přístupu k problému, volbu správných nástrojů k řešení problému, důvěru ve vybudované řešení. Vybrat zde znamená zamyslet se, najít potřebné zdroje, sestavit správný tým, promyslet návrh, promyslet přístup, stanovit úkoly, kontrolovat výsledek a nést za něj odpovědnost. To je „inženýrství tak, jak je“. Myslím, že sám nejsem připraven to popsat správnými slovy.
Neopakuj se (DRY)
Je to poměrně jednoduchá, ale velmi užitečná zásada, která říká, že opakovat stejnou věc na různých místech je špatný nápad. Především to souvisí s nutností další podpory a úpravy kódu. Pokud se nějaký fragment kódu opakuje na několika místech uvnitř programu, existuje vysoká pravděpodobnost dvou katastrofických situací:
- Při provádění i drobných změn ve zdrojovém kódu je třeba změnit stejný kód na několika místech. To bude vyžadovat další čas, úsilí a pozornost(často to není snadné).
- První bod následuje po druhém. Vy nebo jiný vývojář z vašeho týmu můžete omylem přehlédnout některou ze změn(může se to stát jednoduše sloučením větví ve vcs) a čelit následným chybám v aplikaci. Tyto chyby pro vás mohou být frustrující, protože jste slyšeli, že taková chyba již byla opravena.
V této souvislosti existuje doporučení – pokud se nějaký kód nachází ve výpisu více než dvakrát, měl by být umístěn samostatně. Jedná se o obecné doporučení. Ve skutečnosti byste měli přemýšlet o vytvoření samostatné metody i v případě, že se opakování vyskytne podruhé.
Occamova břitva
Jedná se o velmi rozšířenou myšlenku, která do programování přišla z filozofie. Princip dostal své jméno podle anglického mnicha Williama z Oakhamu. Tento princip říká: „Entity se nemají množit bez nutnosti“. V inženýrství se tato zásada vykládá takto: Není třeba vytvářet zbytečné entity bez nutnosti. Proto je vždy dobré se nejprve zamyslet nad přínosem přidání další metody/třídy/nástroje/procesu atd. Koneckonců, pokud přidáte další metodu/třídu/nástroj/proces atd. a nezískáte žádné výhody kromě zvýšené složitosti, jaký to má smysl?
Keep It Simple Stupid (KISS)
Tato zásada je velmi podobná výše uvedené, ale má trochu jiný význam. Tato zásada říká, že kód musí být co nejjednodušší, bez složitých struktur, jinak komplikuje ladění a údržbu kódu. Kromě toho bude pro jiného programátora obtížnější pochopit logiku kódu, což ve svém důsledku také bude vyžadovat další čas a úsilí. Proto byste se měli vždy snažit používat jednoduché konstrukce, které řeší problém pokud možno bez četných větvení, hlubokého vnořování a nadměrně přetížených struktur tříd. Tím usnadníte život sobě i svým kolegům, protože složitost generuje chyby. Vzpomeňte si, co řekl Peter Hintiens: „
You Aren’t Gonna Need It (YAGNI)
Problém, kterým trpí mnoho programátorů. Touha implementovat najednou všechny potřebné (a někdy i nepotřebné) funkce hned na začátku projektu. To znamená, když vývojář hned na začátku přidá do třídy všechny možné metody, implementuje je a v budoucnu je možná ani nikdy nepoužije. Podle tohoto doporučení tedy nejprve implementujte jen to, co potřebujete, a později, pokud je to nutné, funkcionalitu rozšiřte. Ušetříte si tak námahu, čas i nervy na ladění kódu, který ve skutečnosti není potřeba.
Předtím, než začnete vyvíjet funkcionalitu, měli byste se nejprve zamyslet nad architekturou aplikace a navrhnout celý systém do dostatečně malých detailů, a teprve potom přistoupit k implementaci podle předem stanoveného plánu. Princip má právo na existenci, ale v poslední době se na něj snáší poměrně velká kritika. Souvisí to především s neaktuálností plánu při návrhu a rozpracování. V této souvislosti je nutné provést ještě následné změny. Má však i nesporné výhody, při správném projektování je možné výrazně snížit náklady na další ladění a opravy chyb. Kromě toho jsou takové informační systémy zpravidla lakoničtější a architektonicky správnější.
Vyhněte se předčasné optimalizaci
„Předčasná optimalizace je kořenem všeho zla (nebo alespoň většiny) v programování.“ – Donald Knuth
Optimalizace je velmi správný a nutný proces pro zrychlení programu i pro snížení spotřeby systémových prostředků. Vše má však svůj čas. Pokud se optimalizace provádí v raných fázích vývoje, může napáchat více škody než užitku. Především to souvisí s tím, že vývoj optimalizovaného kódu vyžaduje více času a úsilí na vývoj a podporu. V tomto případě je poměrně často nutné nejprve ověřit správnost zvoleného vývojového přístupu. Proto je zpočátku výhodnější použít jednoduchý, ale ne nejoptimálnější přístup. A později, když odhadnete, jak moc tento přístup zpomaluje práci aplikace, přejít na rychlejší nebo na zdroje méně náročný algoritmus. Navíc po dobu, kdy zpočátku implementujete nejoptimálnější algoritmus, se mohou požadavky změnit a kód půjde do koše. Není tedy třeba ztrácet čas předčasnou optimalizací.
Principle Of Least Astonishment
Tato zásada znamená, že váš kód by měl být intuitivní a zřejmý a neměl by překvapit jiného vývojáře při kontrole kódu. Pokud se například metoda jmenuje „výroba sušenek“, ale jako výsledek dostanete brambory, je takový kód (samozřejmě) špatný. Kromě toho byste se měli snažit vyhnout vedlejším efektům a dokumentovat je, pokud se jim nemůžete vyhnout.
S.O.L.I.D.
„SOLID“ je vlastně skupina zásad objektově orientovaného návrhu. Každé písmeno ve slově „SOLID“ představuje jeden z principů, kterými jsou:
- Jediná odpovědnost uvádí, že každý modul nebo třída by měla mít odpovědnost za jedinou část funkčnosti poskytované softwarem a tato odpovědnost by měla být zcela zapouzdřena třídou;
- Otevřená-uzavřená uvádí, že softwarové entity (třídy, moduly, funkce atd.) by měly mít odpovědnost za jedinou část funkčnosti poskytované softwarem.) by měly být otevřené pro rozšíření, ale uzavřené pro modifikaci;
- Liskova substituce říká, že zděděná třída by měla doplňovat, nikoliv nahrazovat chování základní třídy;
- Segregace rozhraní říká, že žádný klient by neměl být nucen záviset na metodách, které nepoužívá;
- Inverze závislostí říká, že programátor by měl pracovat na úrovni rozhraní a ne na úrovni implementace.
Při společné aplikaci těchto principů pomáhají vývojáři vytvářet kód, který lze snadno udržovat a časem rozšiřovat.
Zákon Demeter
Základní myšlenkou tohoto principu je rozdělit oblasti odpovědnosti mezi třídy a zapouzdřit logiku uvnitř třídy, metody nebo struktury. Z tohoto principu lze vyčlenit několik doporučení:
- Třídy nebo entity by měly být nezávislé
- Měli byste se snažit snížit počet vazeb mezi různými třídami (tzv. coupling).
- Spojené třídy musí být v jednom modulu/balíku/adresáři (tzv. koheze)
Při dodržení těchto zásad se aplikace stane pružnější, srozumitelnější a snadno udržovatelná.
Závěr
Kamarádi vývojáři, buďme inženýři! Přemýšlejme o návrhu a budujme robustní a dobře implementované systémy, místo abychom pěstovali organická monstra. Uvedené principy jsou ve své podstatě vysoce korelované a propojené. Samozřejmě jsem je nevytvořil já, ale malé připomenutí neuškodí, alespoň moje paměť rozhodně není dokonalá.
Doporučené knihy
- Čistý kód od Roberta C. Martina
- Čistá architektura od Roberta C. Martina
.