Hi,
ich hatte letzte Woche ein interessantes Erlebnis bei einem Kunden.
Es ging um ein funktional zentrales Applet für eine wichtige Anwendung von denen. Das funktionierte nicht so richtig. Deshalb war ich da. Der code sah extrem seltsam und unübersichtlich aus. Nach einer relativ langen Zeit des Rumdrucksens waren die dann doch ehrlich genug, das Rätsel zu lüften, wie dieses Applet entstanden ist.
Die haben einfach ein der gewünschten Funktionalität ähnliches Applet (noch nicht mal openSource) durch den de-compiler gejagt und tagelang dran rumgeklopft, bis sie es der Geschäftsleitung präsentieren konnten (geht ja nur darum, daß es so aussieht als würde es funktionieren).
Dieses Applet wurde 1999 geschrieben (einer Zeit, wo wg. dot.com.Boom und Neuheit von Java) wesentlich schlechterer code geschrieben wurde als heute.
Emotional nähere ich mich inzwischen solchen Dingen mit unagressiven, sachlichen Melancholie (hab ich mir von Inspektor Derrick abgeschaut
). Gruß an den Harkpabst, der kennt das noch ganz anders.
Ist es fair, etwas in seine IT-Landschaft zu stellen, was man nicht beherrscht? Die bezeichneten das als pragmatische, wirtschaftliche Lösung. Hab das denen gegenüber nicht geäußert, aber ich finde das weder pragmatisch noch wirtschaftlich. Schließlich haben die Tage an etwas entwickelt, das präsentiert, etc., daß nun am Donnerstag entsorgt wurde und ich fang wieder von vorne an.
Ist das komponentenbasierte Entwicklung? Man benutzt schließlich etwas, was vom inneren Funktionieren eine black box darstellt und das man von außen anspricht. Eben genau und gerade nicht.
Eine Komponente hat eine klar definierte Schnittstelle und ist sowieso hinsichtlich seines für den Anwendungsentwickler relevanten Verhaltens genau dokumentiert.
In Deutschen Städten gibt es seit Jahren sowas wie Stadtplanung. In Städten von Schwellen- oder Entwicklungsländern über weite Strecken des 20. Jhdts nicht. Das hat dann negative Auswirkungen für den Ausbau der Kanalisation, den Straßenbau, die Elektrizitätsversorgung, die Optik etc.. Durch das oben beschriebene Verhalten kopieren wir Entwicklungsländer.
Natürlich nehme ich bei meinen Projekten auch "Abkürzungen". Nur ich verbringe auch Tage damit, das wieder gerade zu biegen. Manches, was ich mache, ist auch einfach schlecht, weil ich es nicht besser weiß. Aber diesen mittelfristig Folgekosten erzeugenden "Pragmatismus" als Karriereprinzip zu erheben?
Der Grund warum ich Java (und die Community) so mag, ist das da wirklich über die Verbesserung der Infrastruktur, die einem auf soliden Ausbau seiner Kenntnisse bemühten Entwickler begegnet, nachgedacht wird. Hiermit meine ich Projektplanung (UML, Rational XDE, Poseidon, etc.), Testverfahren (Junit Tests, Profiling) und Integration derselben in IDEs, Deployment, Build-Prozeß (Ant). Spezifikationen, Komponenten für wiederkehrende Aufgaben wie O/R Mapping, Transaktionen, etc.
Natürlich kann das -wie oben gesehen- immer unterlaufen werden.
Gruß Axel
