čtvrtek 22. května 2008

Effective Java - druhé vydání

Kdo by z javovských programátorů neznal kultovní knihu Effective Java (v českém překladu Java efektivně - 57 zásad softwarového experta,) Joshuy Blocha. Dneska jsem narazil na rozhovor s jejím autorem v rámci letošní JavaOne, který se točil nejen kolem jejího druhého vydání, které bylo rozšířeno vzhledem k syntaktickým a API novinkám Javy 5.

Mě osobně zaujaly dvě poselství, které nám v tomto rozhovoru sděluje.

What is your opinion on the inclusion Closures in Java 7?

As readers of the first edition know, I value simplicity and clarity above all else. So it should come as no surprise that I don't want to see anymore major additions to the Java programming language. It's already as complex as a language should be. If Java programmers want to use features that aren't present in the language, I think they're probably best off using another langauge that targets the JVM, such a Scala and Groovy.

S tímto se naprosto ztotožňuji. No a to druhé...

Every developer should read this book - but some might not be able to make time. For those, if you were to promote just one message from the book what would it be?

Always strive to write simple, clear, and correct programs. It is penny wise and pound foolish to do otherwise. Style does matter. It pays real dividends in terms of correctness, usability, robustness, and maintainability. Also, it's way more fun to write good programs than bad ones.

Jenom ta představa jak někdo píše úmyslně složitý, obfuskovaný a nefunkční kód mě docela rozesmívá. Ale třeba tím chtěl jenom navnadit případně čtenáře, že v druhém vydání najdou odpovědi, jak výše zmíněného dosáhnout...

pondělí 19. května 2008

Před předpisem protřepat

Kolikrát jsem to jenom zažil, jednou, dvakrát, třikrát? Na mou ti duši opravdu nevím, ale bylo to nespočetněkrát. Že nevíte o čem to mluvím? Nevadí, určitě jste takovou situaci zažili, stačí jenom trochu zavzpomínat. Přijdete k nějakému kusu kódu a máte prostě tu neodolatelnou potřebu jej z gruntu přepsat. Nemáte k tomu vlastně ani žádné závažné důvody, kromě toho, že o tom prohlásíte, že je to kus nepoužitelného exkrementu, který ten břidil před vámi pěkně zprasil. Je to úchylka eufemisticky nazvaná nemoc z povolání. Jste přece programátoři a ti musí stavět a to nejlépe na zelené louce.

Tak až vás to zase popadne, tak si přečtěte článek Joela Spolskyho Things You Should Never Do, Part I, který je sice datem vydání osm let starý, ale obsahem nadčasový (tímto zároveň prosím své kolegy ať mi pošlou výše uvedený link, až mě to zase chytne).

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It's harder to read code than to write it.

...When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Ten článek opravdu doporučuji přečíst. No a jaké máme možnosti, když ne všechno to přepsat? Opět si pomůžu jedním článkem a to konkrétně 3 Options for Rebuilding Your Software Without Risking Death. Ony tři možnosti jsou ve zkratce:

  • Prototype and expand
  • Incremental
  • Buy

a kterou z nich preferujete vy? Já vzhledem k těm pár prototypům, co byly za nevelké libosti jejich vývojářů převedeny do produkce, se tak nějak intuitivně přikláním k možnosti inkrementálního nahrazeni.

In the incremental approach, you replace big components of your software with more modern components, or you refactor the existing code. However, you do this in a series of steps that leave you with a releasable and saleable product after each step. This is often compared to "rebuilding the plane in the air".

Na závěr bych rád dodal, že tímto článkem nezastávám názor, že v některých případech není kompletní přepis tím nejlepším řešením. Takže když přepis, tak všeho s mírou...

neděle 18. května 2008

Ještě více statická

Ač jsem velkým příznivcem dynamických jazyků namísto násilného, alespoň z mého pohledu, rozšiřování Javy, tak jsou návrhy, které mají moje sympatie. Jedním z nich je JSR 308: Annotations on Java Types, které se snaží rozšířit možnost deklarace anotace u libovolného užití typu.

JSR 308 proposes an extension to Java's annotation system that permits annotations to appear on nearly any use of a type. (By contrast, Java SE 6 permits annotations to appear only on class/method/field/variable declarations; JSR 308 is backward-compatible and continues to permit those annotations.) Such a generalization removes arbitrary limitations of Java's annotation system, and it enables new uses of annotations

Díky tomuto jazykovému rozšíření by bylo možné vytvořit například velice silný anotační procesor pro pokročilou kontrolu typových informací. Nejlépe to ilustruje následující příklad.

01   @NonNullDefault  
02   class DAG {
03 
04       Set<Edge> edges;    
05 
06       // ...
07 
08       List<Vertex> getNeighbors(@Interned @Readonly Vertex v@Readonly 
09           List<Vertex> neighbors = new LinkedList<Vertex>();
10           for (Edge e : edges)    
11               if (e.from() == v)                          
12                   neighbors.add(e.to());      
13           return neighbors;      
14       }
15   }

(pozn: samotné anotace nejsou součástí specifikace viz vysvětlení)

  • Anotace @NonNullDefault na rádku 1. ríka, že žádná z proměnných třídy nesmí být null. To se týká rádku 4, 10, 11, 12. Zároveň návratový typ metody getNeighbors nesmí být null.
  • Dve anotace @Readonly na rádku 8. garantují, že argument metody v nebude modifikován resp. že stav objektu se nebude měnit při volání metody getNeighbors.
  • Anotace Interned použitá na rádku 8. říká, že použití operátoru rovnosti objektu na řádku 11. je validní.

Toliko k sémantice anotací a teď si představte, že kompilátor vám všechny tyto restrikce hlídá. Jak je muže hlídat? Právě díky tomu, že můžete anotace vůbec na tato místa (další príklady umístení) umístit. Potom už stačí napsat vhodný anotační procesor, který anotace ohlídá a zavěsit jej do kompilátoru.

V této souvislosti doporučuji k nahlédnutí velice zajímavou prezentaci Preventing bugs with pluggable type-checking, která ukazuje možnosti otevřené touto specifikací. Samozřejmě, že využití pro takto širokou deklaraci anotací by se našlo více, například mě napadá dokumentace API.

Jedním z aspektu, které by toto rozšíření použití anotací přineslo, by zajisté bylo zvýšení komplexnosti kódu a vetší přiklonění k statické straně (síly ;-). Na druhou stranu, u kterého z dalších rozšíření syntaxe platí, že je možné jej jednoduše ignorovat, pokud chcete. Pro me osobně je příklad s rozšířenou typovou kontrolou na úrovni kompilace velice silným argumentem pro tento návrh.

Související články