Vaadin auf Grails: Kann das funktionieren?

Vaadin auf Grails: Kann das funktionieren?

Projektanfragen mit dem Wunsch, eine Rich Internet Application auf Basis des bekannten Vaadin-Frameworks zu entwickeln oder zu erweitern, sind für uns als Vaadin-zertifizierter Partner mittlerweile zur Selbstverständlichkeit geworden. Bei den meisten Kunden ist dabei bereits eine bestehende JEE-Architektur vorhanden, in welche das Vaadin-Framework eingebettet werden soll. Im Gegensatz dazu unterstützen wir aktuell einen Verlag bei einem agilen „Green-Field-Projekt“: einer vollkommenen Neuimplementierung einer Rich Internet Application mit Vaadin. Die Besonderheit dieses Projekts liegt darin, dass statt einer herkömmlichen JEE-Umgebung eine ebenfalls neu zu entwickelnde Grails-Architektur als Backend dienen soll.

Read More

Wie misst man Clean Code?

Wie misst man Clean Code?

Als Software-Entwickler stehe ich am Ende des Tages mit einer mal mehr, mal weniger großen Menge neuen Codes da und stelle mir die Frage: Wie gut ist das, was ich heute geschrieben habe?

Genauso wie viel andere neige ich aber dazu, nicht immer 100 % objektiv zu sein, wenn ich die Qualität meines Codes selber beurteilen muss. Deswegen ist in unserer „Definition of Done“ festgelegt, dass jeder Code durch einen Kollegen revidiert werden muss. Dadurch erhalte ich eine zweite, unabhängigere Sicht auf meinen Code.

Falls man aber gerade keinen Kollegen zur Hand hat, hilft es auch, nacheinander die Prinzipien des Clean Codes durchzugehen und den Code darauf zu überprüfen, wie gut die Prinzipien dort umgesetzt sind. Und um dem eigenen, wohlwollenden Blick ein wenig Objektivität zur Seite zu stellen, hat es sich für mich bewährt, ein paar Code-Metriken zur Unterstützung heranzuziehen.

Read More

Mit der Abrissbirne zu besseren Unittests - Erkenntnisse beim Kaffeetrinken mit Uncle Bob

Mit der Abrissbirne zu besseren Unittests - Erkenntnisse beim Kaffeetrinken mit Uncle Bob

Durch glückliche Umstände hatte ich vergangenes Jahr die Möglichkeit, an einem zweitägigen Workshop mit Robert C. Martin – besser bekannt als „Uncle Bob“ – teilzunehmen. Ich hatte zu dieser Zeit bereits einige Erfahrung mit testgetriebener Entwicklung gesammelt, sowohl in Coding Dojos als auch in der täglichen Projektarbeit. Die Arbeitsweise durch das Vorgehen nach TDD (test-driven development) hatte signifikant positive Auswirkungen auf die Qualität der Software, die wir bauten, und gab uns ein Gefühl für eventuelle Schwachstellen der Anwendungen.

Read More

Das Interface Segregation Principle - Nicht nur auf den Schnitt kommt es an

Das Interface Segregation Principle - Nicht nur auf den Schnitt kommt es an

In unserem heutigen SOLID-Beitrag geht es um das „Interface Segregation Principle“. Wie wir im Blog sehen werden, ist dabei weniger die Trennung nach Interfaces das Problem, als vielmehr die an manchen Stellen wieder benötigte, sinnvolle Zusammenführung von Funktionalitäten aus verschiedenen Interfaces eines Objekts.

Vorweg: Die Fachabteilung war ganz begeistert, dass wir neulich die Anforderung zur Aufnahme von nicht registrierten Kunden so schnell und sauber umsetzen konnten. Die ausführliche Geschichte und wie die Anwendung des Liskov Substitution Principle zu einer sauberen Lösung beigetragen hat, kann man im „L“-Blog unserer SOLID-Reihe nachlesen.

Allerdings hat diese Erweiterung den Einfallsreichtum angespornt. Die neue Vision: Zukünftig sollen weitere neue Kundentypen im System eingeführt werden können. Außerdem soll es möglich sein, bestehende Kunden in einen anderen Kundentyp zu wandeln ohne dazu den Kunden im System neu anlegen zu müssen. 

Read More

Das - Liskov Substitution Principle - LSP

Das - Liskov Substitution Principle - LSP

ubtypes must be substitutable for their base types. 

So, das „S“ und das „O“ der SOLID-Prinzipien haben unser Design hinsichtlich der Qualitätsmerkmale wie Wartbarkeit, Testbarkeit und Erweiterbarkeit bereits erheblich verbessert. Wir haben gesehen, dass es Sinn macht, einer Klasse möglichst nur eine Verantwortlichkeit zu übertragen (Single Responsibility Principle) und Programmcode offen für Erweiterungen, aber geschlossen für Änderungen zu implementieren (Open Closed Principle).

