Datenarchitekturen nicht nur für Microservices from JAX TV on Vimeo.

Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u. a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps, Microservices und NoSQL.

The post Datenarchitekturen (nicht nur) für Microservices appeared first on JAX.

JAXenter: Fangen wir mit einer schwierigen Frage an: Was ist guter Code? Woran kann man diesen messen?

Christoph Meyer: Um mit einem sinngemäßen Zitat von Robert C. Martin zu beginnen: „Mit Code ist es ähnlich wie mit Kunst. Niemand kann dir genau sagen, was ein gutes oder schlechtes Bild ausmacht. Aber wenn ein Betrachter davor steht, wird er es schnell sagen können.“

Es gibt keine klare, einheitliche Definition von gutem Code, jeder Entwickler hat eine andere Vorstellung. Es haben sich aber Merkmale herauskristallisiert, die man in diesem Zusammenhang immer wieder findet. Hier würde ich zuerst Lesbarkeit, Verständlichkeit, Wartbarkeit und Testbarkeit nennen.

Diese Merkmale wiederum sind qualitativ, was die Messbarkeit erschwert. Die statische Codeanalyse liefert hier als Hilfestellung eine Menge Kennzahlen, mit denen man zumindest positive und negative Entwicklungen der Codebasis verfolgen kann. Man sollte sich vorher allerdings gut überlegen, mit welchen Metriken man welche Entwicklungen nachverfolgen möchte und ob die gewählten Metriken auch im Team Akzeptanz finden, wenn man sie zur Steuerung der Codequalität einsetzen will.

JAXenter: Warum ist es so schwer zu beschreiben, was guten Code ausmacht?

Christoph Meyer: Das liegt an den genannten weichen Faktoren, die guten Code definieren. Nehmen wir als Beispiel die Lesbarkeit als Kriterium für guten Code. Lesbarkeit ist beispielsweise abhängig von der gewählten Programmiersprache und ihren Ausdrucksmöglichkeiten aber auch von individuellen Präferenzen der Entwickler. Ich finde es wichtig, dass sich das Team hier auf Standards einigt und diese – wenn möglich – Tool-gestützt oder mit Code Reviews überprüft und einheitlich umsetzt.

Die Betrachtung, dass wir Programmierer Autoren sind, die für eine Leserschaft Text schreiben, finde ich ebenfalls hilfreich. Code wird wesentlich öfter gelesen als geschrieben und mit mangelnder Lesbarkeit verteuern sich Problemanalysen und Bugfixing später enorm.

Was führt zu schlechtem Code?

JAXenter: Welche Faktoren sorgen für schlechten Code, kannst du drei Beispiele nennen?

Christoph Meyer: Zeitdruck, gedankliche Trennung von Funktion und Qualität, sowie fehlendes Feedback.

Zeitdruck hat viele Ursachen und kommt in den meisten Projekten vor. Er wird für mangelnde Qualität gern als Rechtfertigung herangezogen. Zeitdruck ist aber nicht nur Ursache, sondern auch Wirkung: Durch Stress und Zeitdruck entstehen zusätzliche Fehler, die durch „dringende Fehlerbehebungsmaßnahmen“ wiederum Stress erzeugen.

Verstärkt wird das erfahrungsgemäß durch die gedankliche Trennung von Funktion und Qualität. Sagt ein Entwickler einen Satz wie etwa „die Realisierung benötigt X Tage, plus Y Tage für die Unit-Tests und Refactorings“, dann ist das gefährlich, denn die Zahl von Y wird damit aus Managementsicht verhandelbar und kürzbar. Bei testgetriebener Vorgehensweise stellt sich diese Frage erst gar nicht.

Fehlendes Feedback ist tückisch – es lullt ein und wiegt in Sicherheit. Mit Tool-Unterstützung oder Code Reviews kann man hier gegensteuern. Aber der wichtigste Faktor ist sicherlich Collective Code Ownership – wenn sich alle Entwickler im Team gleichermaßen verantwortlich für die Codebasis fühlen, sich mit Pairings helfen und auch Verantwortung für Fehler übernehmen, die aus Code der Anderen stammen, hat man günstige Voraussetzungen für guten Code.

