Java >> Java Tutorial >  >> Java

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

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 41 gelernt habe.

Was ich in Woche 41 gelernt habe

Zuerst , Hibernate Validator hat ein @SafeHtml Validator, mit dem sichergestellt werden kann, dass der angegebene Text keinen bösartigen Code enthält. Dies ist eine praktische Möglichkeit, Ihre Anwendung vor XSS-Angriffen zu schützen, wenn Sie den bösartigen Code nicht stillschweigend aus dem Text entfernen möchten.

Zweite , Einschränkungen des Domänenmodells müssen den Einschränkungen entsprechen, die in der Datenbank gefunden wurden.

Ich denke, dass dies aus zwei Gründen wichtig ist:

  1. Diese Einschränkungen dienen als Dokumentation. Wenn die Einschränkungen gleich sind, müssen die Entwickler nicht alles aus der Datenbank überprüfen. Dies ist eine enorme Zeitersparnis.
  2. Integrationstests werden häufig gegen eine von Hibernate erstellte Datenbank ausgeführt. Wenn die Einschränkungen nicht gleich sind, ist die von Integrationstests verwendete Datenbank nicht gleich der Produktionsdatenbank. Dies kann zu Fehlalarmen führen, die zu einem Problem werden können, wenn die Anwendung in der Produktionsumgebung bereitgestellt wird.

Außerdem füge ich oft andere nicht obligatorische JPA-Annotationen hinzu (hauptsächlich @Table und @Spalte ) auch, weil ich auf diese Weise die Namen von Datenbanktabellen und -spalten bestimmen kann.

Dritter , Alle Jira-Probleme müssen aktivierende Spezifikationen sein.

Ich habe letzte Woche geschrieben, dass ein Issue Tracker als Spezifikationstool verwendet werden kann. Diese Woche habe ich gemerkt, dass das nicht gut genug ist.

Lassen Sie mich erklären.

Eine Spezifikation wird oft als etwas verstanden, das erforderlich ist, wenn wir unserer Anwendung neue Funktionen hinzufügen oder die Implementierung einer vorhandenen Funktion ändern möchten. Obwohl es verständlich ist, warum Menschen so denken, hat ein Softwareprojekt viele Aufgaben, die das Verhalten der Anwendung nicht ändern.

Wie sollen wir diese Aufgaben beschreiben?

Wir sollten diese Tasks genauso behandeln wie die Tasks, die das Verhalten unserer Anwendung ändern. Wir sollten alle erforderlichen Informationen zur Beschreibung des Tickets hinzufügen.

Woher wissen wir, welche Informationen erforderlich sind?

Es ist schwierig, hierzu eine allgemeine Richtlinie zu geben, da alles von den Fähigkeiten und Erfahrungen unserer Teammitglieder abhängt. Aus diesem Grund schlage ich vor, dass wir zunächst alle Informationen hinzufügen, die uns relevant erscheinen, und unsere Tickets verbessern, indem wir Feedback von unseren Teammitgliedern einholen.

Dies wird einige Zeit dauern, aber irgendwann werden wir wissen, welche Informationen relevant sind und welche nicht.

Warum sollte uns das interessieren?

Diese Woche habe ich mit der Arbeit an einer mir unbekannten Anwendung begonnen. Alles, was ich hatte, war eine vage Vorstellung von der allgemeinen Idee der Anwendung.

Diese Erfahrung hat mich gelehrt, wie wichtig es ist, Spezifikationen zu ermöglichen. Da ich keine Ahnung von den Geschäftsregeln der Anwendung oder ihrer Architektur hatte, musste ich Stunden damit verbringen, die Informationen zu finden, die nicht im Ticket gefunden wurden. Das war eine ziemlich frustrierende Erfahrung.