Read More

Das Open-Closed Principle (OCP)

Das Open-Closed Principle (OCP)

Software sollte lesbar, modular und wartbar sein. Leider entsteht im Laufe der Entwicklung, vor allem aber auch bei Weiterentwicklungen, immer wieder schlechtes Software-Design. Im schlimmsten Fall treten Programmfehler bei bereits längst getesteten Funktionalitäten auf. Die Beachtung der SOLID-Prinzipien objektorientierter Softwareentwicklung kann helfen, diese Fehler zu vermeiden und Programmcode wartbar zu halten. Insbesondere die Wartbarkeit ist von großer Bedeutung, da man selten Softwareentwicklung auf der grünen Wiese betreibt, sondern in den allermeisten Fällen auf vorhandenem Programmcode aufbaut.

Read More

Das Single Responsibility Principle (SRP)

Das Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Heute beginnen wir mit dem ersten SOLID–Prinzip: Eine Klasse sollte immer eine einzige Verantwortung haben, oder anders ausgedrückt: Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern (Single Responsibility Principle, SRP).

Das SRP wendet man an, um übersichtliche, leicht erweiterbare und einfach zu wartende Software zu konzipieren.

Read More

SOLID – ein Schritt zu mehr Professionalität in der Software-Branche

SOLID – ein Schritt zu mehr Professionalität in der Software-Branche

Schon vor vielen Jahren saß ich mal in einer Straßenbahn, wir standen an einer Haltestelle, es ging nicht weiter. Plötzlich hörten alle Motoren auf zu summen, alle Lichter gingen aus – und nach einiger Zeit wieder an. An der Anzeige über dem Fahrer blinkte die Firmware-Versionsanzeige auf. Was war passiert? Offenbar war die Straßenbahn „abgestürzt“ und der Fahrer hatte sie in seiner Not einfach neu gebootet.

Read More

Highlights aus dem MobileTech 2013 Workshop - Mobile Javascript WebApps professionell entwickeln

Highlights aus dem MobileTech 2013 Workshop - Mobile Javascript WebApps professionell entwickeln

Die Beschäftigung mit den verschiedenen Ansätzen der Softwareentwicklung für mobile Endgeräte lenkte mein Augenmerk auf aktuelle Konzepte in der Javascript-Entwicklung. Dass sich bewährte Prinzipien und Praktiken aus der herkömmlichen Webentwicklung auch auf Mobile-Web Projekte übertragen lassen, ist nachvollziehbar. Beispielsweise können dort ebenso CleanCode Richtlinien berücksichtigt und JavaScript Module Test getriebenen entwickelt werden. Dennoch gibt es spezifische Herausforderungen, die bei der Entwicklung von mobilen Applikationen ergeben.

Auf der MobileTech 2013 in München wurden im Workshop „Mobile Javascript WebApps professionell entwickeln“ derartige Herausforderungen adressiert und Lösungsansätze vorgestellt, welche anhand von Programmieraufgaben verinnerlicht werden konnten.

Im Folgenden möchte ich meine persönlichen Highlights aus diesem Workshop vorstellen.

Read More

Software Reverse Engineering

Software Reverse Engineering

er Softwaremarkt ist in vielen Bereichen hart umkämpft. Es existieren viele Mitbewerber und unzählig viele Produkte in den verschiedensten Bereichen. Um sich als Firma durchzusetzen und einen möglichst hohen Marktanteil zu ergattern, muss sich eine Software in der Regel von den Konkurrenzprodukten absetzen. Ich denke dabei an Innovationen: Besondere Funktionalität und sehr ausgeklügelte Lösungsansätze, aber auch an Performance-Erwartungen.

Um diesen Vorsprung zu erreichen, muss ein Unternehmen viel investieren. Es ist notwendig Fachleute anzustellen und die Entwicklung und Umsetzung des Konzepts benötigt mehr oder weniger Zusatzaufwand. Es müssen Tests gefahren werden, die den ordentlichen Betrieb dieser Neuerung gewährleisten. All dies führt zu Kosten, die dann (so die Erwartung) durch den besseren Absatz gedeckt werden können.

Je mehr Entwicklungsaufwand betrieben wird und je mehr es beim Vertrieb auf diese Innovationen ankommt, desto mehr sollte man sich die Frage stellen, wie diese Software zu schützen ist. Dieser Blogeintrag soll einen Denkanstoß in diese Richtung geben. Dabei geht es nicht um einen Kopierschutz, sondern um die Gefahren und den Schutz vor ungewollten Einblicken durch die Konkurrenz mittels Software Reverse Engineering.

Read More

Behavior Driven Development

Behavior Driven Development

