Wie viel Vielseitigkeit als Entwickler ist zuviel?

[philipp.hofmann]

Es bedeutet natürlich Aufwand, aber um 2-3 Hochzeiten kommt man teilweise nicht umhin. Manchmal nimmt man dies aber auch gar nicht so wahr. Es gibt für jedes Problem geeignete und ungeeignete Lösungsansätze (egal, ob Sprache, Betriebssystem, Datenbanken, ...). Aber sehr oft ist der Lösungsansatz ja auch kundengetrieben, weil bestimmte Dinge schon da sind.

Wenn der Kunde eine Oracle-Datenbank hat und dort Daten durch die Gegend geschoben müssen (auch über Servergrenzen hin weg), dann mache ich dies nach Möglichkeit per SQL-Stored-Procedure und Triggern. Dies ist an Performance nicht zu schlagen und bietet mittlerweile auch relativ viele Möglichkeiten der Codierung. Ansonsten kann ich aber genauso gut Delphi(=Pascal [um hier genau zu bleiben])/Java und im Bedarfsfall auch C/C++-Code implementieren.

Die Grundstrukturen guter Entwicklung bleiben ja glücklicherweise gleich und ich nutze eher weniger Frameworks/Libraries. Bedeutet zwar teilweise Mehraufwand bei der initialen Entwicklung, aber wenn ich mir anschaue, welche Projekte schon an Hibernate-Problemen gescheitert sind, dann gibt mir dies bisher recht. Ich habe schon mehrfach mit Frameworks überlastete Projekte komplett neu implementiert und sehe dort meist sehr deutliche Performance-Verbesserung (teilweise bis Faktor 4, also 4 mal so schnell), deutlich geringere Hauptspeicherbelastung und eine deutlich besser Nachvollziehbarkeit und der Entwicklungsaufwand ist am Ende des Tages auch kleiner. Wenn ich dann Frage, warum man das Framework A oder B den genutzt hat, heißt es meist, dass dies Vorgabe war ohne das es einen technischen Sinn macht. Und da ich wenig Frameworks und Libraries nutze, komme ich auch schneller in eine neue Programmiersprache.

Aber um es zu unterstreichen (und nicht missverstanden zu werden), in einem anderen Kontext kann dann Framework A Sinn machen, weil der Aufwand sonst zu groß wird. Nur muss man es dann wirklich im Griff haben und auch trotzdem noch in der Lage zu sein, zu verstehen, was die Software wann und warum tut. Wenn man dies nicht mehr versteht, sollte man das Vorgehen überdenken, den wehe es kommt ein Fehler.