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

Java

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.

Zweite , 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 48 gelernt habe.

Was ich in Woche 48 gelernt habe

Zuerst , Auch klein kann schön sein.

Ich bin der Frühlingstyp. Das sollte niemanden überraschen. Das bedeutet jedoch nicht, dass ich alternative Methoden zum Schreiben von Software mit Java für schlecht halten würde. Ich mag einfach Spring Framework.

Diese Woche habe ich einen Blogbeitrag mit dem Titel Humble Architects von Johannes Brodwall gelesen, und er hat mich zum Nachdenken über Komplexität gebracht. Dieser Blogpost macht mehrere gute Punkte, aber dieser Abschnitt ist mir aufgefallen:

Jede Technologie ist mit Kosten verbunden. Viele Technologien bieten einen verschwindend geringen Nutzen.

Hier ist eine Liste von Technologien, die meiner Erfahrung nach immer höhere Kosten als Nutzen haben und daher niemals verwendet werden (wenn Sie sie nicht kennen, machen Sie sich keine Sorgen. Der Punkt ist die Zahl):JavaServer Pages, Java Server Faces , JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS (alle Implementierungen), JBoss.

Hier ist eine Liste von Technologien, die ich gerne verwende:JUnit, Jetty, Joda-time, Java Standard Edition.

Als ich diesen Abschnitt zum ersten Mal sah, fragte ich mich, wie er produktiv sein könnte, ohne ein Framework zu verwenden. Dann erinnerte ich mich, dass ich, als ich anfing, Software mit der Programmiersprache Java zu schreiben, dasselbe tun musste, weil es keine Frameworks gab.

Also habe ich Webanwendungen geschrieben, indem ich Servlets geschrieben habe, und ich war produktiv. Eine Sache, an die ich mich aus dieser Zeit erinnere, war, dass wir aufhörten, unsere eigenen "Bibliotheken" zu schreiben, was uns half, weniger ausführlichen Code zu schreiben. Typischerweise befassten sich diese Bibliotheken mit Anforderungsparametern, verwalteten Abhängigkeiten und so weiter. Mit anderen Worten, wir haben unsere eigenen Frameworks geschrieben .

Das Problem war, dass viele dieser Frameworks plump und unelegant waren. Dies mag an unserer mangelnden Erfahrung liegen, aber dieses Gefühl war einer der Hauptgründe, warum ich mich sehr gefreut habe, als die ersten Web-Frameworks veröffentlicht wurden.

Umso glücklicher war ich, als die ersten Dependency-Injection-Container veröffentlicht wurden, weil sie mich davon befreiten, mich mit den Abhängigkeiten meiner Anwendung auseinanderzusetzen. Endlich konnte ich die Fabriken loswerden, die meine Komponenten herstellten. Es fühlte sich an wie ein riesiger Sprung nach vorne.

Diese Woche habe ich gelernt, dass klein auch schön sein kann. Wenn die Verwendung eines Frameworks für uns sinnvoll ist, sollten wir es verwenden. Wir sollten uns jedoch daran erinnern, dass wir uns oft dafür entscheiden, für jedes Problem, mit dem wir konfrontiert sind, einen vertrauten Rahmen zu verwenden. Das nächste Mal, wenn wir diese Entscheidung treffen müssen, sollten wir uns diese Frage stellen:

Brauche ich das alles wirklich?

Werden Sie diese Frage stellen? Ich weiß, dass ich es tun werde.

Zweite , Unveränderlichkeit anstreben.

Diese Woche stieß ich auf die Folien der Präsentation (Immutable Java), die Tero Parviainen auf dem Java Day Riga 2013 hielt.

Als ich die Dias durchblätterte, wurde ich ärgerlich. Ich war aus einem einfachen Grund verärgert:

Ich fühlte mich schuldig weil ich wusste, dass ich besser dafür sorgen könnte, dass meine Klassen unveränderlich sind.

Nachdem ich das erkannt hatte, wusste ich, dass ich etwas dagegen tun muss. Obwohl ich bezweifle, dass es unmöglich/unpraktisch ist, alle Objekte unveränderlich zu machen (hauptsächlich wegen Hibernate), habe ich mich entschieden, diese Regeln zu befolgen:

Verwenden Sie unveränderliche Typen für Daten (eigentlich mache ich das bereits, weil ich Joda-Time verwende).
Feld als endgültig deklarieren, wenn sein Wert nicht mehr geändert werden kann, nachdem es zum ersten Mal gesetzt wurde.
Stellen Sie sicher, dass die Informationen von Entitäten nicht außerhalb der Entitätsklasse geändert werden können.
Machen Sie Ihre Wertobjekte unveränderlich.
Alle schreibgeschützten Klassen unveränderlich machen. Dazu gehören DTOs.

Dies scheint ein ziemlich umfassendes Regelwerk zu sein, und ich bin zuversichtlich, dass ich meinen Code verbessern kann, wenn ich diese Regeln befolge. Was denkst du?

Dritter , Verwenden Sie benutzerdefinierte Typen anstelle von Basistypen (aber übertreiben Sie es nicht).

Ich habe viel Zeit damit verbracht, über benutzerdefinierte Typen nachzudenken, und es war wirklich sehr schwer, eine Antwort auf diese Frage zu finden:

Wann kann ich die Komplexität der Verwendung eines benutzerdefinierten Typs anstelle eines Basistyps rechtfertigen?

