Blog - Somebody said we need to do content marketing

Wenn wir Software in die Wartung übernehmen finden wir oft Projekte in denen es keine Tests gibt.

Wir ziehen dann nicht mit der Aufgabe los, Tests um der Tests willen zu schreiben. Stattdessen fangen wir einfach an opportunistische Tests zu schreiben, nur dort wo wir ohnehin einen Bug fixen oder eine neue Funktionalität einbauen und auch nur dann, wenn es einfach und ohne ohne zu viel Refactoring möglich ist. Die Tests binden wir natürlich in eine Dev-Ops Pipeline ein.

Wenn wir das eine Weile machen stellt sich ein super Effekt ein. Die Qualität der Software steigt schnell. Einfach weil schrittweise die kritischen Punkte über Tests abgesichert werden - jedoch genau die Ecken des Quellcodes in denen es viele Bugs oder große Veränderungen gibt. So stabilisiert sich der Quellcode für die Weiterentwicklung. Außerdem sinkt der manuelle Testaufwand.

Diesen Effekt, dass die Tests einfach so in das Projekt reinkriechen nennen wir: Test Creep

und Test Creep ist super!

Die Frage lautet, ist eine Weiterentwicklung und Modernisierung wirtschaftlich?

Um das herauszufinden, gibt es Hausaufgaben:

• Gesamtkontext beleuchten: Bedeutung der Software, Schnittstellen zu anderen Systemen, Verfügbarkeit von Standardsoftware, Risiken?
• Technischen Überblick erarbeiten: Technologien, Software Architektur, Code Qualität, Tests, Sicherheit?
• Nagelprobe: wie lange brauche ich, um ein kleines Feature zu ergänzen und produktiv zu nehmen?

Die Hausaufgaben bildet die Basis für strategische Szenarien.

codecare hilft gerne bei der Analyse

Two years ago we started to move our development from java to kotlin.

Now we are looking back and summing up.

It definitely was the right decision. Mixed stacks of java legacy code and kotlin do work perfectly. Our java coders have built up kotlin experience. The transition proved to be smooth and motivating. The kotlin modules are better tested, more robust and the code is a lot easier to maintain because kotlin is a lot more concise than java.

Kotlin really is just modern java! Do not be afraid to take the step!

Software Technologie ändert sich beständig. Was wird bleiben? Was läuft aus? Was passt?

• Soll ich Rust machen oder bei C bleiben?
• Code ich in Golang oder Java?
• Brauche ich wirklich Kubernetes?
• Ist Flutter 2 reif für den produktiven Einsatz?

Diese Liste ist beliebig lang und sinnvolle Antworten findet man nur in einem konkreten Kontext.

Jeder bei codecare hat einen halben Tag in der Woche zum forschen und ausprobieren. Damit schärfen wir die Basis für langfristig tragfähige Technologieentscheidungen.

Wir haben eine Verzollungssoftware geschrieben und ich habe viel gelernt.

Zum Beispiel ist 9503009510 die Zollkategorie für "maßstabgetreue Modellseilbahnen zum Bedrucken". Modell-SEIL-Bahnen. Das habe ich mir nicht ausgedacht. Das ist echt!

Wer denkt sich so etwas aus und vor allem warum?

Benötigt der europäische Wirtschaftszweig der Modellseilbahnhersteller Schutz vor ausländischen Billigimporten? Immerhin gilt ein Drittlandszollsatz von 4,7%.

Oder hat sich ein Kabarettist in die Kommission zur Definition der Warentarifnummern eingeschlichen?

Oder dient es einfach nur dazu, uns Programmierer mal zum Lachen zu bringen?

Lustigerweise muss bei der Einfuhr außerdem durch den Code Y922 bestätigt werden, dass "Keine oder andere Felle als Katzen- und Hundefelle" in der Modellseilbahn verbaut sind.

Ich tippe auf den Kabaretisten...

Wir suchen fortwährend nach wirtschaftlichen Lösungen für die Software Modernisierung. Im Endeffekt läuft das fast immer auf die Wartbarkeit und Testbarkeit des Quellcodes hinaus.

