Basierend auf einer wahren Begebenheit.

Ich bin Softwarearchäologe. Ich habe wirklich Spaß daran alten Code auszugraben und wieder fit zu machen. Gleichzeitig freue ich mich auch über Neuentwicklungen, bei denen die Software auf Continuous Delivery ausgelegt werden kann. Doch ist Continuous Delivery wirklich nur für Projekte auf der grünen Wiese geeignet? In meinem vorigen Projekt konnte ich das untersuchen anhand der schlimmsten Codebasis die ich je gesehen habe.

Ein Monolith aus 5 Millionen Zeilen Code in verschiedenen Sprachen (Java, Classic ASP, VBA, JavaScript, T- und PL-SQL). Die Fachlichkeit erstreckte sich vom UI (Scripting, SQL Queries) bis zur Datenbank (Stored Procedures). Keine Versionskontrolle, keine Testabdeckung und keine Testumgebung. Die Mandantenfähigkeit erhielt man in dem man Code ein oder auskommentierte. Dieses System war eine große Herausforderung.

Ein Neubau war keine Option. Etwa 20 Menschen hatten gut 15 Jahre Entwicklungszeit investiert. In 9 Monaten musste das System für 10 Mandanten live sein. Es sollte in der Cloud betrieben werden und die Infrastruktur war nicht spezifiziert. Es gab viele Probleme zu lösen.

In dieser Präsentation schauen wir uns folgendes an:

  • Wie man Hotspots identifiziert
  • Was Connascence ist und wie es einem helfen kann versteckte Kopplung zu finden
  • Welche Teamstruktur sinnvoll ist
  • Warum man in regelmäßigen Abständen eine neue Version veröffentlichen sollte und wie man dabei kein schlechtes Bauchgefühl hat

Richard Gross MaibornWolff

Richard Gross ist seit 2012 Software-Archäologe im Bereich IT-Sanierung bei MaibornWolff. Am Tag erforscht er die Geheimnisse von Code und sucht nach Komponenten. Wenn der Tag sich dem Ende neigt, wird er zum Idea Farmer und durchstöbert das Web nach guten Ideen und neuen Konzepten. Doch wenn der Mond am höchsten steht, zeigt sich erst seine wahre Natur: bei jeder kleinsten Bewegung schreiend vor Zombies wegzujoggen.