Was ich diese Woche gelernt habe (Woche 47/2013)

Jede Woche schreibe ich einen Blogbeitrag, der beschreibt, was ich in dieser Woche gelernt habe. Ich schreibe diese Blogbeiträge aus zwei Gründen.

Zuerst , ich möchte meine persönliche Entwicklung im Auge behalten, und das Schreiben regelmäßiger Blogbeiträge ist eine großartige Möglichkeit, dies zu tun.

Zweiter , ich möchte meine Erkenntnisse mit Ihnen teilen. Ich hoffe, dass Sie einige davon in Ihrer täglichen Arbeit verwenden können.

Fangen wir an und finden heraus, was ich in Woche 47 gelernt habe.

Was ich in Woche 47 gelernt habe

Zuerst , Nehmen Sie sich Zeit, Ihren Build-Prozess zu entwerfen und zu konfigurieren, wenn Sie ein neues Projekt starten.

Wie viele von Ihnen beginnen ein neues Projekt, indem sie das Build-Skript aus einem vorhandenen Projekt kopieren? Ich habe festgestellt, dass dies eine ziemlich übliche Praxis ist, und ich habe dies mehrere Male getan. Die Verwendung eines vorhandenen Build-Skripts ist schließlich sinnvoll, da es viel Zeit spart und dafür sorgt, dass wir den Build-Prozess sehr gut kennen.

Dieser Ansatz hat ein großes Problem:

Unterschiedliche Projekte erfordern unterschiedliche Build-Prozesse .

Wenn Sie ein Projekt starten, indem Sie ein Build-Skript aus einem vorhandenen Projekt kopieren und unverändert verwenden, gehen Sie das Risiko ein, dass der Build-Prozess für Ihr aktuelles Projekt nicht optimal ist. Im schlimmsten Fall übertragen Sie die Probleme des Build-Prozesses in Ihr neues Projekt.

Sie möchten dies nicht tun . Stattdessen sollten Sie sich etwas Zeit nehmen und herausfinden, welche Art von Build-Prozess Sie wirklich brauchen. Sie sollten Antworten auf die folgenden Fragen finden:

• Welches Build-Tool sollte ich verwenden?
• Wie integriere ich meinen Build in den Continuous-Integration-Server?
• Sollte ich ein Projekt mit mehreren Modulen erstellen?
• Wie soll ich meine Anwendung bereitstellen?

Nachdem Sie die Antworten auf diese Fragen herausgefunden haben, können Sie sehen, ob das vorhandene Build-Skript Ihre Probleme löst. Denken Sie daran, dass Sie mit Ihren Entscheidungen leben müssen. Daher ist es ratsam sicherzustellen, dass Sie die richtigen Entscheidungen treffen.

Zweiter , Seien Sie nicht zu kreativ!

Frameworks sind dazu da, erweitert zu werden, und das Erweitern eines Frameworks ist eine gute Möglichkeit, das Verhalten des Frameworks zu ändern. Dies ist jedoch nur sicher, wenn Sie die bereitgestellten Erweiterungspunkte verwenden. Wenn Sie zu kreativ werden, können Probleme auftreten, wenn Sie das Framework auf eine neuere Version aktualisieren.

Ich bin auf diese Mine getreten.

Ich hatte sowohl Unit- als auch Integrationstests für meine Controller geschrieben, indem ich das spring-test-mvc-Projekt verwendet hatte. Um die Sache noch schlimmer zu machen, hatte ich eine JUnit-Regel erstellt, die meine Tests konfigurierte. Als ich das Projekt aktualisierte, um Spring Framework 3.2 zu verwenden, musste ich meine Tests migrieren, um das Spring MVC Test Framework zu verwenden.

Leider wurde meine benutzerdefinierte JUnit-Regel durch dieses Update verletzt, und ich musste meine Tests korrigieren. Glücklicherweise hat das nicht allzu lange gedauert, aber ich habe eine unschätzbare Lektion gelernt:

Sei nicht zu kreativ!

Dritter , ich weiß nicht genug über Garbage Collection.

Ich schäme mich ein bisschen, das zuzugeben, aber mein Wissen über den Garbage-Collection-Mechanismus von JVM ist ziemlich begrenzt. Dies wurde deutlich, als wir bemerkten, dass unser Produktionsserver viel Zeit mit der Garbage Collection verbrachte. Die Situation war so schlimm, dass es nicht mehr auf Anfragen reagierte, während die Garbage Collection lief.

Ich hatte keine Ahnung, wie ich dieses Problem lösen könnte.

Dann sind wir auf diesen Gist gestoßen (Danke Joe), der unser Problem gelöst hat (oder zumindest sieht es im Moment so aus).

Meine Arbeit ist jedoch noch nicht getan. Mein nächstes Ziel ist es, herauszufinden, wie Garbage Collection wirklich funktioniert.

Wenn Sie gute Tutorials dazu kennen, lassen Sie es mich wissen!

Vierter , Überarbeiten Sie Ihren Code nicht.

Die Implementierung der ersten Version einer Funktion ist oft ziemlich einfach, und es ist nicht allzu schwer, sauberen Code zu schreiben. Die Chancen stehen jedoch gut, dass Ihr Kunde bemerkt, dass die Funktion nicht ordnungsgemäß funktioniert, wenn Sie diese Funktion in der Produktionsumgebung bereitstellen. Er erkennt, dass es auch einige Ausnahmesituationen gibt, die unterstützt werden müssen.

Hier müssen Sie sich entscheiden:

• Sie können Ihrem Code eine schnelle Lösung hinzufügen
• Sie können Ihren Code umgestalten

Obwohl das Hinzufügen einer schnellen Lösung ein bisschen schlecht klingt, ist es oft das Beste, was man tun kann. Wenn Sie nur mit wenigen Ausnahmen umgehen müssen, macht es keinen Sinn, Ihren Code zu überarbeiten, da dies einfache Dinge schwieriger macht, als sie sein sollten.

Wenn die Anzahl der Ausnahmen jedoch zunimmt, werden Sie irgendwann einen Punkt erreichen, an dem Ihr Code so chaotisch ist, dass es nicht mehr sinnvoll ist, ihm eine weitere schnelle Lösung hinzuzufügen.

Das ist der Punkt, an dem Sie Ihren Code neu gestalten müssen .

Fünfter , Spring Batch verwenden.

Das Spring-Framework bietet eine einfache Möglichkeit, geplante Jobs zu erstellen, indem es @Scheduled verwendet Anmerkung. Dies ist eine praktische Möglichkeit, kleine geplante Jobs zu implementieren, die keine Informationen aus einem anderen System importieren oder in ein anderes System exportieren.

Wenn Sie andererseits "mehr" komplexe geplante Jobs implementieren müssen, sollten Sie ernsthaft über die Verwendung von Spring Batch nachdenken. Es ist kein Zeitplanungs-Framework, und Sie müssen immer noch einen Weg finden, Ihre Jobs zu planen.

Spring Batch befreit Sie jedoch davon, den Installationscode zu schreiben, der Ihre Komponenten zusammenklebt. Dies ist äußerst wertvoll, da das Schreiben von Installationscode überraschend schwierig ist, wenn Sie einen anständigen Fehlerbehandlungsmechanismus implementieren. Und wenn Sie das nicht tun, sind Ihre Jobs ziemlich lahmgelegt.

Tun Sie sich selbst einen Gefallen und werfen Sie einen Blick auf Spring Batch. Vielleicht können Sie es in Ihrem nächsten Projekt verwenden.

Richtig?

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.