Proč?

Poté co prohlížeč přijme data z formuláře, vygeneruje novou stránku. Pokud by na ní uživatel stisknul v prohlížeči tlačítko „refresh“, pokusil by se prohlížeč znovu odeslat jednou už odeslaná data. Protože to je nestandardní operace, browser se uživatele zeptá, jestli si to opravdu přeje, ale řekněme si upřímně – kolik uživatelů si to vůbec přečte? A kolik z nich chápe, o co se jedná?

Jestliže místo vygenerování stránky uděláte redirect na REST URL (tzv. „POST / Redirect / GET pattern“), nemusíte se o tlačítka jako je „back“ nebo „refresh“ více starat – alespoň v souvislosti s odesíláním formulářů.

Jak?

Udělat serverový redirect je triviální, ale často se chybuje v HTTP kódu. Jediný správný HTTP kód pro tento redirect je 303 „See Other“. Bohužel, jak praví dokumentace, „Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.“

Pokud tedy počítáte i se staršími browsery (např. Netscape 4), použijte kód 302 a doufejte, že ho někdo v budoucnu nenaimplementuje správně – pak by totiž kód 302 nepřešel na GET, ale zopakoval by POST, což by byla docela katastrofa.

Všechny současné browsery by však 303 měly umět, takže pokud zrovna neděláte stránky pro muzeum prohlížečů, můžete ho s klidem a bez rizika používat.

Platí to vždy?

Každé pravidlo má svoje výjimky. Určitě se může vyskytnout situace, v jaké by mohlo být opakované odeslání
POSTu výhodné, ale v praxi jsem se s takovou situací zatím nesetkal. Jestli jste se s takovým případem setkali, napište o něm v komentářích.

Již od svého založení roste naše společnost každoročně o více než polovinu – jedinou výjimkou byl rok 2009, postižený světovou ekonomickou krizí. Za mimořádnými výsledky stojí především snaha o dlouhodobé, oboustranně přínosné vztahy se zákazníky a týmy kvalitních, velmi oceňovaných specialistů společnosti.

Na našem projektu Starthead používáme pro unit testy embedded databázi HSQLDB (Spring nám dává jednoduchou podporu pro využívání embedded databází HSQLDB, H2 nebo DERBY). Ovšem podpora jazyka PL/SQL je v této i dalších embedded databázi téměř nulová. Přesto jsme ale potřebovali nějak otestovat jednu část kódu používající uloženou funkci.
Pokud se podíváme do dokumentace HSQLDB najdeme sice podporu procedur a funkcí v rámci SQL/PSM (Persistent Stored Modules), což nám v některých případech může stačit. Ve spoustě případů ovšem ne. A právě zde přichází na řadu podpora SQL/JRT, tedy SQL Routines and Types for the Java Programming Language. JRT nám dovoluje místo vytváření procedur a funkcí registrovat statické metody psané v jazyce Java, které poté budou volány na pozadí místo daných procedur, případně funkcí.

Dost bylo nudné teorie, pojďme se podívat na jednoduchý příklad, který celý princip osvětlí.

V aplikaci máme jednoduchou uloženou funkci, která například počítá průměr ze dvou čísel a vrací výsledek (berme to opravdu jen jako triviální případ pro vysvětlení principu). Naše funkce je psaná pro databázi MySQL.

CREATE FUNCTION average (a INT, b INT)
  RETURNS  DOUBLE
   DETERMINISTIC
    BEGIN
     DECLARE sum DOUBLE;
     SET sum  = (a + b) / 2;
     RETURN sum;
    END

Nyní musíme tuto metodu převést do jazyka Java, aby poté mohla nahradit stejnou funkcionalitu v embedded databázi.

package com.aspectworks;
public class EmbeddedFunction{
  public static double average(int a, int b){
    return (a + b) / 2;
  }
}

Posledním krokem je registrace metody napsané v Javě pro volání funkce average v embbeded databázi. (Toto řešení je možné použít v HSQLDB 2.0 a vyžší. Nižší verze měli podporu aliasů, které fungovali na podobném principu.)

CREATE FUNCTION average (a INT, b INT)
  RETURNS CHAR  DOUBLE
  LANGUAGE JAVA DETERMINISTIC NO SQL
  EXTERNAL NAME 'CLASSPATH:com.aspectworks.EmbeddedFunction.average'

