sobota 24. ledna 2009

Jeden krok dál

Přemýšlel jsem se o tom, proč mi v psolední době chybí nějaký ten nápad na článek a došlo mi, že se můj život vraci zase do normálu. Už zase musím jísti všední chléb a ten je jako každý jiný o dvouch kůrkách. Hodně developerů by chtělo býti architekty a věřte mi, že hodně architkettů by chtělo být opět zase developery a když se jim to alespoň na chvíli povede, tak z toho mají nespoutanou radost. Za ten rok a půl práce architekta jsem se naučil vnímat svět develpomentu úplně jinak, než tomu bylo v čase, kdy má rozhodnutí ovlivňovala pouze omezenou množinu problémů.

Povolání kodera, bušiče, developera či programátora je mnohem svobodnější než si kolikrát uvědomuje. V uvozovkách řečeno, to co si developer nadrobí, to se dá skoro vždy nějak zrefaktorovat či opravit. Architektonická rozhodnutí mají daleko širší dopad. Chyba developera je defekt v Bugzille s životností pár dní, chyba architekta je problém táhnoucí se měsíce či léta. Develperkouká na svůj problém jakoby klíčovou dírkou, ale architekt musí vidět celý rámec daného problému.

Nedávno jsem dělal review analýzy, mimochodem výborně zpracované, která řešila konfigurační komponentu. Úkolem developera je tuto komponentu navrhnout a úkolem architekta je zajistit, že to bude zapadat do celého rámce produktu a to s výhledem do budoucnosti.

Měřeno viditelnou prací, to co děla architekt není vidět nebo lépe žečeno její výsledky jsou v krátkém horizontu těžko měřitelné. Dlouhou dobu mě to trápilo. Developer se po dni stráveném v práci může ohlédnout a vidí svou práci reálně zhmotněnou - fungující test, část kódu. Je to podobné jako ve stavebnictví, práce po stavařích je vidět skoro hned a to i v případě, že se jedná o dílčí výsledky.

Co zůstane po dni strávanem v roli architekta? Dlouhou dobu mi trvalo uvědomit si, že zůstanou rozhodnutí. Jsou to rozhodnutí jejichž dopad je vidět za řádů týdnů a měsiců. Architekt bohužel nemá žádný unitový test, který by validoval jeho rozhodnutí a nebo IDE, které by zkontrolovalo syntaxi. Jediné co může udělat je, že dané rozhodnutí a závěr nechá podrobit kritice někoho jiného.

úterý 20. ledna 2009

Vyšší divčí anotací

Pokud budete v Jave definovat vlastní anotaci, tak asi určitě narazíte na to, že anotace má zvláštní syntaxi a omezení co do objektových typů, které můžete v anotaci použít. To vede k tomu, že ve vlastní anotaci můžete použít i jinou anotaci. Vrchol zápisu aneb to jak může být anotace definovaná jsem zatím viděl v Bean Validation specifikaci (JSR 303). Následující zápis ukazuje jak lze atributy jedné anotace přemapovat na atributy jiné anotace, což považuji za zajímavý případ užití.

@NotNull
@Size
@ConstraintValidator(FrenchZipcodeValidator.class)
@Documented
@Target( { ANNOTATION_TYPE, METHOD, FIELD })
@Retention(RUNTIME)
public @interface FrenchZipcode {
  String message() default "Wrong zipcode";

  Class<?>[] groups() default {};

  @OverridesParameters( {
      @OverridesParameter(constraint = Size.class, parameter = "min"),
      @OverridesParameter(constraint = Size.class, parameter = "max") })
  int size() default 5;

  @OverridesParameter(constraint = Size.class, parameter = "message")
  String sizeMessage() default "{beancheck.zipcode.size}";
}

A účel?

Parameters from composing annotations can be overridden by parameters from the main annotation. The parameter value from the main annotation annotated with @OverridesParameter is applied to the parameter named after OverridesParameter.parameter of the composing constraint of type OverridesParameter. constraint. If not specified, the name of the targeted parameter equals the name of the parameter the @OverridesParameter is on The types of the overridden and overriding parameters must be equals.