Wie man ein Java EE Projekt auditiert?

8

Ich muss die Qualität und Wartbarkeit der Code-Architektur prüfen (am Ende, um sicher zu gehen, dass wir haben, wofür wir bezahlt haben), ein Java EE Web-Projekt basierend auf JSF / CDI / EJB3.0 / JPA (um nur einige zu nennen) der beteiligten Technologien).

Dies ist vielleicht nicht der richtige Ort, um zu fragen, aber wie gehen Sie mit dieser Art von Aufgabe um? Grundsätzlich würde ich von grobkörnig zu feinkörnig, d. H. Von der gesamten Architektur zum Java-Code, gehen. Ist es besser, mit jeder Schicht vollständig fertig zu werden? Sollte ich mehr Zeit auf den Low-Level-Ebenen verbringen?

Bewerten Sie das Ganze (Build, Deployment, Test)?

    
LB40 01.11.2011, 09:58
quelle

5 Antworten

6

Auf der unteren physischen Ebene / Implementierungsebene möchte ich Maven als Build-Tool übernehmen und dann die umfangreiche Maven-Berichterstellung konfigurieren, um eine Website mit verschiedenen Code-Metriken zu erstellen.

  • Für den Anfang gibt es das Maven-Checkstyle-Plugin , das über Code-Konformität mit einem bestimmten Standard berichten kann Die Konsistenz der Codierungsstandards hat viele offensichtliche Vorteile, die meisten Projekte würden einfach einen der vorkonfigurierten Standards übernehmen, z Sonne oder Apache.
  • Das Findbugs-Plugin listet mögliche Programmierfehler auf
  • Es gibt eine Auswahl von Code-Coverage-Berichten, ich habe cobertura verwendet. Diese zeigen Zeile für Zeile in einer Anwendung, welche Teile durch Komponententests abgedeckt sind. Maven unterstützt Komponententests im Build-Lebenszyklus und führt sie als Teil des Builds aus. Das hat mich ein paar Mal gerettet.
  • Das PMD-Plug-In identifiziert doppelten Code und hebt Bereiche hervor, die möglicherweise refaktorisiert werden müssen.

Sobald dies eingerichtet ist und Teil des normalen Build-Zyklus wird, kümmert es sich im Grunde um sich selbst, und Sie müssen sich keine Sorgen mehr um große halbjährliche Audits / Nachholprozesse machen.

Viele der Berichte verfügen über Schwellenwerte, die so konfiguriert werden können, dass der Build bei einem Fehler fehlschlägt, d. h. mehr als n% Checkstyle-Fehler verursachen einen Buildfehler.

Maven fördert auch einen modularen Ansatz zum Erstellen von Anwendungen, dies führt zu kleineren verständlicheren und wiederverwendbaren Modulen sowie zu einer Trennung von Belangen, d. h. separaten Modulen für Darstellungs- und Persistenzschichten. Der Hauptvorteil, den Maven bietet, ist die Verwaltung der Abhängigkeiten zwischen den Modulen.

Das hilft Ihnen auf den höheren Ebenen der Architektur jedoch nicht sehr, daher wird ein ergänzender Ansatz benötigt, um diese Dimension abzudecken.

Siehe Beispielberichte unter diesem Link
Ссылка

    
crowne 01.11.2011 12:44
quelle
2

Um bei der Prüfung auf Code-Ebene und wahrscheinlich auch in der Projektumgebung zu helfen, ist eine SONAR-Software sehr hilfreich ... Es ist sehr einfach, nur einige maven-Befehle einzurichten, mit vielen bewährten Code-Standards wie Code-Qualität, Wiederverwendbarkeit, schlechte Praktiken Messungen und so weiter ...

it Läuft auf Ihrem Projekt SVN oder CVS und generieren Sie eine Website mit Grafiken für die Vergangenheit und den aktuellen Status der Metriken, die es erstellt, so können Sie die Projektdaten navigieren und verfolgen Sie die Verbesserungen oder Fehler.

Es verwendet auch all diese Maven und Maven Plugins, die in der anderen Antwort wie cobertura aufgelistet sind, finde Bugs usw. ...

Ссылка

Laden Sie einfach herunter und zeigen Sie auf Ihren Repo.

    
Cristiano Fontes 01.11.2011 12:54
quelle
0

Zusätzlich zu den bereits erwähnten Code-Metriken und statischen Analysen auf niedrigerer Ebene würde ich ein Tool wie Structure101 hinzufügen, um die Struktur und Abhängigkeiten auf höherer Ebene zu analysieren. Es kann auch beim Refactoring helfen.

Durch die Identifizierung von Abhängigkeitengruppen kann festgestellt werden, ob die App unter Berücksichtigung von Bedenken und Modularität geschrieben wurde, und sie kann helfen, potenzielle Schwachstellen zu erkennen, wenn Erweiterungen oder Änderungen in Betracht gezogen werden.

    
Dave Newton 01.11.2011 13:00
quelle
0

Achten Sie darauf, es in Bereiche von Interesse zu zerlegen und sie einzeln anzugehen. Bereiche, an die ich denken kann, sind:

  1. Konformität mit spezifizierten Anforderungen (hoffentlich sind diese spezifisch)
  2. Leistung / Skalierbarkeit
  3. Codequalität (einschließlich der Konventionen, denen Sie folgen möchten)
  4. Testabdeckung
  5. Plugin / Bibliothekslizenzen

Offenbar haben andere die Punkte 3 und 4 angesprochen. Da Sie die Frage jetzt stellen (vermutlich nachdem Sie das Produkt erhalten haben) müssen 1 und 2 wahrscheinlich manuell verarbeitet werden, es sei denn, Sie haben automatisierte Funktionstests bereits geschrieben (oder möchten Tests automatisieren, damit Sie zukünftige Versionen von dem, was Sie gekauft haben, überprüfen können). 5 ist ein Gegenstand, der manchmal übersehen wird, aber sehr wichtig sein kann. Sie möchten wahrscheinlich nicht, dass GPL-Code eingebunden wird, wenn Sie diese Software weiterverkaufen. Sie müssen die Lizenzen jeder enthaltenen Bibliothek überprüfen und entscheiden, welche mit Ihren Zielen kompatibel sind.

    
Jared 01.11.2011 13:51
quelle
0

Um Ihre Architektur zu verstehen, können Sie versuchen JavaDepend es gibt die Möglichkeit, Code mit CQL, wie SQL für Datenbank, mit mehr als 82 Metriken und viele interaktive Ansichten, um tief in Ihr Design, Ihre Architektur und Ihre Implementierung einzudringen.

    
quelle

Tags und Links