Alles für den Sourcecode Nerd
Programmier Sprachen
Neben den Unit Tests für einzelne Methoden kann man auch generelle Vorgaben prüfen, welche die gesamte Architektur erfüllen muss. Dazu gibt es das ArchUnit Paket.
In meinem Demo Projekt habe ich das mal in aller Breite beispielhaft aufgebaut:
Zuerst war ich ja etwas kritisch, außerdem lief bei einer alten Version der maven download nicht mehr, da die Zertifikate fehlten.
Aber nun mit der aktuellen 8er und 11er Version vom OpenJDK klappt es vorzüglich und gefühlt kompiliert der ganze Stapel richtig schnell durch. Sämtliche Unittests sind grün, alles compiliert, nichts klemmt. Perfekt!
Wenn man sich wundert, warum eine einzige geänderte Datei beim rebase über Minuten den PC lahm legt (Windows natürlich). Wenn parallel Eclipse offen ist und bei jeder kleinen Änderung sofort neu compilieren will, dann bremst das natürlich ein wenig.
Dazu noch eine virtualisierte Umgebung und man kann erst mal Kaffee holen.
Egal ob mal eben ein XML oder ein XLSX File zu parsen ist, mit Java kann auch das schnell von der Hand gehen. Dank Maven Unterstützung ist das ganze in einer Stunde schnell hingezaubert. An manchen tagen läuft es einfach.
Ist zwar nicht üblich, aber heute war der Entwickler in mir mit echtem Gummihammer unterwegs zur Problemlösung.
Hat funktioniert, die Racks sind nun zusammen gebaut.
An echter Entwicklung gab es danach als Absacker die Verbindung von C++, Google Test, Jenkins und Testlink.
Da gibt es zum Glück die __cplusplus Variable bzw. Makro. Wenn der Wert 201103L ist, dann haben wir z.B. Version 11. Mehr ist auf snippet.wiki zu lesen.
Viel zu schnell hat man sich mal vertippt bei der Referenz zu einer Variablen. Wenn dann eine andere Variable fast genauso benannt wurde, ist der Fehler kaum zu finden:
for (TestMap testMap : this.testMaps)
{
System.out.println(testMaps.toString());
}Das eine gemeine Plural s hat sich also reingemogelt. Dem Compiler ist das egal. Gemeint war aber eher dieser Aufruf:
for (TestMap testMap : this.testMaps)
{
System.out.println(testMap.toString());
}Der Unterschied ist kaum merklich. Also hätte man besser etwas längere Namen genutzt, die sich gleich in mehr Zeichen unterscheiden:
for (TestMap oneTestMap : this.allTestMaps)
{
System.out.println(oneTestMap.toString());
}So sollte es besser lesbar sein.
So ein Sprung von Java 1.8 zu Java 11 macht schon einige kleinere Probleme. Die eigene Programmierung ist da noch das kleinste Problem, aber der CI Stack mit Code Coverage und Änderungen im Bytecode bringt einen Haufen zu aktualisierender Maven Pakete mit sich. Und da kaum jemand an einen Änderungsarmen Updatepfad denkt, muss man sich erst durch viele Changelogs arbeiten.
Aber nun läuft das JaStaCry Projekt wieder stabil, alles im grünen Bereich und Java 11 schnuckelt selbst im Jenkins ohne Probleme.
Das Problem finden manche leider erst im live Betrieb. Manche Daten sind für einen temporären Aufenthalt im Hauptspeicher einfach zu viel.
In diesem Beitrag hat sich jemand dazu mal in Java Gedanken gemacht.
Ein weiteres NoGo Beispiel aus C-Land:
Man will in einem Modul eine bestehende header Datei einbinden und fügt das passende #include hinzu. Schon hagelt es aus der eingebetteten Datei unbekannte Identifier und mehr. Was ist passiert?
Die neue header Datei nimmt stillschweigend an bestimmte weitere header files schon im aufrufenden Code eingebettet zu haben. Besser ist es aber, wenn jede header Datei alles selber einbettet was sie zu nutzen gedenkt. Dann sind die Einbindungen zwar vielfach vorhanden, aber das abzufangen ist ja schon lange ein Must Have, dank #ifdef in jeder header Datei.