Pokud nyní v unit testech zavoláme sql dotaz, který používá tuto average funkci, na pozadí se provede vykonání metody average ve třídě EmbeddedFunction s danými parametry a jako výsledek se použije návratová hodnota metody. Jako návratová hodnota může být použita i tabulka, Java metoda poté musí mít návratový typ java.sql.ResultSet. Vnitřní chování převolávání takovéto metody se poté liší. Podrobně a srozumitelně je to popsáno v dokumentaci Java Language Routines (SQL/JRT).

Nevýhodou tohoto řešení je nutnost udržovat společně s uloženou funkcí i metodu v dané třídě. Nechám už na posouzení každého, jestli je jednodušší použít toto řešení nebo pro testování použít některou z databází podporující jazyk PL/SQL.
Uvítám vaše názory na tento způsob řešení, případně napište, jakým způsobem testujete uložené procedury a funkce vy.

Pár odkazů:
http://hsqldb.org – HSQLDB databáze
http://en.wikipedia.org/wiki/SQL/JRT – popis JRT

Implementace takového mechanismu přímo na DAO vrstvě by byla pracná a hlavně složitě konfigurovatelná. Řešení žurnálování na úrovni databázových procedur a triggerů by zase zrušilo nezávislost aplikace na konkrétním typu databáze. Hibernate pro žurnálování nabízí zajímavou funkčnost interceptor pro zachycení a zpracování různých událostí, jako například databázové CRUD operace.

Vycházím z příkladu použití interceptoru na audit log (žurnál) a samozřejmě ze samotné dokumentace http://docs.jboss.org/hibernate/core/3.3/reference/en/html/events.html

Po menší modifikaci lze uvedený příklad použít i na žurnálování starých a nových hodnot. Vytvořímě si entitu AuditLogData pro ukládání změněných hodnot a přidáme ji do entity AuditLog.

@Entity @Table(name = "auditlog", catalog = "mkyong")
public class AuditLog implements java.io.Serializable {
private Long auditLogId;
private String action;
private String detail;
private Date createdDate;
private Long entityId;
private String entityName;
@OneToMany() @JoinColumn (name = "auditLogId") @OrderBy("propertyName")
privateList auditLogData;
...
}

@Entity @Table(name = "auditlogdata", catalog = "mkyong")
public class AuditLogData implements java.io.Serializable {
private Long auditLogDataId;
private String propertyName;
private String oldValue;
private String newValue;
...
}

Při ukládání záznamu budeme pracovat přímo se záznamem AuditLog třídy a ne pouze s entity.