JAXenter: Welche Rolle spielen hier die Softwarearchitekten im Vergleich zu Entwicklern?

Christoph Meyer: Softwarearchitekten als Bindeglied zwischen Entwicklern und Management kommt eine wichtige Rolle zu: Sie definieren den Rahmen für die Entstehung guten Codes, überwachen die Entwicklung kontinuierlich und verteidigen Qualitätsmaßnahmen gegenüber dem Management, während sich die Entwickler auf die Realisierung der Features konzentrieren. Zusätzlich sehe ich beim Architekten auch die Pflicht, für die ausgewählten Qualitätsmaßnahmen Werbung zu machen, zu erklären und zu coachen.

Nach meiner Erfahrung führt das immer wieder zu Konfliktsituationen sowohl mit dem Team, als auch mit dem Management. Die Bearbeitung und Lösung dieser Konflikte ist für mich daher ebenfalls eine wichtige Aufgabe des Softwarearchitekten.

Auf dem Weg zur Clean-Code-Kultur

JAXenter: Auch die Kultur und Stimmung im Unternehmen sind wichtige Faktoren. Wie müssen diese aussehen, damit sie einen positiven Effekt auf die Codequalität haben?

Christoph Meyer: Eine offene und wertschätzende Kommunikationskultur sowie eine konstruktive Problemlösungskultur sind sehr wichtig. Es ist selbstverständlich, dass Fehler passieren und die Frage sollte stets lauten: Wie lösen wir das Problem und wie lernen und verbessern wir uns, damit wir es in Zukunft vermeiden?

Wird im Unternehmen immer zuerst der Schuldige gesucht, führt das zu einer Blame- bzw. Rechtfertigungskultur, in der die Mitarbeiter viel Mühe investieren um nachzuweisen, warum gerade sie nicht Schuld sind. Mir ist aufgefallen, dass ein konstruktiver Umgang mit Problemen in agilen Umfeldern einfacher zu sein scheint. Ich halte so eine Kultur aber auch in „klassischen Umfeldern“ für möglich, beispielsweise durch die Einführung von Feedback-Meetings als abschließenden Teil der Problemlösung oder durch regelmäßiges Zusammentragen von sogenannten Lessons Learned.

JAXenter: Du wirst in deiner Session auch Gamification-Ansätze zeigen – kannst du Beispiele dafür nennen?

Christoph Meyer: Ein gutes Beispiel ist ein Scoring-System, in dem Entwickler etwa Punkte für die Erledigung von Qualitätsmaßnahmen bekommen können. Das kann man mit einem Achievement-System koppeln, wo sich Badges und Titel freischalten lassen. Eingebettet in ein etwas nerdiges Szenario und gekoppelt mit freiwilliger Teilnahme der Entwickler kann man eine Menge Spaß an Refactorings für guten Code entwickeln.

In diesem Sinne: Errungenschaft „Clean Code Padawan“ freigeschaltet!

JAXenter: Vielen Dank für dieses Interview!

The post Clean Code: Was guten Programmcode ausmacht! appeared first on JAX.

Die verborgenen Schätze der Java-Plattform

Programmiersprachen sind das Salz in der Suppe eines jeden Entwicklers. Wer der Java-Plattform die Treue hält, wird mit einer riesigen Vielfalt an Sprachen belohnt, die die verschiedensten Programmierparadigmata abdecken: von der Objektorientierung bei Java, JRuby oder Ceylon über die funktionale Programmierung mit Clojure, Frege oder Erjang, bis hin zu dynamischem Scripting mit Groovy, Jython oder Nashorn.

Einen Überblick über die Sprachen-Landschaft der Java-Plattform bietet die Infografik Pirates of the JVM. Hier finden sich zur Orientierung die verschiedenen Sprachen-Inseln in ihren jeweiligen Paradigmen-Ozeanen – und, mit einem dicken Augenzwinkern versteht sich, alle Details zu Entdeckern, klimatischen Verhältnissen und Population der Sprachen.

Pirates of the JVM – das Gewinnspiel

Auf der Infografik tummeln sich so manche JVM-Piraten – erkennen Sie welche? Dann wird es Ihnen nicht schwer fallen, das untere Rätsel zu lösen!

