Ebenfalls. Diese Aussage stimmt so. gilt mit hoher Warscheinlichkeit irgendwann auch für J2EE. Dieses "Produkt" ist im Vergleich zu anderen noch am Anfang seines Lebenszyklus. Warten wir ab, wie es da mit der Komplexität in sagen wir einmal 10 Jahren ausschaut.
Ist wie diskutieren über ungelegte Eier, aber ich glaube (wissen kann man das nicht), dass man heute weiter ist hinsichtlich der "Reinhaltung" einer komplexen Architektur und auch ein stärkeres Bewusstsein für Software-Enthropie besitzt. Z.B. geht man auch bei Release-Wechseln härter vor. Z.B. hat sich Websphere Administration dramatisch geändert in 5. EJBs sind auch sehr anders in EJB2.0 gegenüber EJB1.2/1.1/1.0. Dieser Hang zum Neubau war sicher nicht immer lustig für die Projektverantwortlichen, hilft aber auch die Architektur reinzuhalten. In EJB3.0 wird noch einmal ein ernsthaft radikaler Wandel vollzogen.
[SkriptMonster]Und genau das glaube ich nicht. Es mag sein das das vielleicht etwas leichter möglich ist, Anwnedungen zu schreiben die keine "Monster" werden, aber: 99% aller Monster sind deswegen Monster weil ohne Plan von unterschieldichen Personen mit sehr unterschiedlichen Erfahrungsgraden daran gearbeitet wurde ohne einen "Masterplan" und jemand der ihn überwacht zu haben, Das es also Monster gibt liegt nach meiner Erfahrung nicht an der Sprache oder Umgebung in der eine Anwendung entwickelt wird, sondern an den Entwicklern.
Naja. Sehe ich z.T. auch so. Auf der anderen Seite ist die Planungsfähigkeit des Menschen eben beschränkt (s. Untergang des Kommunismus). Ich bin auch völlig hoffnungslos bezüglich des rationalen Verhaltens menschlicher Organisationen (Projektgruppe). Für rationales Verhalten braucht man:
1. vollständige Information (Softwareprojekte sind irgendwie immer auch Entdeckungsverfahren, dh man trifft auf unerwartetes und alle Leute überschätzen die Qualität der Informationen auf denen ihre Entscheidungen beruhen, inklusive explizit ich).
2. rational für das Gemeinwohl arbeitende Beteiligte. (Leute verfolgen aber auch immer subjektive Ziele und vieles hat mit Politik zu tun. Und: Es ist nicht immer so, aber ich glaub jeder hat schon Leute Projektpläne erstellen sehen, die stattdessen besser Mittags das Essen ausgegeben hätten.
Ausserdem: Die Agile-Bewegung hat klar darauf hingewiesen, dass die Requirements der Projekt-Anwender sich quasi immer während des Projekts ändern. Das stürzt den schönsten Plan um. Gerade deshalb benötigt man Entwickler, die changing requirements erwarten und trotzdem die Anwendung stabil halten. Unit Tests, Design Patterns, Kappselung durch OO, Kappselung durch geschichtete Architekturen helfen hier. Da glaub ich inzwischen ziemlich fest dran. Es ist nicht einfach und erfordert Erfahrung.
nur aus den Reaktionen an der Oberfläche auf den Fehler im Kern der Anwendung Rückschlüsse ziehen kann und muss, weil ich keine Sourcen auf die ich zugreifen kann zur Verfügung stehen habe, solange ist es egal, ob ich in C, C++, Perl, .Net , Java oder Lotus Script programmiere, ob ich Eclipse oder WSAD oder den Domino Designer als Framework benutze oder ob eine Relationale oder eine Domino Datenbank meine Datenbasis bildet. Ich sehe den Fehler nicht und kann daher nicht direkt auf das Problem schließen sondern muss mich dem Ziel auf Umwegen nähern.
Die Sourcen von Java sind weitgehend frei zugänglich. Perl ist soweit ich weiss openSource. Eclipse ist openSource. Viele RDBMS sind openSource (java: hsqldb, derby. c/c++(?): mySql, PosGreSQL (jetzt_auf_windows_ohne_cygwin.nett.btw)). Die Frage ist natürlich inwieweit man in der Lage ist, dort den Source code zu durchblicken. Immerhin gibt es gerade für OpenSource Projekte gute Foren.
Auch das hat meiner Meinung nach nichts mit J2EE zu tun sondern einfach mit der Tatsache, ob "sauber" programmiert und dokumentiert wurde. Jede Methode der Anwendungsentwicklung oder Analyse ist per se erst einmal unabhängig von einer bestimmten Sprache oder Umgebung. Worin ich dir beipflichte ist, das es durchaus Umgebungen gibt die bestimmte Methoden besser unterstützen als andere. Oder was das angeht Tools die die Analyse besser unterstützen.
Auch hier wieder großes (und vielleicht über-idealistisches) Armwinken von meiner Seite: Es hat noch nie einen Entwickler-Pool gegeben, der so intensiv und leidenschaftlich über die maintainability von Anwendungen nachgedacht und diskutiert hat als gerade Java Leute. Gut. Vielleicht SmallTalk. Aber das ist wirklich zu langsam. Bei C++ gab/gibt es glaub ich große Unterschiede. Das war - so weit ich es Überblicke - ab einem gewissen Level sehr elitär. Und ausserdem erlaubte die Sprache an sich große Unsauberkeiten.
Es geht nicht um die Erfüllung von "richtigen" Methoden. Methoden sind immer kontext-abhängig. Imho geht es um Wissen, Erfahrung und Skepsis. Methoden sind immer eingebettet in einem Kontext und sowas wie Rational Unified Process besteht bewusst rein aus optionalen Modulen.
Es geht nicht um Tools. Ich bin bekennender Rationale-Hasser. Tools können auch im Weg stehen. Haben hier gerade den Einsatz von Rational Test Director für das Projekt gekippt (haha).
Bin im letzten Jahr zu einem immer größeren Freund von leichtgewichtigen Prozessen und Tools geworden.
Axel
Umfrage
Thema: Sind Notesler zu sehr auf ihre Plattform fixiert? (Gelesen 6476 mal)