Leute, bitte. Ihr wisst es doch eigentlich alle besser: Trolle bitte nicht füttern.
Mal zurück zu MVVM und grundsätzlich Strukturierung von Code:
Zitat von
Dejan Vu:
Wenn ich die gängigen Programmierpattern (OCP, SRP, SOC usw.) stringent umsetzen will, dann führt kein Weg an einem MVVM-ähnlichen Konzept vorbei. Die Frage ist, ob ich das will, oder ob ich nicht doch pragmatisch das nicht ganz umsetze und manchmal ein wenig schludere.
Pragmatisch kann einem hierbei aber auch auf die Füße fallen. Mal ein Beispiel aus der Praxis:
Ein Team von Entwicklern (über die Zeit zwischen 3 und 6 Leute) sollte ein Softwaresystem bauen. Sie wussten es eigentlich schon damals alle besser: SOLID Prinzipien beachten,
Unit- und Integration testen. Fremdkomponenten Kapseln vor dem Verwenden damit sie austauschbar bleiben etc.
Weil sie aber schnell fertig werden mussten, wurde das ganze über den Haufen geworfen und es wurde pragmatisch geschludert'. Oder anders/betriebswirtschaftlich formuliert: Es wurden während der Entwicklung technische Schulden aufgehalst, um durch diese Schulden eine schnellere time to market zu erkaufen. Das mag manchmal eine legitime Entscheidung sein.
Das Team war sich dessen schon bewusst, und sie wollten das was dort hingeschludert wurde auch immer später aufräumen (=die Schulden zurückzahlen). Die Business-seite wollte aber keine Schulden zurückzahlen (=Zeit und damit Geld in Aufräumen investieren), sondern neue Features / Produkte haben. Auch die mussten schnell gebaut werden, also wurden zusätzliche technische Schulden angehäuft.
Wie das nunmal in der Wirtschaft so ist: Auf Schulden werden Zinsen verlangt. Bei technischen Schulden machen sich diese Zinsen dadurch bemerkbar, das auf einmal die Wartungsaufwände steigen. Es werden mehr Bugs, die werden schwieriger zu fixen weil man keine gescheite Testabdeckung hat. Weil der Code sehr eng gekoppelt ist werden neue Features sehr teuer, etc.
Nach technischen Schulden kommt irgendwann die Überschuldung. Und dann irgendwann der Bankrott.
Fast-forward: Nur 4 Jahre später war das System an diesem Zeitpunkt angekommen. Die Ergebnisse:
Das Team war von dem Rotzcode den sie fabrizieren mussten so angewiedert, das bis auf einen das gesamte Team nahezu geschlossen die Firma verlassen hat. Das Know-how: Unwiderbringlich verloren. Das Software-System war als Grundstein für viele Projekte der Firma genutzt worden, die auf dieser suboptimalen Platform haben aufsetzen müssen. Die Weiterentwicklung war ohne Entwicklungsteam komplett eingebrochen, was die Projekte die darauf aufgesetzt haben massiv zurückgeworfen hat. Das System ist inzwischen in einem Zustand, das man es nur noch wegwerfen und nicht mehr weiterentwickeln kann.
Kurzum: Zwischen 12 und 21 Personenjahre Entwicklung direkt an dem System, plus weitere unzählige in den Projekten die darauf basierten sind für die Katz. Die Firma hat viele Top-Performer verloren. Den tatsächlichen wirtschaftlichen Schaden auszurechnen traut sich niemand.
Das ganze muss jetzt nochmal neu gebaut werden. Diesmal richtig: Unpragmatisch und SOLIDe. Wartbar. Erweiterbar. Flexibel. Die ganzen Projekte die darauf aufbauen migriert werden.
Hätte man damals den Pragmatismus beiseite gelassen, nicht geschludert und gleich den Overhead den gute Software nun einmal kostet auch in Kauf genommen, wäre es nie dazu gekommen. Ich sehe die Investition in eine gute Architektur, SOLID und Tests inzwischen wie eine Versicherung. Die Police bezahlt man vorher, aber sie sichert einen davor ab, schlechte Software zu produzieren die einen hinterher deutlich mehr, im schlimmsten Fall bis hin zum Totalverlust des Geschäftes kosten kann.