Darüber hinaus sind wir der Meinung, dass C-Code inhärent "broken" ist. C macht Speicherfehler viel zu einfach und erfordert beinahe geniale Entwickler - so erfordert auch das Lesen von C-Code oft Klimmzüge, bis man versteht, welches fachliche Problem dort gelöst wurde. Deswegen ist C-Code bei Software Modernisierung regelmäßig ein Risiko.

Auf der anderen Seite ist uns klar, dass in Legacy Systemen ein Big Bang Ansatz zur Erneuerung selten ökonomisch tragfähig ist. Daher finden wir Lösungswege extrem hilfreich, die eine Software Modernisierung punktuell an kritischen Stellen erlauben.

Und jetzt kommt "RUST to the rescue". In seiner Bachelor-Arbeit hat unser Kollege Philip Koslowski die technische Machbarkeit einer partiellen Erneuerung einer C Codebasis mit RUST untersucht. Das geht nicht nur gut, es macht sogar wirtschaftlich enorm viel Sinn!

Vielen Dank an Prof. Dr.-Ing. Mira Mezini und Dr. Krishna Narasimhan der TU Darmstadt für die engagierte Betreuung der Bachelor Arbeit.

Die Cookie-Zustimmungsdialoge werden immer fetter, komplexer und grotesker. Warum?

Technisch gesehen braucht es Cookies nur dann, wenn man seine Nutzer tracken will oder einen Zustand speichern muss.

Gehören alle diese Websites mit den abstrusen und irreführenden Cookie-Dialogen zu Firmen, die beständig ihre Conversion-Rates mit Hilfe der Klick-Pfade optimieren und ihre Marketing-Kampagnen vermessen wollen?

Warum kommt der Cookie Dialog für die notwendigen Cookies nicht erst dann, wenn sie wirklich notwendig werden - also beim Login oder wenn ich was in den Warenkorb lege?

Ich habe das Gefühl, das hat sich komplett verselbstständigt.

Unsere Homepage funktioniert jedenfalls komplett ohne Cookies. Wir tracken einfach nicht. Trotzdem freuen wir uns über jeden Besuch.

Bei unserer Software-Modernisierung ist die Programmiersprache meist festgeschrieben. Zuletzt hatten wir aber freie Wahl.

Im Team haben wir intensiv diskutiert. Die Motivation für go, kotlin oder python ist sehr groß.

Aber zu guter letzt ist es mal wieder Java geworden.

Ausschlaggebend dafür war die Risikobetrachtung. Das Java Ökosystem an Open Source Libraries ist super und das Java Know How weitreichend. Außerdem gibt es Legacy-XML-Schnittstellen. Zusammen mit einem engen Zeitrahmen und enormer fachlicher Komplexität ist es dann wieder Java geworden.

Ein wenig langweilig aber sinnvoll.

Aber das nächste Projekt machen wir mit Go!

Wir haben in den letzten Tagen die passende Cloud für eine neues Projekt ausgewählt.

Das Überraschende daran war, dass in der Entscheidungsmatrix die strategischen Punkte den Ausschlag gegeben haben. Aus technischer Sicht waren die Clouds für unsere auf Kubernetes aufbauende Architektur fast austauschbar. Am Ende war das schon vorhandene DevOps Know-how dann maßgebend.

Und aus meiner Sicht passt das auch: "You build it, you run it" ist zusammen mit einer komplexen DevOps CI/CD Pipeline und hohen Anforderungen an die Verfügbarkeit nicht wirklich praktikabel. Eine Arbeitsteilung mit DevOps Experten hilft hier einfach sehr.

Komplexität verschwindet nicht, nur weil sie gekapselt ist.

Gestern habe ich 3 Stunden für 30 Zeilen DevOps Konfiguration gebraucht. Das Resultat war eine automatische Bauanleitung. Sie ist kompakt und gut lesbar. Aber unter der Haube verbergen sich viele Technologien: gitlab, docker, nodejs und komplexe Konzepte und Konventionen zur Parametrisierung. Dazu kommt, dass vieles sich in Bewegung befindet und Beispiele oft für ältere Versionen gemacht sind.

Daher ist es sinnvoll, sich erst einmal in die konkreten Konzepte einzulesen und dann an Hand von Best Practice Beispielen die Pipeline aufzubauen.

codecare - wir können DevOps