Ich weiß, dass die Verwendung eines benutzerdefinierten Typs meinem Code eine semantische Bedeutung hinzufügt. Dies ist etwas, das ich nicht erreichen kann, wenn ich nur einfache Typen wie Strings verwende. Die meisten dieser benutzerdefinierten Typen wären jedoch nur dünne Wrapper-Klassen, und ihre Verwendung scheint meinen Code zusätzlich zu komplizieren.

Es gibt jedoch eine Ausnahme:

Wenn ich mehr als eine Eigenschaft gruppieren möchte, ist es klar, dass ich einen benutzerdefinierten Typ verwenden sollte. Z.B. Es macht keinen Sinn, streetAddress hinzuzufügen , Stadt und zipCode Felder in jede Klasse, die eine Adresse hat. Stattdessen erstelle ich eine Adresse Klasse, die streetAddress hat , Stadt und zipCode Felder und fügen Sie es jeder Klasse hinzu, die eine Adresse hat.

Was soll ich dann mit einzelnen Feldern machen?

Diese Woche habe ich einen Blog-Beitrag mit dem Titel Never, never, never use String in Java gelesen (oder zumindest seltener :-), und ich glaube, ich habe eine Antwort auf diese Frage gefunden.

Wenn ein Wert eine semantische Bedeutung hat, die für die domänenspezifische Sprache der Anwendung wichtig ist, und (oder) Sie sicherstellen möchten, dass nur gültige Eingaben akzeptiert werden, sollten Sie die Verwendung eines benutzerdefinierten Typs in Erwägung ziehen.

Ich bin mit dieser Regel nicht ganz glücklich, aber es ist ein guter Anfang. Was denkst du darüber?

Vierter , Benennen Sie "Dinge" in domänenspezifischer Sprache.

Ich denke (hoffe), dass jeder Entwickler versteht, dass es wichtig ist, Methoden, Variablen und Klassen beschreibende Namen zu geben, weil es den Code lesbar macht. Ich denke auch so.

Und doch vergesse ich es manchmal.

Diese Woche bin ich auf die folgende Controller-Methode gestoßen, die von Ihnen geschrieben wurde:
[cc lang="java" tabSize="2" height="*" width="*"]public String submitRegistrationForm(RegistrationDTO dto ) {
//Implementierung hier hinzufügen.
}
[/cc]Diese Methode hat drei folgende Probleme:

Obwohl es aufgerufen wird, wenn das Registrierungsformular gesendet wird, beschreibt sein Name nicht, was passiert, wenn es aufgerufen wird.
Der Name der Formularobjektklasse ist nicht sehr gut. Es ist klar, dass es sich um ein Datenübertragungsobjekt handelt, und dennoch habe ich mich dafür entschieden, das Suffix DTO hinzuzufügen zu seinem Namen. Dies hilft uns nicht zu verstehen, welche Art von Informationen darin enthalten sind.
Der Name des Methodenparameters beschreibt nicht seinen Zweck.

Ich glaube, dass wir Dinge benennen sollten, indem wir eine domänenspezifische Sprache verwenden. In diesem Fall bedeutet dies, dass wir Begriffe verwenden sollten, die sich auf einen Registrierungsprozess beziehen. Wenn wir dieser Regel folgen, landen wir bei der folgenden Methode:

[cc lang="java" tabSize="2" height="*" width="*"]public String registerNewUserAccount(RegistrationForm newUserAccount) {
//Implementierung hier hinzufügen.
}
[/cc]Die zweite Methode sieht viel besser aus und behebt alle Probleme, die bei der ursprünglichen Methode gefunden wurden. Das mag wie Erbsenzählerei erscheinen, aber Dinge wie diese machen eine große Codebasis viel verständlicher.

Das Beste daran ist, dass es nicht viel Arbeit erfordert, da alle modernen IDEs über großartige Refactoring-Fähigkeiten verfügen.

BENUTZE SIE!

Fünfter , Ärger kann ein mächtiger Verbündeter sein, wenn Sie wissen, wie man damit umgeht.

Wenn Sie sich ärgern, wenn Sie einen technischen Blogbeitrag lesen oder sich eine Präsentation ansehen, haben Sie zwei Möglichkeiten, damit umzugehen:

Sie können den Blogbeitrag oder die Präsentation ignorieren und denken, dass diese Person ein Idiot ist, der nicht weiß, wovon er spricht. Du könntest sogar eine witzige Bemerkung machen und versuchen, dieser Person zu signalisieren, dass du besser bist als sie.
Sie können herausfinden, warum Sie sich ärgern, und versuchen, etwas daraus zu lernen.

Es ist ziemlich einfach, die erste (und sehr unproduktive) Option zu wählen. Wenn Sie sich jedoch die Zeit nehmen, Ihre Gefühle zu erforschen, werden Sie vielleicht feststellen, dass der Grund, warum Sie sich ärgern, nicht darin besteht, dass diese Person ein Idiot ist.

Es könnte etwas viel Persönlicheres sein .

Sind Sie sicher, dass Sie sich nicht ärgern, weil Sie wissen, dass diese Person einen berechtigten Standpunkt einnimmt?

Bist du sicher, dass dir seine Aussage nicht gefällt, weil sie dich aus deiner Komfortzone zwingt?

Ich habe festgestellt, dass ich jedes Mal, wenn ich mich geärgert habe, etwas daraus gelernt habe. Es ist ein wunderbares Gefühl!

Sind Sie sicher, dass Sie sich nicht auch so fühlen möchten?

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.