úterý 11. září 2007

Deset rad jak psát kód efektivně

NkD má tezi o tom, že dneska již neprogramujeme, ale spojujeme dohromady pouze části frameworků, které napsal někdo jiný. Do jisté míry s tím lze souhlasit a já osobně na tom nevidím nic divného, každopádně v poslední době jsem strávil nezvykle množství času vlastním kódováním. Při té příležitosti mě napadlo se s vámi podělit o oblíbené rady a postupy, které se mi osvědčily. Nechci úplně papouškovat Joshe Blocha a jeho Effective Java, takže pokud se vám tato kniha nedostala do ruky, pak ji vřele doporučuji.

1.) Null object

Null object též řečený Active nothing je návrhový vzor, který částečně oprošťuje kód od ošetření null referencí.

2.) Inversion of Control a Dependency injection

Mám pocit, že Inversion of Control a Dependency injection (popis) jsou vnímány vývojáři hodně kontroverzně. To je částečně dáno dřívější nutností vyjadřovat závislosti v XML, ovšem moderní IoC kontejnery umožňují i další způsoby např. anotace. Každopádně pokud přijmete tento přístup při tvorbě API za vlastní neradi jej opouštíte.

3.) Neměnitelné třídy

Neměnitelné alias immutable třídy nedovoluji na instanci změnit její stav, který je nastaven během inicializace. Pěkně se o nich rozepsal Lukáš Křečan ve spotu Neměnitelné třídy. Ne všechny třídy lze pojmout jako neměnitelné, ale je dobré se nad tím minimálně zamyslet.

4.) Programování rozhraním

Další prubířský kámen mezi vývojáři. Je zvláštní jak každý ve svém API vystavuje java.util.List či java.util.Map namísto jeho implementace, ale pokud má stejný přístup aplikovat i pro své třídy, pak se začíná cukat. Já osobně raději programuji rozhraním protože je to trochu více konzistentní z hlediska budoucnosti a párkrát se mi to už vyplatilo. Z mého pohledu je rozhraní více striktnější z hlediska designu API, protože člověk nesklouzává k implementačním detailům.

5.) Open/Closed princip

Kombinaci protected metod a final public metod jsem okoukal ze Spring frameworku. Třídy, které mohou být potenciálně rozšiřitelné definují chování pomocí veřejných neměnitelných metod, potomek může překrýt protected metody a rozšířit (nikoliv změnit) chování předka. Přesně v duchu myšlenky Open/Closed principu - software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

6.) Runtime výjimky

Zkoušeli jste zjistit kolik výjimek ve vašem API musí být kontrolovaných? Ve většině API to nebylo více jak 20%, 80% připadal na výjimky běhové. Při tvorbě API zakládám skoro jako první věc hierarchii výjimek, tím se vyhýbám zbytečným změnám, když výjimky přetečou mimo kontrolu. Celkem dobrým přístupem pro určitý typ běhových výjimek je Deklarovaná runtime výjimka. No a samozřejmě nesmím zapomenout fault barieru.

7.) Kontrolujte argumenty metod

Bolí to, ale funguje to. Pokud si nechcete vytvářet vlastní sadu programových kontrol, použijte například třídu Validate z balíku Jakarta Commons Lang či Springovskou org.springframework.util.Assert, pokud nevadí závislost na Spring API.

8.) Neopakujte se

Tomáš Záluský mi kromě jiných mouder předal jedno, které se mi vždycky aktivuje jaksi automaticky. Pokud se někde v kódu objevuje na vice místech jeden a ten samý kus kódu, něco není v pořádku a programátorovi by se měla v hlavě rozsvítit červená kontrolka. Jeden ze způsobů jak neopakovat kód je popsán v článku Návrhový vzor Template method a jeho aplikace v prostředí JDBC.

9.) Dokumentujte poctivě

Pokud vám někdo tvrdí, že dobře napsaný kód se dokumentuje sám, pak si o něm můžete myslet tři věci.

  • dělá si z vás srandu a zkouší vaší reakci
  • v životě nenapsal API, které by používal někdo jiný
  • pravděpodobně je to diletant a nebo chorobný optimista

Pište javadoc, pište interni komentáře uvnitř kódu, uveďte nějaký příklad použití daného API, případně nalinkujte UML schéma. To všechno jsou informace, které jsou velice cenné pokud pracujete nejen v týmu.

10.) Nebojte se refaktoru

Refaktoring je úžasný přístup k tomu, aby váš kód nezahnil špatnými rozhodnutimi a hacky. Bohužel to do jisté míry stojí na faktu, že máte k dispozici testy. Ale možná právě proto je to o důvod více proč psát testy. Takže kromě brutálních refaktoru půlky code base se uchylujte i k menším akcím jako extract method, extract local variable. Kód bude lépe čitelný a pochopitelný.