public boolean onFlushDirty(Object entity,Serializable id,
                Object[] currentState,Object[] previousState,
                String[] propertyNames,Type[] types)
                throws CallbackException {
                ...
   if (entity instanceof IAuditLog){
       AuditLog auditRecord = new AuditLog("Updated“,entity.getLogDeatil(), new Date(),entity.getId(), entity.getClass().toString());
       fillChangedData(auditRecord, previousState,  currentState, propertyNames, entity);
	 //Add the auditLog to be saved as update after commit of transaction
       updates.add(auditRecord);
   }
   return false;
}

Kde plnění změněných dat by mohlo vypadat přibližně následovně:

private void fillChangedData(AuditLog auditLog, Object[] startState, Object[] endState, String[] propertyNames, Object newObject, Long persistedObjectId)
           throws IllegalArgumentException, IllegalAccessException, InvocationTargetException {
        //check input parameters
        …
        for (int i = 0; i < propertyNames.length; i++) {
            //check if the property has been changed
            if (propertyValueChanged(startState[i], endState[i])) {
                // property changed, add it to auditLog.auditLogData list
                final String pn = propertyNames[i];
                String valueOld = propertyValueToString(startState[i]);
                String valueNew = propertyValueToString(endState[i]);
                addDataToAuditLog(auditLog, pn, valueOld, valueNew);
            }
        }
    }

Jak je na příkladu vidět, Hibernate interceptor je mohutný nástroj, který umožňuje na aplikační úrovni nejen odchytávat operace nad databází, ale i dále zpracovávat jejich data.

Zde popisované řešení je trochu jiné v tom, že je definované obecné API pro naplánování asynchronního zpracování. Motivací bylo umožnit asynchronní procesing handleru bez nutnosti statické konfigurace Quartz jobu pro každý takový handler. Pro každou naplánovanou úlohu je použit společný Quartz job, který v okamžiku vyvolání vyhledá požadovaný handler ve Spring contextu a spustí jej. Přidání nového handleru, nového typu úlohy kterou chceme asynchronně spouštet, pak nevyžaduje žádné další konfigurační změny Quartz scheduleru, pouze konfiguraci nového beanu ve Spring kontextu.

Pro vyvolání metody na Spring beanu již existuje MethodInvokingJobDetailFactoryBean, jenže tento způsob neumožňuje předat metodě parametry. Navíc i zde je potřeba mít pro každý bean nakonfigurovaný vlastní trigger. V našem scénáři nechceme pro každý springový bean definovat nový trigger, pouze definujeme a nakonfigurujeme univerzální scheduler vrstvu. Popsané řešení je sice závislé na Springu, nicméně klientský kód je oddělený interfacem, takže není až takový problém vytvořit implementaci, která Spring používat nebude.

Implementace

Celý mechanismus je skrytý za API, které tvoří 2 třídy:
-SchedulerDAO – určeno pro přístup z business logiky, pomocí tohoto interfacu se naplánuje asynchronní zpracování
-Task – rozhraní, které musí naimplementovat handler, který chceme asynchronně spouštět

public interface SchedulerDAO {
    /**
     * Schedule task for asynchronous processing.
     * @param taskClass task that is about to be executed asynchronously
     * @param properties data to be passed to the task
     */
    <T extends Task> void schedule(Class<T> taskClass, Properties properties);
}

public interface Task {
    /**
	 * run scheduled action
	 * @param properties data the task was scheduled with
	 */
	void run(Properties properties);
}

Jednoduchá implementace SchedulerDAO může vypadat takto:

public class SimpleSchedulerDAO implements SchedulerDAO {
	//...instance variables omitted..
    public SimpleSchedulerDAO(Scheduler scheduler, String jobName, String jobGroup, String classNameProperty) {
        this.scheduler = scheduler;
        this.jobName = jobName;
        this.jobGroup = jobGroup;
        this.classNameProperty = classNameProperty;
    }
    public <T extends Task> void schedule(Class<T> taskClass, Properties properties) {
        JobDataMap jobDataMap = new JobDataMap(properties);
        //todo validation that classNameProperty not present in passed properties
        jobDataMap.put(classNameProperty, taskClass.getName());
        try {
            scheduler.triggerJob(jobName, jobGroup, jobDataMap);
        } catch (SchedulerException e) {
            throw new RuntimeException(e);
        }
    }
}

Navržená implementace naplánuje jeden univerzální job, společný pro všechny Task implementace. Pokaždé je vytvořen nový trigger, který je okamžitě naplánován ke spuštění. Složitější implementace může např. získávat instanci triggeru pomocí trigger factory, kde bude vyřešena různá konfigurace triggeru pro různé typy handlerů.
Důležité je, že do persistentních dat daného triggeru (jobDataMap) se uloží název třídy/interface, který chceme asynchronně spustit. Tj. název třídy, která byla jako parametr předána metodě schedule(..). V okamžiku, kdy Quartz vyvolá takto vytvořený trigger, se podle uloženého názvu třídy vyhledá Springový bean, který chceme zavolat (viz dále). Třída jobu je konfigurovatelná, stejně jako název skupiny a klíč, pod kterým je uložený persistovaný název třídy.

Ukázková konfigurace Spring contextu:

<bean id="simpleSchedulerDAO" class="com.aspectworks.example.scheduler.impl.SimpleSchedulerDAO">
   <constructor-arg index="0" ref="scheduler"/>
   <constructor-arg index="1" value="taskExecutorJob"/>
   <constructor-arg index="2" value="taskGroup"/>
   <constructor-arg index="3" value="@className"/>
</bean>
<bean name="taskExecutorJob" class="org.springframework.scheduling.quartz.JobDetailBean">
   <property name="jobClass" value="com.aspectworks.example.scheduler.impl.TaskExecutorJob"/>
   <property name="group" value="taskGroup"/>
</bean>
<bean id="scheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean" destroy-method="destroy">
   <property name="jobFactory">
      <bean class="org.springframework.scheduling.quartz.SpringBeanJobFactory"/>
   </property>
   <property name="applicationContextSchedulerContextKey" value="applicationContext"/>
   <property name="schedulerContextAsMap">
      <map>
	     <entry key="classNameProperty" value="@className"/>
	  </map>
   </property>
   <property name="jobDetails">
      <list>
	     <ref bean="taskExecutorJob"/>
      </list>
   </property>
</bean>

V konfiguraci je vidět název třídy společného Quartz jobu – TaskExecutorJob, který je spouštěn všemi triggery. Job se chová tak, že podle názvu interface uloženého v persistentních datech triggeru nalezne Springový bean, a na něm spustí metodu run(). Za zmínku stojí ještě čtvrtý parametr konstruktoru SimpleSchedulerDAO, jedná se o název klíče, pod kterým bude v persistentních datech triggeru uložen název třídy Spring beanu, zde tedy hodnota "@className". V implementaci SimpleSchedulerDAO je vhodné dodělat kontrolu, že předané properties neobsahují klíč, který by kolidoval s hodnotou classNameProperty, a ještě lépe tuto hodnotu pevně stanovit a zdokumentovat v API.
Na závěr tedy ještě implementace samotného jobu, zde se vyhledá a spustí naplánovaný handler.

public class TaskExecutorJob implements Job{
    private String classNameProperty;
    private ApplicationContext applicationContext;
    public void execute(JobExecutionContext context) throws JobExecutionException {
	    //read class from persisted data
        Class taskClass = readClass(context, classNameProperty);
		//lookup bean instance
        Task task = lookupJobBean(taskClass);
        if (task != null) {
            Properties properties = new Properties();
            properties.putAll(context.getTrigger().getJobDataMap());
            properties.remove(classNameProperty);
			//finally execute the target task
            task.run(properties);
        }
    }
    /**
     * read persisted Task class name from trigger's jobDataMap
     */
    protected  Class readClass(JobExecutionContext context, String beanClassKey) {
        String beanClassName = context.getTrigger().getJobDataMap().getString(beanClassKey);
        try {
            if (beanClassName != null){
                return (Class) Class.forName(beanClassName);
            }
        } catch (ClassNotFoundException e) {
            //log error
        }
        return null;
    }
    /**
     * lookup Task implementation from Spring context
     */
    protected  T lookupJobBean(Class clazz){
        if (clazz != null){
            try {
                return applicationContext.getBean(clazz);
            } catch (BeansException e) {
                //log error
            }
        }
        return null;
    }
}

Možné nevýhody

Existuje zde ovšem také jeden nedostatek. Klientský kód je sice oddělený dvěma rozhraními (Task a SchedulerDAO), nicméně popsané řešení je orientované na Spring framework a toto má jeden dopad: je potřeba, aby handler, který chceme asynchronně spouštět, definoval nové rozhraní rozšiřující interface Task. Například takto:

public interface TestingTask extends Task{
}
public class TestingTaskImpl implements TestingTask {
    public void run(Properties properties) {
      //do something..
    }
}

Nelze definovat přímo implementaci interface Task a tuto se snažit naplánovat přes SchedulerDAO. Jde o to, jak funguje Springový lookup BeanFactory.getBean(Class requiredType): pokud Spring pro AOP používá jdk proxy, nebude možné provést lookup Spring beanu podle jeho implementace, pouze podle interface. Dále je nutné, aby v kontextu byla registrovaná od každého tohoto rozhraní pouze jedna implementace. Popsané řešení by bylo možné změnit např. tak, že scheduling nebude probíhat na základě rozhraní handleru, ale pomocí jména beanu. Toto by ovšem do kódu zaneslo mnohem větší závislosti na Spring frameworku.

Budu rád, pokud se podělíte se svými názory, či jste třeba řesili něco podobného, nebo zda v tom vidíte nějaké problémy.

Ukázkový funkční příklad si můžete stáhnout zde: quartz-example.zip

Agilní manifest je dostupný v češtině.

Slyšeli jste už termín death-by-Powerpoint? Garr Reynolds píše o Slideuments, anti-pattern míchání slajdů a dokumentů do jednoho.

Martin Fowler sepsal článek New Methodology , ve kterém se věnuje agilnímu vývoji. Mimo jiné se zamýšlí nad tím, že zatímco ve stavením inženýrství zabere návrh asi 10% rozpočtu, tak v softwarovém inženýrství je to naopak téměř většina. Softwarový vývoj je kreativní činnost, a proto se těžko předvídá a plánuje.

Lidé nejsou zdroj, lineární proměnná, ačkoliv se tak s nimi v softwarovém inženýrství často počítá – Characterizing people as non-linear, first-order components in software development

Stanford University pořádá on-line kurz kryptografie, zdarma. Právě začal, tak si pospěšte, ať ještě stihnete domácí úkoly. Seznam všech kurzů naleznete na https://www.coursera.org

Jediným správným měřítkem kvality kódu je WTF za minutu.

Open space kanceláře mají svá úskalí, Dilbert o tom ví své.

Předchozí doporučená četba

Tento kurz se zaměřuje na praktický vývoj a není (jako většina odborných školení) koncipován jako teoretická přednáška. V průběhu tří dnů poznáte a hlavně se naučíte vývoj kompletní aplikace na Springu a Hibernatu. Ze školení si odnesete funkční aplikaci, která se může směle stát základem pro velký projekt.

Agenda školení je následující:

• Spring Core
• Spring AOP
• Spring JDBC
• ORM
• Transactions
• Spring Test
• Spring MVC
• Spring Remoting
• Spring Security

Školit bude Pavel Müller, technický ředitel a hlavní softwarový architekt společnosti AspectWorks, se zkušenostmi z mnoha rozsáhlých projektů za použití Springu. Kromě běžných věcí se tak dozvíte zajímavosti z oblasti architektury systémů, best practices, novinky ve Springu 3.1 a další tipy a triky. Další informace můžete nalézt zde

Dějství první: Plánujeme

User story byla prostá: Umělec nabízí svým fanouškům odměny za to, že přispějí na realizaci jeho projektu. Čím vyšší příspěvek, tím lepší odměny. Měli jsme vyvinout uživatelské rozhraní, které umožní umělci zadat jednotlivé odměny do systému, který je pak zobrazí fanouškům.

Dle hesla “dohnat a předehnat” jsme se rozhodli udělat více než konkurence: tam kde si jiní vystačili s prostým seznamem odměn, máme dva objekty: samotnou odměnu (název a popis), která ovšem nemá cenovku, a balíček, který má cenovku (ale chybí mu název) a obsahuje jednu či více odměn.

Co nás vedlo k takovému zjevnému nesmyslu? Alibismus, v podobě klasické věty „byznys to tak chce“. Věta, která vede ke zkáze, zní „Je to asi nesmysl, ale technicky to není nic složitého, tak to uděláme“. Tento způsob uvažování vede vždy ke katastrofě. Jestliže byznys nedokáže o nezbytnosti něčeho přesvědčit vývojáře, jak o tom chce přesvědčit zákazníky?

Krutou zbraní na straně byznysu je psychologický tlak na efektivitu v podobě osvědčené věty „už o tom kecáme tak dlouho, že za tu dobu byste to měli naprogramované“. To je podpásovka a třeba v tomto konkrétním případě by pár hodin analýzy a diskusí navíc možná ušetřilo stovky hodin vývoje.

Rozhodnutí nakonec opravdu vedlo k obrovskému množství problémů, neboť složitější struktura je obtížnější na pochopení a tím i na ovládání. Na strukturu typu “n x n” nelze použít žádný z osvědčených vzorů UI a ani architektura serverové části nám implementaci neusnadnila. Navíc jsou odměny lokalizované a odměny i balíčky mají stav (schvaluje je moderátor serveru, již schválené odměny a balíčky nelze nadále editovat).

Poučení: Jestliže nevidíte jasnou konkurenční výhodu, udělejte méně než konkurence. Pokud nějaká vlastnost vypadá jako nezbytná, najděte způsob, jak se bez ní obejít, a teprve až ho budete znát, rozhodněte se pro nebo proti.

Dějství druhé: Navrhujeme architekturu

Rozhodovali jsme se mezi dvěma variantami řešení. První varianta předpokládala, že odměny a balíčky odměn se budou spravovat samostatně. Tvůrce si nejdříve nadefinuje, jaké nabízí odměny, a pak je v další obrazovce seskupí do balíčků a dá jim cenovky. Druhá varianta typu “všechno v jednom” předpokládala, že tvůrce vytvoří balíček, a ten bude rovnou plnit odměnami, které si hned na místě vytvoří.

Nejdříve jsme se pustili do první varianty, která vypadala jednodušší. Brzy jsme se však dostali do potíží a navíc se ukázalo, že řešení má vážné vady v oblasti použitelnosti. Uživatel musel stále přecházet z jedné obrazovky do druhé, nechápal co je balíček odměn ani proč odměna nemá cenovku atd.

Prohlásili jsme tedy koncept za neúspěšný a pustili se do druhé varianty. Ta kupodivu docela fungovala, ale občas se tam děly prapodivné věci. Považovali jsme je za drobné potíže, které bude snadné odladit, řešení však už obsahovalo skrytý technologický dluh a navíc nebylo tak docela kompatibilní s architekturou nižších vrstev aplikace. Oprava jednoho problému obvykle odhalila další potíže, práce se táhly zdánlivě do nekonečna.

Poučení: Jestliže všechna řešení, která se nabízí, jsou špatná, nezapomeňte hledat chybu v zadání. Zpochybněte cíle. Snažte se najít to podstatné a ostatního se zbavit. Hledejte taková řešení, která jsou v souladu s dostupnou technologií, neútočte hlavou proti zdi. Proces plánování je bezpochyby nutný a užitečný, hotový plán je však přítěž, která svazuje vaše myšlení. Zbavte se sentimentality a zahoďte plán, když jeho realizace začne váznout. Důležité je dosáhnout cíle, nikoli držet se plánu.

Dějství třetí: Programujeme

Znáte ty části kódu, které sice fungují, ale nikdo neví jak? Pravděpodobně je napsal programátor s pragmatickým přístupem “zbouchám to aby to bylo” a tím vám zadělal na problémy v budoucnu. Jistá dávka pragmatismu je samozřejmě nezbytná, v podstatě ale jde o škodlivý přístup, který do projektu vnáší zbytečná rizika a zvětšuje technologický dluh. Čím větší projekt, tím důležitější je psát kód přehledný a transparentní a vyhýbat se zkratkovitým řešením.

Náš kód od začátku trpěl neduhem pragmatického přístupu. Programátor sestavil controller tak, že sice fungoval, ale dalo opravdu hodně přemýšlení pochopit, jak je to možné. Kodér pak nad tím sestavil javascriptovou aplikaci, jejíž kód byl v podstatě v pořádku, ale měla naprosto tragickou strukturu. Názvy proměnných nedávaly smysl, parametry funkcí a metod se jmenovaly a fungovaly pokaždé jinak. Například pod názvem “id” se někdy skrývalo skutečné databázové id, jindy ale pořadové číslo položky v seznamu a občas i něco úplně jiného. Na nečitenosti kódu se také podepsalo časté používání různých zájmen, hlavně klíčového slova “this”, v kódu.

Neštěstí by asi nebylo tak velké, kdyby si někdo včas všimnul, co se děje. Ale celý tým byl tou dobou pod enormním tlakem, protože projekt se blížil dokončení a kvůli špatně nastavenému rozsahu “hořel” na mnoha místech. Proto tuto funkcionalitu programovali junioři bez jakéhokoli dohledu (“není čas dělat code review”).

Poučení: Kód, který je pochopitelný a čitelný, ale nefunguje, můžete snadno spravit. Kód, který funguje, ale je nepochopitelný, se může kdykoli rozbít a neuděláte s ním nic.
Nejlepší forma boje proti “pragmatickému přístupu” jsou pravidelné code reviews, které by měl vždy provádět vývojář-senior. Zdánlivě jde o ztrátu času, ale pečlivou kontrolou před každým commitem zabráníte mnohem větším nákladům a zdržením v budoucnu.

Dějství čtvrté: Refactoring

Když se po několika sprintech ukázalo, že vývoj definitivně uváznul, sáhli jsme k nepopulárnímu opatření: refactoringu. Refactoring byl velmi bolestný a nakonec trval přibližně dvakrát déle, než jsme původně odhadovali.

Ukázalo se, že hlavní zdroj problémů byl špatně čitelný kód. Většina práce tedy spočívala v přejmenování všech proměnných, funkcí, objektů a metod tak, aby názvy odpovídaly projektovému slovníku. Druhý důležitý krok spočíval v novém rozdělení existujícího kódu do logicky pojmenovaných funkcí, s jasně definovaným rozhraním. Přibylo tak velké množství funkcí, které však byly jednoduché a jednoúčelové, což se později ukázalo jako výhoda.

Jakmile začalo být fungování aplikace zřejmé i z kódu, ukázaly se skryté problémy a zjistili jsme, že některé funkce zcela chybí. Co bylo horší, zjistili jsme také, že stávající řešení nelze správně propojit s naším validačním frameworkem a že je nutné celý front end přepracovat. Naštěstí, vyčištěná struktura umožnila kompletní přepracování celého řešení během jediného sprintu.

Poučení: Je opravdu důležité, jak pojmenujete svoje proměnné. Vytvořte si projektový slovník a přísně ho dodržujte, nejen v běžné řeči a v dokumentaci, ale i v názvech objektů, vlastností a metod, v pojmenování tříd a id v HTML kódu, v pojmenování funkcí v JavaScriptu, v názvech souborů a pojmenování sloupců v databázi… Dbejte na čitelnost názvů, nevytvářejte zbytečně různé zkratky. Pište kód tak, aby ho přečetlo i malé děcko (má-li samozřejmě příslušné vývojářské certifikace). Máte-li se rozhodnout mezi elegantním, výkonným kódem a kódem, který je čitelný, zvolte čitelný kód.

Dějství páté: Bilancujeme

Po bitvě je každý generál. I my, když se podíváme zpět, nechápeme jak jsme mohli být tak tupí, akceptovat podivné zadání a snažit se ho implementovat i přes jeho zjevné nedostatky. U některých věcí je jasné, že jseme udělali chybu, ale už vůbec není jasné, jak se jí příště vyhnout:

Porušili jsme pravidlo Ockhamovy břitvy. Pravidlo zní “Pluralitas non est ponenda sine necessitate.” což většina vývojářů zná spíše pod zkratkou KISS (keep it simple stupid). Máme sice dobrou výmluvu – zadavatel na tom trval – nicméně i tak je to jenom výmluva. Náš postoj v této otázce nebyl tak pevný, abychom trvali na zjednodušení zadání i za cenu vážného konfliktu se zadavatelem, a to se obrátilo proti nám. Tohle je problém, na který zatím neznám jasné řešení – má vývojář vystupovat jako despotický egomaniak, který šikanuje zadavatele “pro jeho vlastní dobro”, nebo raději bez odporu realizovat nesmyslné vize zadavatele a po nevyhnutelném neúspěchu být označován za neschopného packala? Existuje nějaká třetí cesta?

Uvažovali jsme od začátku příliš pragmaticky. Pragmatický vývoj s sebou přináší technologický dluh. Jestliže technologický dluh vznikne na konci projektu, je to v pořádku – vývoj pravděpodobně nebude pokračovat, takže ho nebude třeba splatit. Pokud ale vznikne hned na začátku, zaplatí vývojový tým všechno i s úroky. Proto je na začátku projektu nutné vyvíjet toho co nejméně, co nejčistším způsobem a nebát se velkých refactoringů. Později tyhle věci už budou mnohem dražší. Problém je, že v každém týmu se najde nejméně jeden fanoušek “pragmatického přístupu” a že v krátkém časovém horizontu tento přístup skutečně přináší oslňující výsledky. Bohužel v dlouhodobém horizontu zruinuje jak projekt tak i vztah se zákazníkem. Ani tady nemám jasný recept, jak tento problém řešit. Vize rychlých, snadných řešení je prostě příliš lákavá a kdo je zpochybní, je nevyhnutelně v roli neschopného škarohlída.

Nenašli jsme včas odvahu zahodit rozdělanou práci. Když zazní věta “teď už jsme do toho investovali příliš, než abychom to zahodili a celé předělali”, je třeba začít hodně přemýšlet. Pokud tato věta zazní o čtrnáct dnů později a týká se stejného problému, je to jasné – přišel čas na bolestivý řez. Opět je výhoda, pokud vývojář je ochoten udělat ze sebe exemplární příklad arogantního tvrdohlavého idiota a říci kategorické “ne” dalšímu vývoji. Pokračování může být v podstatě dvojí, buď vyletí z projektu nebo prosadí refactoring. Možná tím nezachrání projekt, ale určitě tím ušetří svoje nervy.

Jak skončit v pozitivním duchu? Poučili jsme se z neúspěchu? Silně o tom pochybuji, tahle rozhodnutí jsou vždy těžká a nepopulární. Ale projekt jsme dokončili a spustili, takže vlastně nakonec všechno dobře dopadlo.