n Projekten kommt es immer wieder vor, daß Kunden und Business Analysten bei der Präsentation der Ergebnisse einer Softwareentwicklung ihre Anforderungen nicht umgesetzt sehen. Gründe dafür können z.B. unspezifische Anforderungen, fehlende Beispielfälle und Mißverständnisse bei der Interpretation der Anforderungen sein. Softwareentwickler leiten aus der sprachlichen Spezifikation Testfälle in Programmcode ab, die von technikfernen Projektbeteiligten nur schwer verstanden und geprüft werden können. Wie kann es ermöglicht werden, diese automatischen Tests lesbarer zu gestalten, so daß sie durch Business Analysten und Kunden geschrieben und abgenommen werden können? Bei der Suche nach Lösungen bin ich auf "Behavior Driven Development" gestoßen.

Read More

Inversion of Control

Inversion of Control

Vergleichbar mit der Konstruktion eines Wolkenkratzers, müssen bei der Erstellung einer Software Architektur-Richtlinien definiert und berücksichtigt werden. Wird dies nicht befolgt, stürzt die Konstruktion über kurz oder lang ein.
Inversion of Control gibt dem Entwickler ein effektives Tool an die Hand, um Software auf Klassenebene so solide zu bauen, dass auch bei größeren Umbaumaßnahmen oder langjähriger Weiterentwicklung die Architekturaspekte Erweiterbarkeit, Wiederverwendbarkeit, Testbarkeit nicht in Mitleidenschaft geraten.

Read More

Automatisierte Tests über Weboberflächen

Automatisierte Tests über Weboberflächen

Fast jeder kennt das Problem. Man implementiert neue Funktionalität, führt eventuell noch paar Code-Optimierungen durch und lässt anschließend Unit-Tests laufen. Obwohl alle Tests erfolgreich sind, ist man trotzdem nicht immer sicher, ob eigene Änderungen keine Seiteneffekte verursacht haben, die erst beim manuellen Testen der Applikation über die Oberfläche ersichtlich werden. Ganz schlimm wird es, wenn diese Fehler ganz übersehen werden. Meistens ist es nicht der Fall. Doch wer sicher sein will, sollte sich über Testautomatisierung der Benutzeroberflächen (GUI-Testing) Gedanken machen.

Read More

Legacy Code unter Kontrolle - Folge 3, JMockit für Fortgeschrittene

Legacy Code unter Kontrolle - Folge 3, JMockit für Fortgeschrittene

m ersten Blog-Eintrag dieser kleinen Serie habe ich erzählt, warum JMockit eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung zu testen. Im nächsten Eintrag habe ich das wichtigste API von JMockit, das Expectations-API vorgestellt. Als Abschluss zeige ich an zwei konkreten Beispielen aus der Praxis, wie JMockit einem auch in schwierigen Fällen einen Unit-Test möglich macht.

Hier nochmal der Überblick über die ganze Serie:
•    Folge 1: Vorstellung von JMockit
•    Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur schwer zu erstellen wäre.
•    Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Schaltjahresproblem und ein Singleton-Factory-Lindwurm.

Read More

Legacy Code unter Kontrolle - Folge 2, Die Grundkonzepte von JMockit

Legacy Code unter Kontrolle - Folge 2, Die Grundkonzepte von JMockit

In meinem letzten Blog-Eintrag habe ich erläutert, warum JMockit bei meinem aktuellen Kunden eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung testbar zu machen und so änderbar zu halten.
In der Folge 2 will ich heute darstellen, wie man konkret Unit-Tests mit JMockit schreibt und welche Konzepte dabei eine Rolle spielen. Es entsteht ein Test für eine Stück Legacy Code, das ohne JMockit nur sehr schwer zu testen wäre.

Hier nochmal der Überblick über die ganze Serie:

  • Folge 1: Vorstellung von JMockit
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.
Read More

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

Bei meinem aktuellen Kunden setzen wir das Tool „JMockit“ so erfolgreich ein, dass es inzwischen einen wichtigen Platz in meiner „virtuellen Werkzeugkiste“ bekommen hat. Auch wenn sich die Entwickler in meinem Team größte Mühe gegeben haben, ordentlichen Code mit einem sauberen Design zu erstellen, so schlagen wir uns nun dennoch durch inzwischen weit über 1 Million Zeilen Java-Code, aus denen uns die Fehlentscheidungen der letzten 10 Jahre „entgegenmüffeln“. Wir kämpfen mit Legacy Code. Hier helfen uns Unit-Tests. Und JMockit spielt bei der Erstellung dieser Tests eine entscheidende Rolle.

 

Da JMockit noch recht neu und unbekannt ist, möchte ich es Ihnen hier in einer lockeren Folge von Blog-Einträgen näherbringen:

  • Folge 1: Vorstellung?
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.
Read More