Ich stimme zu, dass das Schreiben von Freigabespezifikationen einige Zeit in Anspruch nehmen wird. Trotzdem denke ich, dass es besser ist, eine Viertelstunde oder eine halbe Stunde damit zu verbringen, ein gutes Issue-Tracker-Ticket zu schreiben, weil es dem Entwickler Stunden der Frustration ersparen kann.

Das klingt für mich wie ein Kinderspiel.

Auch wenn Sie Produktivitätsprobleme haben, ist das Schreiben von Leistungsspezifikationen eine einfache Möglichkeit, die Produktivität Ihres Teams zu steigern.

Vierter , JPA-Vererbung mit InheritanceType.TABLE_PER_CLASS verwenden kann zu einer ziemlich beschissenen Datenbank führen.

Stellen wir uns folgendes Szenario vor:

  1. Wir verwenden JPA-Vererbung mit dem InheritanceType.TABLE_PER_CLASS . Das bedeutet, dass wir für jede konkrete Entitätsklasse eine Datenbanktabelle anlegen müssen.
  2. Der Name der Oberklasse ist AbstractFoo .
  3. Der AbstractFoo Klasse hat zwei Unterklassen, die FooOne genannt werden und FooTwo . Die Informationen dieser Entitäten werden in den Datenbanktabellen namens foo_ones gespeichert und foo_twos .

Unsere Klassenhierarchie ist fertig. Der nächste Schritt besteht darin, ein AbstractFoo hinzuzufügen -Feld zu einer Entität und geben Sie die verwendete Join-Spalte an:

@OneToOne
@JoinColumn(name = "foo_id")
private AbstractFoo foo;

Zu welcher Tabelle gehört die foo_id Spaltenverweis?

Nun, es verweist entweder auf die Tabelle foo_ones oder zum Tisch foo_twos . Das ist verdammt gruselig .

Können Sie diese Frage beantworten:

Wie erstellen Sie eine Fremdschlüsseleinschränkung für die Spalte foo_id?

Hab Angst. Hab große Angst.

Fünfter , Scheitern ist ein guter Lehrer.

Obwohl einige Leute denken, dass es überbewertet wird, aus Fehlern zu lernen, glaube ich immer noch, dass Scheitern ein guter Lehrer ist. Natürlich hat das Lernen aus Ihren Fehlern seine Grenzen, aber Sie können immer noch mehr lernen, als Sie denken.

Verschwende deine Fehler nicht, indem du denkst:

"Ich weiß jetzt, dass es keine gute Idee ist, X zu verwenden. Ich werde es beim nächsten Mal mit Y versuchen."

Denken Sie an dieses Zitat von Jason Fried von 37Signals:

"Was hast du gelernt? Du hast gelernt, was nicht funktioniert hat. Jetzt machst du nicht zweimal denselben Fehler, aber beim nächsten Mal machst du genauso wahrscheinlich einen anderen Fehler. Du weißt vielleicht, was nicht funktionieren wird, aber Sie wissen immer noch nicht, was funktionieren wird. Das ist keine große Lektion."

Ich stimme zu. Der richtige Weg, um aus Ihren Fehlern zu lernen, besteht darin, herauszufinden, wie Sie den Fehler von vornherein hätten vermeiden können. Mit anderen Worten:

Du musst herausfinden, was funktioniert!

Ich stimme zu, dass Sie sich darauf konzentrieren sollten, aus Ihren Erfolgen zu lernen, weil sie Ihnen beibringen, was funktioniert. Wenn Sie jedoch Fehler machen (und glauben Sie mir, das werden Sie), können Sie immer noch lernen, was funktioniert, solange Sie mit Ihren Fehlern richtig umgehen.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.

PS . Ich habe versprochen, ein Buch mit dem Titel Scaling Big Data with Hadoop and Solr zu rezensieren. Ich habe noch nicht angefangen, es zu lesen, aber seine Beschreibung sieht ziemlich interessant aus. Ich denke, dass ich nächste Woche anfangen werde es zu lesen.


Java-Tag