13 Fehler, vor denen Java-Veteranen auf der Hut sein sollten

Probleme, die während des Produktionsprozesses auftreten, geraten nach und nach in die Aufmerksamkeit des mittleren und oberen Managements. Unabhängig davon, ob Sie Entwickler oder Architekt sind, sollten Sie den folgenden Punkten genügend Aufmerksamkeit schenken, um in Zukunft nicht in peinliche Situationen zu geraten. Sie können es auch als Hinweis zur Fehlerbehebung verwenden.

#1. Konfigurationseigenschaften nicht in Eigenschaftendateien oder XML-Dateien externalisieren. Beispielsweise ist die Anzahl der von der Stapelverarbeitung verwendeten Threads in der Eigenschaftendatei nicht als konfigurierbar festgelegt. Ihr Batch-Programm kann sowohl in einer DEV-Umgebung als auch in einer UAT-Umgebung (User Acceptance Test) reibungslos ausgeführt werden. Sobald es jedoch auf PROD bereitgestellt wird und als Multithread-Programm zur Verarbeitung größerer Datensätze verwendet wird, wird eine IOException ausgelöst , entweder aufgrund unterschiedlicher JDBC-Treiberversionen oder aufgrund des in Nr. 2 besprochenen Problems. Wenn die Anzahl der Threads in einer Eigenschaftendatei konfiguriert werden kann, ist es sehr einfach, daraus eine Single-Thread-Anwendung zu machen. Wir müssen Anwendungen nicht mehr wiederholt bereitstellen und testen, um Probleme zu lösen. Diese Methode eignet sich auch zum Konfigurieren von URL, Server- und Portnummer usw.

#2. Die Größe des im Test verwendeten Datensatzes ist unangemessen. Ein typisches Szenario in der Produktion besteht beispielsweise darin, nur 1 bis 3 Konten zum Testen zu verwenden, obwohl die Anzahl 1000 bis 2000 betragen sollte. Bei Leistungstests müssen die verwendeten Daten real und unbeschnitten sein. Leistungstests, die nicht nah an der realen Umgebung sind, können zu unvorhersehbaren Leistungs-, Erweiterungs- und Multithreading-Problemen führen. Nur durch das Testen der Anwendung mit größeren Datensätzen können Sie garantieren, dass sie ordnungsgemäß funktioniert und SLAs (Service Level Standards) für nicht funktionale Attribute erfüllt.

#3. Glauben Sie naiv, dass die in der Anwendung aufgerufenen externen und internen Dienste zuverlässig und immer verfügbar sind. Wenn Zeitüberschreitungen und Wiederholungsversuche bei Serviceaufrufen nicht zugelassen werden, wirkt sich dies negativ auf die Stabilität und Leistung der Anwendung aus. Es sind ordnungsgemäße Dienstausfalltests erforderlich. Dies ist wichtig, da heutige Anwendungen meist verteilt und serviceorientiert sind und eine große Anzahl von Netzwerkdiensten erfordern. Das endlose Anfordern nicht verfügbarer Dienste kann Ihrer Anwendung schaden. Der Load Balancer muss ebenfalls getestet werden, um sicherzustellen, dass er ordnungsgemäß funktioniert, um jeden Knoten im Gleichgewicht zu halten.

#4. Nichteinhaltung der Mindestsicherheitsanforderungen. Wie oben erwähnt, sind Netzwerkdienste allgegenwärtig, was es Hackern leicht macht, sie für Denial-of-Service-Angriffe auszunutzen. Wenn Sie Secure Sockets Layer verwenden, ist es daher wichtig, eine grundlegende Verifizierung durchzuführen und Penetrationstests mit Tools wie Google Skipfish durchzuführen. Eine unsichere Anwendung gefährdet nicht nur ihre eigene Stabilität, sondern kann sich aufgrund von Datenintegritätsproblemen auch negativ auf den Ruf eines Unternehmens auswirken, beispielsweise wenn Kunde „A“ die Daten von Kunde „B“ einsehen kann.

#5. Es gibt keine browserübergreifenden Kompatibilitätstests. Heutige Webanwendungen sind meist umfangreiche Einzelseitenanwendungen, die die Programmiersprache JavaScript und Frameworks wie Angular JS verwenden. Damit die von Ihnen erstellte Website auf verschiedenen Geräten und Browsern reibungslos funktioniert, müssen Sie ein entsprechendes Design implementieren. Um sicherzustellen, dass Ihre App auf allen Geräten und Browsern funktioniert, muss sie auf Kompatibilität getestet werden.

#6. Veräußern Sie keine Geschäftsregeln, die sich häufig ändern können. Zum Beispiel Steuergesetze, behördliche oder branchenbezogene Anforderungen, Taxonomien usw. Sie können eine Engine wie Drools verwenden, um Geschäftsregeln zu verarbeiten, was Ihnen hilft, diese Geschäftsregeln zu externalisieren, indem Sie sie in einer Datenbank oder Excel speichern. Sobald Unternehmen diese Geschäftsregeln beherrschen, können sie mit minimalen Änderungen und Tests schnell auf Steuergesetze oder damit verbundene Anforderungen reagieren.

