J2EE Projekt Gefahren!

In meinen verschiedenen Amtszeiten als Entwickler, leitender Entwickler und Architekt habe ich das Gute, das Schlechte und das Hässliche gesehen, wenn es um Java-Unternehmensprojekte geht! Wenn ich mich frage, was ein Projekt zum Erfolg und ein anderes zum Scheitern bringt, ist es schwierig, die perfekte Antwort zu finden, da der Erfolg für alle Softwareprojekte schwer zu definieren ist . J2EE-Projekte sind keine Ausnahme. Stattdessen sind Projekte in unterschiedlichem Maße erfolgreich oder scheitern. In diesem Artikel möchte ich die zehn wichtigsten Gefahren, die sich auf den Erfolg eines Java-Unternehmensprojekts auswirken, für Sie als Leser vorstellen.

Einige dieser Gefahren verlangsamen einfach das Projekt, andere sind falsche Wege, und wieder andere können jede Erfolgschance völlig ruinieren. Alle sind jedoch mit guter Vorbereitung, Kenntnissen über die bevorstehende Reise und lokalen Führern, die das Gelände kennen, vermeidbar.

Dieser Artikel ist einfach aufgebaut. Ich werde jede Gefahr wie folgt abdecken:

  • Name der Gefahr: Einzeiler, der die Gefahr umreißt
  • Projektphase: Die Projektphase, in der die Gefahr auftritt
  • Betroffene Projektphase (n): In vielen Fällen können sich Gefahren auf spätere Projektphasen auswirken
  • Symptome: Mit dieser Gefahr verbundene Symptome
  • Lösung: Möglichkeiten, die Gefahr insgesamt zu vermeiden und die Auswirkungen auf Ihr Projekt zu minimieren
  • Anmerkungen: Ich möchte Punkte vergeben, die sich auf die Gefahr beziehen, aber nicht in die vorherigen Kategorien passen

Wie oben erwähnt, werden wir jede Gefahr im Kontext eines Java-Unternehmensprojekts zusammen mit seinen wichtigen Phasen untersuchen. Die Projektphasen umfassen:

  • Lieferantenauswahl: Der Prozess der Auswahl des bestmöglichen Werkzeugmixes vor dem Start Ihres J2EE-Projekts - vom Anwendungsserver bis hin zu Ihrer Kaffeemarke.
  • Design: Zwischen einer strengen Wasserfallmethode und einem Ansatz von "Code it and see" liegt meine Sicht auf Design: Ich mache genug Design, damit ich bequem in die Entwicklung einsteigen kann. Ich betrachte meine Entwurfsphase als abgeschlossen, wenn ich genau weiß, was ich baue und wie ich es bauen werde. Darüber hinaus verwende ich Entwurfsvorlagen, um sicherzustellen, dass ich mir und meiner vorgeschlagenen Lösung alle richtigen Fragen gestellt habe, bevor ich mit der Entwicklung beginne. Ich habe jedoch keine Angst, in dieser Phase zu codieren. Manchmal ist dies die einzige Möglichkeit, eine Frage zu Leistung, Modularität oder Beantwortung zu beantworten.
  • Entwicklung: Die Projektphase, in der der Arbeitsaufwand in früheren Phasen angezeigt wird. Eine gute Auswahl an Werkzeugen in Verbindung mit einem guten Design bedeutet nicht immer eine reibungslose Entwicklung, aber es hilft auf jeden Fall!
  • Stabilisierungs- / Lasttests: In dieser Phase werden der Systemarchitekt und der Projektmanager ein Einfrieren der Funktionen verhängen und sich auf die Build-Qualität konzentrieren sowie sicherstellen, dass die wichtigen Statistiken des Systems - Anzahl der gleichzeitigen Benutzer, Failover-Szenarien usw. - kann getroffen werden. Qualität und Leistung sollten jedoch erst in dieser Phase ignoriert werden. In der Tat können Sie keinen Code mit schlechter oder langsamer Qualität schreiben und ihn bis zur Stabilisierung reparieren lassen.
  • Live: Dies ist nicht wirklich eine Projektphase, sondern ein in Stein gemeißeltes Datum. In dieser Phase dreht sich alles um die Vorbereitung. Hier kommen die Geister vergangener Fehler zurück, um Ihr Projekt zu verfolgen, von schlechtem Design und Entwicklung bis hin zu einer schlechten Auswahl an Anbietern.

Abbildung 1 zeigt die Projektphasen, die am stärksten von den verschiedenen Ursachen (und insbesondere den Auswirkungen) betroffen sind.

Na dann, ohne weiteres, lasst uns direkt in die Top 10 eintauchen!

