Tag: agile software engineering (Seite 1 von 2)

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.

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.

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.

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. 

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).

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.

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.

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.

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.

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.