#7. Die folgenden Dokumente werden nicht bereitgestellt

Schreiben Sie Unit-Testdokumente und sorgen Sie dafür, dass sie eine gute Codeabdeckung aufweisen.

Integrationstests.

Eine umfassende oder enzyklopädische Seite, die alle Softwarekomponenten wie Klassen, Skripte, Konfigurationsdateien usw. auflistet, die entweder geändert oder neu erstellt wurden.

Das übergeordnete Konzeptdiagramm zeigt alle Komponenten, Interaktionen und Strukturen.

Das Basisdokument erklärt Entwicklern, „wie man eine Entwicklungsumgebung basierend auf detaillierten Informationen über Datenquellen erstellt“.

Neben COS (Conditions of Satisfaction), einem von MindMap erstellten Formular, gibt es in der agilen Entwicklung zwei Hauptdokumentformen, 1 und 2.

#8. Kein ordnungsgemäßer Notfallwiederherstellungsplan und keine richtige Systemüberwachungs- und Archivierungsstrategie. Wenn die Projektfristen näher rücken, werden diese Dinge in der Eile, das Projekt umzusetzen, oft übersehen. Wenn mit Nagios und Splunk keine ordnungsgemäße Systemüberwachung eingerichtet wird, gefährdet dies nicht nur die Anwendungsstabilität, sondern behindert auch aktuelle Diagnosen und zukünftige Verbesserungsbemühungen.

#9. Es gibt kein praktisches Spaltendesign für Datenbanktabellen wie „created_datetm“, „update_datetm“, „created_by“, „update_by“ und „timestamp“. Es gibt auch keine Spalte zum ordnungsgemäßen Löschen von Datensätzen, wie „Y“ oder „N“. . Spalte „gelöscht“ oder Spalte „record_status“, die „Aktiv“ oder „Inaktiv“ sein kann.

#10. Versäumnis, einen geeigneten Retracement-Plan zu entwickeln. Wenn das System ausfällt, gibt es daher keine Möglichkeit, den stabilen Zustand des Systems vor der Bereitstellung wiederherzustellen. Dieser Plan muss sorgfältig geprüft und vom zuständigen Team unterzeichnet werden. Zu den Plänen gehört ein Rollback auf eine frühere Version der Software sowie das Entfernen aller in die Datenbank eingefügten Daten und aller Einträge in der Eigenschaftendatei.

#11. Vor Projektbeginn wurde kein Kapazitätsplan entwickelt. Heutzutage reicht es bei der Angabe von Plattformanforderungen nicht mehr aus, einfach zu sagen: „Erfordert eine Unix-Maschine, einen Oracle-Datenbankserver und einen JBoss-Anwendungsserver.“ Ihre Anforderungen müssen genau auf die

spezifische Version des Betriebssystems, der JVM usw. zugeschnitten sein.

Wie viel Speicher (einschließlich physischer Speicher, JVM-Heap-Speicher, JVM-Stack-Speicher und permanenter JVM-Generierungsraum).

CPU (Anzahl der Kerne).

Load Balancer, erforderliche Anzahl von Knoten, Knotentyp, z. B. aktiv/aktiv oder aktiv/passiv, und Clustering-Anforderungen.

Anforderungen an das Dateisystem. Beispielsweise kann Ihre Anwendung generierte Berichte sammeln und ein Jahr lang speichern, bevor sie archiviert wird. In diesem Fall müssen Sie über ausreichend Festplattenspeicher verfügen. Einige Anwendungen erfordern die Generierung von Datenextraktionsdateien und deren temporäre Speicherung zur Verwendung durch andere Systemprozesse oder Data-Warehouse-Systeme für mehrdimensionale Analyseberichte. Es gibt auch Datendateien, die auf dem Secure File Transfer Protocol basieren, die entweder von internen oder externen Systemen stammen und vor der Archivierung 12 bis 36 Monate lang aufbewahrt werden müssen.

Nr. 12 unten stammt aus dem Kommentar von „David DeCesare“ aus „java.dzone“,

Nr. 12: „Verwenden Sie nicht das beste Werkzeug für den Job.“ In vielen Fällen verwenden Entwickler eine Sprache oder ein Tool, das sie in einem Produktionssystem erlernen möchten. Normalerweise ist dies nicht die beste Option. Verwenden Sie beispielsweise NoSQL-Datenbanken für Daten, die bereits tatsächlich relational sind. Denken Sie daran, dass Sie Ihr Produkt unabhängig davon, welches Tool Sie verwenden, für die nächsten 3 bis 5 Jahre (oder sogar länger) warten müssen.

#13. Mangel an ausreichenden Wissensreserven in 16 wichtigen technischen Bereichen. Zu diesen Bereichen gehört die Identifizierung und Behebung von 1) „Parallelitätsproblemen“, 2) Transaktionsproblemen und 3) Leistungsproblemen. In vielen Interviews habe ich mich auf diese drei Wissensaspekte verlassen, um neue Verträge zu bekommen.