Gefahr 1: Java nicht verstehen, EJB nicht verstehen, J2EE nicht verstehen

Richtig, ich werde dieses zur einfacheren Analyse in drei Unterelemente aufteilen.

Beschreibung: Java wird nicht verstanden

Projektphase:

Entwicklung

Betroffene Projektphase (n):

Design, Stabilisierung, Live

Betroffene Systemeigenschaften:

Wartbarkeit, Skalierbarkeit, Leistung

Symptome:

  • Neuimplementierung von Funktionen und Klassen, die bereits in den JDK-Kern-APIs enthalten sind
  • Sie wissen nicht, was einige oder alle der folgenden Elemente sind und was sie tun (diese Liste enthält nur eine Auswahl von Themen):
    • Garbage Collector (Zug, Generation, inkrementell, synchron, asynchron)
    • Wenn Objekte durch Müll gesammelt werden können - baumelnde Referenzen
    • In Java verwendete Vererbungsmechanismen (und ihre Kompromisse)
    • Methode Überfahren und Überladen
    • Warum java.lang.String(ersetzen Sie hier Ihre Lieblingsklasse!) Erweist sich als schlecht für die Leistung
    • Pass-by-Referenzsemantik von Java (versus Pass-by-Wertesemantik in EJB)
    • Verwenden ==versus Implementieren der equals()Methode für Nichtprimitive
    • Wie Java Threads auf verschiedenen Plattformen plant (z. B. vorbeugend oder nicht)
    • Grüne Fäden versus native Fäden
    • Hotspot (und warum alte Techniken zur Leistungsoptimierung Hotspot-Optimierungen negieren)
    • Die JIT und wenn gute JITs schlecht werden (nicht gesetzt JAVA_COMPILERund Ihr Code läuft einwandfrei usw.)
    • Die Sammlungs-API
    • RMI

Lösung:

Sie müssen Ihre Java-Kenntnisse verbessern, insbesondere seine Stärken und Schwächen. Java existiert weit über die Sprache hinaus. Ebenso wichtig ist es, die Plattform (JDK und Tools) zu verstehen. Konkret sollten Sie sich als Java-Programmierer zertifizieren lassen, wenn Sie es noch nicht sind - Sie werden erstaunt sein, wie viel Sie nicht wussten. Noch besser, mach es als Teil einer Gruppe und drücke dich gegenseitig. Auf diese Weise macht es auch mehr Spaß. Richten Sie außerdem eine Mailingliste für die Java-Technologie ein und halten Sie sie am Laufen! (Jedes Unternehmen, mit dem ich zusammengearbeitet habe, verfügt über diese Listen, von denen die meisten aufgrund von Inaktivität lebenserhaltend sind.) Lernen Sie von Ihren Peer-Entwicklern - sie sind Ihre beste Ressource.

Anmerkungen:

Wenn Sie oder andere Mitglieder Ihres Teams die Programmiersprache und die Plattform nicht verstehen, wie können Sie dann hoffen, eine erfolgreiche Java-Unternehmensanwendung zu erstellen? Starke Java-Programmierer nehmen EJB und J2EE wie Enten ins Wasser. Im Gegensatz dazu erstellen arme oder unerfahrene Programmierer J2EE-Anwendungen von schlechter Qualität.

Beschreibung: EJB nicht verstehen

Projektphase:

Design

Betroffene Projektphase (n):

Entwicklung, Stabilisierung

Betroffene Systemeigenschaften:

Instandhaltung

Symptome:

  • EJBs, die funktionieren, wenn sie zum ersten Mal aufgerufen werden, jedoch nie danach (insbesondere zustandslose Session-Beans, die an den Ready-Pool zurückgegeben werden)
  • Nicht wiederverwendbare EJBs
  • Sie wissen nicht, wofür der Entwickler verantwortlich ist, verglichen mit dem, was der Container bietet
  • EJBs, die nicht der Spezifikation entsprechen (Feuerthreads, Laden nativer Bibliotheken, Versuch, E / A auszuführen usw.)

Lösung:

Nehmen Sie sich ein Wochenende Zeit und lesen Sie die EJB-Spezifikation (die Version 1.1 umfasst 314 Seiten), um Ihre EJB-Kenntnisse zu verbessern. Lesen Sie dann die 2.0-Spezifikation (524 Seiten!), Um ein Gefühl dafür zu bekommen, was in der 1.1-Spezifikation nicht behandelt wurde und wohin Sie die 2.0-Spezifikation führen wird. Konzentrieren Sie sich auf die Teile der Spezifikation, die Ihnen als Anwendungsentwickler mitteilen, welche rechtlichen Schritte in einem EJB erforderlich sind. Die Abschnitte 18.1 und 18.2 sind gute Ausgangspunkte.

