Software – richtig gemacht!
Der erste Teil dieses Artikels hat gezeigt, wie Mock-Objekte prinzipiell das Leben von Java-Web-Entwickler erleichtern. Nun folgt ein Beispiel aus der Praxis.
Dass die durchgängige Entwicklung von Mock-Objekten relativ viel Arbeit bedeutet, wurde schon im ersten Teil erwähnt. Umso wichtiger ist es, dass die dafür notwendige technische Infrastruktur möglichst einfach umzusetzen ist.
Frontend-Entwickler leiden häufig unter langen Round-Trip-Zeiten beim Bauen und Deployen einer Java-Web-Anwendung. Selbst bei kleinen Layout-Änderungen muss der vollständige Bau-Prozess durchlaufen werden. Mock-Objekte können hier viel Arbeitszeit sparen.
Wer ist von dem Problem überhaupt betroffen? Die Entwickler von Play-, Vaadin– oder Grails-Projekten kennen langsame Build-Prozesse kaum. Auch diejenigen Entwickler, deren Anwendungen in reinen Web-Containern wie Tomcat laufen, profitieren in der Regel von ihrer schlanken Infrastruktur.
Sobald aber „schwerere“ Technologien wie O/R-Mapping, EJBs oder Messaging dazukommen, benötigt das Bauen und vor allem das Deployen einer Anwendung spürbar Zeit. Vor allem der Einsatz von Anwendungsservern bremst die Entwicklung aus. Zum einen funktioniert das Hot-Code-Replacement von Code-Änderungen im laufenden Betrieb meistens schlecht, zum anderen schlagen Änderungen an Ressourcen wie JSF- oder Wicket-Html-Dateien nicht sofort durch. Jedenfalls, solange man nicht Produkte wie JRebel einsetzt.