Zu gewinnen gibt es:

1. Preis: Das Video-Tutorial “Microservices” von entwickler.tutorials.de
2. Preis: Buch: IT Survival Guide 3. Auflage
3. Preis: 1 Magazin digital – freie Auswahl im Kiosk

Tragen Sie die Namen der gesuchten Personen in die Kästchen ein. Als Lösungswort ergibt sich in der roten Vertikalen ein Programmierkonzept, das momentan besonders en vogue ist…

[contact-form-7]

Tipp: Schauen Sie zur Lösung des Rätsels doch ab und zu auf die unten aufgeführte Infografik…

Viel Spaß mit den JVM-Piraten und viel Glück beim Gewinnspiel! Einsendeschluss ist der 19. April.

Pirates of the JVM – die Infografik

The post Pirates of the JVM – das Gewinnspiel appeared first on JAX.

JAXenter: Hallo Rafael! Auf GitHub bezeichnest du dich als “Software Consultant who likes static types”. Das statische Typensystem in Java scheint es dir also angetan zu haben – so sehr, dass du das Projekt Byteboddy gestartet hast, um Java dynamischer zu machen Was findest du am Java-Typensystem gut – was stört dich daran?

Rafael Winterhalter: Grundsätzlich empfinde ich Javas Typensystem als eines der pragmatisch besten, das ich kenne. Durch die durchgehend statische Typisierung kann man meistens sehr einfach auch durch unbekannte Java-Anwendungen navigieren, was es sehr einfach macht, sich mit einem Programm bekannt zu machen. Das hilft oft beim Onboarding neuer Entwickler, was meiner Meinung nach Java als Enterprise-Sprache erfolgreich macht.

Gleichzeitig ist Javas Typensystem einfach zu lesen, gerade weil Javacode teils ein bisschen weitschweifiger ist als andere Sprachen. Diese Explizität macht Java-Programme nach meiner Erfahrung oft sehr ausdrucksstark.

Kritik kann man vielleicht an der mangelnden Flexibiliät des Typsystems üben. Gerade generische Typen könnten natürlich in einer erweiterten Form umfangreichere Typensicherheit zulassen. Aber diese zusätzlichen Mittel würden mit einem hohen Preis kommen, gerade für beginnende Javaentwickler, denen viel Code nicht mehr zugänglich wäre.

Making Java more dynamic

JAXenter: Auf der JAX hältst du eine Session zum Thema „Making Java more dynamic.“ Darin bringst du die Möglichkeit der Code-Generierung zur Laufzeit ins Spiel. Wie genau funktioniert das?

Rafael Winterhalter: Die Java Virtual Machine führt ja eigentlich keine Java-Programme aus, sondern verarbeitet sogenannten Java Bytecode. Dieser ist ein wenig technischer aufgebaut als die Sprache Java, ist in seiner Struktur aber relativ einfach. Byte Buddy generiert dabei zur Laufzeit Java-Programme mittels einer API statt einen Compiler anzubieten. Diese Java-Klassen werden dann ins laufende Programm geladen, um dessen Verhalten zu verändern.

Dies ist manchmal notwendig, um zum Beispiel Proxies zu generieren. Solche lassen sich mit dem Compiler nur schwer erzeugen, unter anderem wegen Javas Typsystem. Weiterhin ist es möglich, existierenden Code mittels sogenannter Java-Agenten umzuschreiben. Das ermöglicht es, Anwendungen zu erweitern, ohne diese neu zu kompilieren. Dieses Verfahren nutzen beispielsweise APM-Tools, um Metriken zur Laufzeit zu sammeln.

1. Class&lt<?> dynamicType = new ByteBuddy()
2.     .subclass(Object.class)
3.     .method(ElementMatchers.named("toString"))
4.     .intercept(FixedValue.value("Hello World!"))
5.     .make()
6.     .load(getClass().getClassLoader())
7.     .getLoaded();
8.    
9.   assertThat(dynamicType.newInstance().toString(), is("Hello World!"));

The post „Das Typensystem von Java ist eines der pragmatischsten, das ich kenne“ appeared first on JAX.