Anmerkungen:

Betrachten Sie die EJB-Welt nicht mit den Augen Ihres Anbieters. Stellen Sie sicher, dass Sie den Unterschied zwischen den Spezifikationen, die dem EJB-Modell zugrunde liegen, und einer bestimmten Einstellung kennen. Dadurch wird auch sichergestellt, dass Sie Ihre Fähigkeiten nach Bedarf auf andere Anbieter (oder Versionen) übertragen können.

Beschreibung: J2EE wird nicht verstanden

Projektphase:

Design

Betroffene Projektphase (n):

Entwicklung

Betroffene Systemeigenschaften:

Wartung, Skalierbarkeit, Leistung

Symptome:

  • Das Design "Alles ist ein EJB"
  • Manuelle Transaktionsverwaltung anstelle der von Containern bereitgestellten Mechanismen
  • Benutzerdefinierte Sicherheitsimplementierungen - Die J2EE-Plattform verfügt wahrscheinlich über die vollständigste und integrierteste Sicherheitsarchitektur im Bereich Enterprise Computing, von der Präsentation bis zum Back-End. es wird selten in vollem Umfang genutzt

Lösung:

Erfahren Sie mehr über die wichtigsten Komponenten von J2EE und welche Vor- und Nachteile jede Komponente mit sich bringt. Decken Sie jeden Service der Reihe nach ab. Wissen ist hier gleich Macht.

Anmerkungen:

Nur Wissen kann diese Probleme beheben. Gute Java-Entwickler sind gute EJB-Entwickler, die wiederum ideal positioniert sind, um J2EE-Gurus zu werden. Je mehr Java- und J2EE-Kenntnisse Sie besitzen, desto besser können Sie entwerfen und implementieren. Zur Entwurfszeit beginnen die Dinge für Sie zu passen.

Gefahr 2: Überentwicklung (an EJB oder nicht an EJB)

Projektphase:

Design

Betroffene Projektphase (n):

Entwicklung

Betroffene Systemeigenschaften:

Wartung, Skalierbarkeit, Leistung

Symptome:

  • Übergroße EJBs
  • Entwickler, die nicht erklären können, was ihre EJBs tun und welche Beziehungen zwischen ihnen bestehen
  • Nicht wiederverwendbare EJBs, Komponenten oder Services, wenn sie sein sollten
  • EJBs starten neue Transaktionen, wenn eine bestehende Transaktion ausreicht
  • Datenisolationsstufen zu hoch eingestellt (um sicher zu gehen)

Lösung:

Die Lösung für Over-Engineering basiert direkt auf der XP-Methode (Extreme Programming): Entwerfen und codieren Sie das Nötigste, um die Anforderungen des Scoping zu erfüllen, und nicht mehr. Während Sie sich der zukünftigen Anforderungen bewusst sein müssen, z. B. der zukünftigen durchschnittlichen Lastanforderungen oder des Verhaltens des Systems zu Spitzenladezeiten, sollten Sie nicht überlegen, wie das System in Zukunft aussehen muss. Darüber hinaus definiert die J2EE-Plattform Merkmale wie Skalierbarkeit und Failover als Aufgaben, die die Serverinfrastruktur für Sie übernehmen soll.

Mit minimalen Systemen, die aus kleinen Komponenten bestehen, die darauf ausgelegt sind, eines zu tun und es gut zu machen, verbessert sich der Wiederverwendungsgrad ebenso wie die Systemstabilität. Darüber hinaus wird die Wartbarkeit Ihres Systems verbessert und zukünftige Anforderungen können viel einfacher hinzugefügt werden.

Anmerkungen:

Verwenden Sie zusätzlich zu den oben aufgeführten Lösungen Entwurfsmuster, die Ihr Systemdesign erheblich verbessern. Das EJB-Modell selbst verwendet häufig Entwurfsmuster. Zum Beispiel die

Home

Die Schnittstelle jedes EJB ist ein Beispiel für ein Finder- und Factory-Muster. Die Remote-Schnittstelle eines EJB fungiert als Proxy für die eigentliche Bean-Implementierung und ist von zentraler Bedeutung für die Fähigkeit des Containers, Anrufe abzufangen und Dienste wie den transparenten Lastausgleich bereitzustellen. Ignorieren Sie den Wert von Designmustern auf eigene Gefahr.

