Java >> Java Tutorial >  >> Java

Was ich diese Woche gelernt habe (Woche 35/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 35 gelernt habe.

Was ich in Woche 35 gelernt habe

Zuerst , Manchmal (meistens) ist das Lesen von Referenzdokumenten NICHT Zeitverschwendung. Diese Woche habe ich an meiner Spring Social-Beispielanwendung gearbeitet, die zeigt, wie wir Spring Social 1.1.0 mit Spring Security 3.2 integrieren können.

Mein Fortschritt war sehr langsam, weil ich dem Referenzhandbuch von Spring Social 1.1.0 keine Beachtung geschenkt hatte. Da ich dabei lerne, konnte ich meinen Experimentierdrang nicht zügeln. Es hat Spaß gemacht, aber auch für viel Frustration gesorgt.

Irgendwann beschloss ich, das Referenzhandbuch zu lesen, und stellte fest, dass es Antworten auf meine Fragen gab. Ich weiß, dass echte Männer keine Handbücher lesen, aber wenn Sie die Arbeit so schnell wie möglich erledigen möchten, ist das Lesen des Handbuchs der einzige Weg, dies zu tun.

Zweiter , Protokollierung ist wichtig. Diese Woche fügte ich einer bestehenden Anwendung eine interessante neue Funktion hinzu, als die Hölle losbrach. Ich erhielt einen Anruf von einem Kunden, der mir mitteilte, dass unsere Anwendung keine E-Mail-Benachrichtigungen sendet.

Ich ließ alles fallen, was ich tat, und fing an, die Protokolle zu lesen. Ich war ziemlich zuversichtlich, dass ich herausfinden konnte, was das Problem war, weil ich wusste, dass diese Anwendung eine Menge Zeug in das Protokoll schreibt.

Rate mal? Ich habe herausgefunden, dass es manchmal nicht ausreicht, viel Zeug in eine Protokolldatei zu schreiben. Sie müssen auch darüber nachdenken, was Sie in die Protokolldatei schreiben .

Das größte Problem war, dass ich keine Möglichkeit hatte, die Ausführung des Prozesses zu verfolgen, der eine E-Mail-Benachrichtigung auslöste. Deshalb konnte ich die Ursache des Problems nicht finden.

Als ich das Problem untersuchte, funktionierten die E-Mail-Benachrichtigungen wieder, aber ich wusste, dass meine Arbeit noch nicht beendet war. Ich muss die Protokollierung dieser Anwendung verbessern. Ich beginne mit dem Lesen der 10 Tipps für die richtige Protokollierung von Anwendungen.

Sie sollten dasselbe tun.

Dritter , Ein Produkt. Ein Meister. Jedes Produkt sollte nur eine Person haben, die das letzte Wort bei allen nicht-technischen Entscheidungen hat, die während des Projekts getroffen werden. Diese Person sollte auf die Meinungen anderer Menschen hören, aber er darf andere Menschen nicht bitten, Entscheidungen für ihn zu treffen.

Daran sollte er sich erinnern

  • Geteilte Verantwortung liegt in der Verantwortung von niemandem.
  • Jede Person hat eine versteckte Agenda. Diese Agenda entspricht möglicherweise nicht dem besten Interesse des Produkts.

Wenn Sie Produktmanager, Projektmanager oder Produkteigentümer sind, müssen Sie EIGENTUM Ihres Produkts sein . Sie müssen eine VISION haben über das Produkt und das GUTS, um Entscheidungen zu treffen .

Wenn das Produkt am Ende versagt, steht Ihr Hals auf dem Spiel . Sind Sie sicher, dass Sie sich daran erinnern?

Vierter , Erstellen Sie keine Objekte, ohne dem Prozess Bedeutung hinzuzufügen. Ich bin ein großer Fan des Builder-Musters, weil es mir hilft, Objekte zu erstellen, ohne das Teleskop-Konstruktor-(Anti-)Muster zu verwenden. Als ich anfing, das Builder-Muster zu verwenden, habe ich diese beiden Regeln befolgt:

  • Die Eigenschaftswerte der erforderlichen Eigenschaften wurden als Konstruktorargument an den Builder übergeben.
  • Optionale Eigenschaftswerte wurden mithilfe der Methoden der Builder-Klasse übergeben.

Allerdings stellte ich bald fest, dass viele Klassen (insbesondere Domänenmodellklassen) zu viele obligatorische Eigenschaften haben. Wenn ich die oben beschriebenen Regeln befolgt hätte, wäre der Konstruktor meiner Builder-Klasse dem (Anti-)Muster des teleskopierenden Konstruktors gefolgt.

Ich habe dieses Problem gelöst, indem ich diese Regeln geändert habe. Meine neuen Regeln waren folgende:

  • Die "wesentlichen" Eigenschaftswerte wurden als Konstruktorargument übergeben.
  • Alle anderen Eigenschaftswerte wurden mit den Methoden der Builder-Klasse übergeben.

Dann stieß ich auf diese beiden Fragen:

  • Was ist wichtig?
  • Wenn etwas so wichtig ist, sollte ich nicht beschreiben, was es bedeutet?

Das Problem meines zweiten Regelsatzes war, dass die wesentlichen Eigenschaftswerte manchmal schwierig zu finden sind. Auch die zweite Frage hat mich sehr beschäftigt. Obwohl der Konstruktor meiner Builder-Klasse normalerweise nur wenige Parameter hatte, konnte dies verwirrend sein.

Dann las ich diesen Blogbeitrag von Blake Caldwell.

Mir wurde klar, dass ich alle Eigenschaftswerte mithilfe von Methoden der Builder-Klasse festlegen konnte. Auf diese Weise konnte ich eine DSL erstellen, die den Aufbau eines Objekts beschreibt und die Lesbarkeit meines Codes verbessern.

Denken Sie daran, dass die Objekterstellung kein bedeutungsloser Prozess ist. Es gibt einen Grund, warum wir all diese Objekte erstellen. Sollten wir diesen Grund nicht jedem klar machen, der unseren Kodex liest?

Fünfter , wissen Sie, welche Methode die Ausnahme ausgelöst hat? Wenn Sie Unit-Tests mit JUnit schreiben, können Sie expected verwenden Attribut von @Test Anmerkung zur Angabe der Ausnahme, die während des Tests ausgelöst werden soll. Dieser Ansatz hat zwei Probleme:

  • Sie können nur den Typ der ausgelösten Ausnahme überprüfen. Manchmal ist es hilfreich, die geworfene Ausnahme etwas weiter zu analysieren.
  • Wenn die getestete Methode mehr als eine externe Abhängigkeit verwendet, können Sie nicht überprüfen, welche Methode die Ausnahme ausgelöst hat, da die Ausführung Ihrer Testmethode gestoppt wird, wenn die Ausnahme ausgelöst wird.

Die Catch-Exception-Bibliothek löst diese beiden Probleme. Ich habe sofort angefangen, es zu verwenden, und ich empfehle, dass Sie dasselbe tun. Es ist eine nützliche Ergänzung für die Toolbox jedes Entwicklers.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.


Java-Tag