Im Produktionsprozess auftretende Probleme erhalten nach und nach 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 konfigurierbar. 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 #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 während der Produktion besteht beispielsweise darin, nur 1 bis 3 Konten zum Testen zu verwenden, obwohl die Anzahl 1.000 bis 2.000 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 einem größeren Datensatz können Sie sicherstellen, 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. Mindestsicherheitsanforderungen werden nicht eingehalten. Wie oben erwähnt, sind Netzwerkdienste allgegenwärtig, was es Hackern leicht macht, sie für Denial-of-Service-Angriffe auszunutzen. Daher müssen Sie bei der Verwendung von Secure Sockets Layer eine grundlegende Überprüfung durchführen und Penetrationstests mit Tools wie Google Skipfish durchfü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. Keine browserübergreifenden Kompatibilitätstests. Heutige Webanwendungen sind meist umfangreiche Single-Page-Anwendungen, 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. Geschäftsregeln, die sich häufig ändern können, nicht externalisieren. 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 dabei 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
Neben COS (Conditions of Satisfaction), einem von MindMap erstellten Formular, gibt es in der agilen Entwicklung zwei Hauptdokumentformen, 1 und 2.
#8. Es fehlt ein ordnungsgemäßer Notfallwiederherstellungsplan und keine Systemüberwachungs- und Archivierungsstrategie. Wenn die Projektfristen näher rücken, werden diese Dinge in der Eile, das Projekt umzusetzen, oft übersehen. Eine unzureichende Systemüberwachung mit Nagios und Splunk gefährdet nicht nur die Stabilität Ihrer Anwendung, sondern behindert auch aktuelle Diagnosen und zukünftige Verbesserungsbemühungen.
#9. Es gibt kein praktisches Spaltendesign für die Datenbanktabelle , z. B. „created_datetm“, „update_datetm“, „created_by“, „update_by“ und „timestamp“. Es werden auch keine geordneten Löschdatensatzspalten bereitgestellt, z. B. die Spalte „gelöscht“, die „Y“ oder „deleted“ annehmen kann „N“. Oder Sie können die Spalte „record_status“ mit „Aktiv“ oder „Inaktiv“ verwenden.
#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. Versäumnis, vor Beginn des Projekts einen Kapazitätsplan zu entwickeln. Heutzutage reicht es bei der Beschreibung von Plattformanforderungen nicht mehr aus, einfach zu sagen: „Erfordert einen Unix-Computer, einen Oracle-Datenbankserver und einen JBoss-Anwendungsserver.“ Ihre Anfrage muss präzise sein
#12 unten stammt aus einem Kommentar von „David DeCesare“ aus „java.dzone“,
#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.