Eine weitere Gefahr, vor der ich immer wieder warne: EJB dafür verwenden. Einige Teile Ihrer Anwendung werden möglicherweise nicht nur als EJBs modelliert, wenn dies nicht der Fall sein sollte, sondern Ihre gesamte Anwendung verwendet möglicherweise EJBs ohne messbaren Gewinn. Dies ist eine Überentwicklung, die bis zum Äußersten geht, aber ich habe gesehen, dass perfekt gute Servlet- und JavaBean-Anwendungen ohne gute technische Gründe auseinandergerissen, neu gestaltet und unter Verwendung von EJBs implementiert wurden.

Gefahr 3: Präsentationslogik nicht von Geschäftslogik trennen

Projektphase:

Design

Betroffene Projektphase (n):

Entwicklung

Betroffene Systemeigenschaften:

Wartbarkeit, Erweiterbarkeit, Leistung

Symptome:

  • Große und unhandliche JSPs
  • Sie bearbeiten JSPs, wenn sich die Geschäftslogik ändert
  • Eine Änderung der Anzeigeanforderungen zwingt Sie dazu, EJBs und andere Backend-Komponenten zu bearbeiten und erneut bereitzustellen

Lösung:

Die J2EE-Plattform bietet Ihnen die Möglichkeit, die Präsentationslogik von der Navigation und Steuerung und schließlich von der Geschäftslogik zu trennen. Es wird als Modell 2-Architektur bezeichnet (einen guten Artikel finden Sie unter Ressourcen). Wenn Sie bereits in diese Falle geraten sind, ist eine steife Dosis Refactoring erforderlich. Sie sollten mindestens dünne vertikale Slices haben, die größtenteils in sich geschlossen sind (dh, wie ich ein Widget bestelle, ist ein separater Slice, wie ich meinen Benutzernamen oder mein Passwort ändere). Verwenden Sie diese implizite Organisation Ihres Systems, um schrittweise umzugestalten.

Anmerkungen:

Durch die Verwendung eines konsistenten Designs in Verbindung mit einem UI-Framework (z. B. Taglibs) können Sie auch sicherstellen, dass Sie Probleme mit der logischen Trennung in Ihrem Projekt vermeiden. Erstellen Sie kein weiteres GUI-Framework für Ihre eigenen Anforderungen, da zu viele gute Implementierungen verfügbar sind. Bewerten Sie sie nacheinander und wählen Sie das Framework aus, das Ihren Anforderungen am besten entspricht.

Gefahr 4: Nicht dort bereitstellen, wo Sie sich entwickeln

Projektphase:

Entwicklung

Betroffene Projektphase (n):

Stabilisierung, Parallel, Live

Betroffene Systemeigenschaften:

Deine geistige Gesundheit

Symptome:

  • Mehrtägige oder einwöchige Übergänge zu Live-Systemen
  • Das mit der Inbetriebnahme verbundene Risiko ist erheblich, da viele Unbekannte und wichtige Nutzungsszenarien nicht getestet wurden
  • Daten in Live-Systemen sind nicht mit Daten in Entwicklungs- oder Stabilisierungs-Setups identisch
  • Unfähigkeit, Builds auf Entwicklercomputern auszuführen
  • Das Anwendungsverhalten ist in den Entwicklungs-, Stabilisierungs- und Produktionsumgebungen nicht dasselbe

Lösung:

Die Lösung für Gefahr 4 beginnt damit, dass die Produktionsumgebung in Ihrer Entwicklungsumgebung originalgetreu dupliziert wird. Entwickeln Sie mit genau demselben Setup wie dem, auf dem Sie live gehen möchten. Entwickeln Sie nicht unter JDK 1.3 und Red Hat Linux, wenn Sie unter JDK 1.2.2 und Solaris 7 live gehen möchten auf einem Anwendungsserver und gehen Sie auf einem anderen live. Holen Sie sich auch eine Momentaufnahme der Daten aus der Produktionsdatenbank und verwenden Sie sie zum Testen. Verlassen Sie sich nicht auf künstlich erstellte Daten. Wenn Produktionsdaten sensibel sind, desensibilisieren Sie sie und laden Sie sie hoch. Unerwartete Produktionsdaten werden brechen:

  • Datenvalidierungsregeln
  • Getestetes Systemverhalten
  • Verträge zwischen Systemkomponenten (insbesondere EJB-EJB und EJB-Datenbank)

Am schlimmsten ist jedoch, dass jede dieser Ausnahmen zu Ausnahmen, Nullzeigern und Verhalten führt, die Sie noch nie zuvor gesehen haben.

Anmerkungen:

Entwickler verlassen die Sicherheit häufig bis zur Stabilisierung ("Ja, die Bildschirme funktionieren, jetzt fügen wir das Zeug zur Benutzerüberprüfung hinzu."). Vermeiden Sie diese Falle, indem Sie der Implementierung von Sicherheit dieselbe Zeit widmen wie der Geschäftslogik.