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

Was ich in Woche 36 gelernt habe

Zuerst , Ein Product Owner kann ohne Entscheidungsbefugnis nicht funktionieren. Wikipedia definiert den Product Owner wie folgt:

Der Product Owner repräsentiert die Stakeholder und ist die Stimme des Kunden. Er oder sie ist dafür verantwortlich, dass das Team einen Mehrwert für das Unternehmen liefert.

Wenn Sie eine Frage zum Produkt haben, an wen wenden Sie sich? Exakt. Sie sprechen mit dem Product Owner und erwarten von ihm eine Antwort auf Ihre Frage. Wenn Entscheidungen zu treffen sind, erwarten Sie, dass er sie trifft. Richtig?

Wenn der Product Owner seine Entscheidungen von jemand anderem bestätigen muss, warum sollten Sie dann mit ihm sprechen?

Wenn seine Entscheidungen später widerrufen werden, warum sollten Sie seinen Entscheidungen vertrauen?

Das Problem eines Product Owners ohne Autorität besteht darin, dass das Team sich nicht auf den Product Owner verlassen kann Entscheidungen treffen. Um die Sache noch schlimmer zu machen, das Team kann seinen Entscheidungen nicht vertrauen .

Glauben Sie, dass dies langfristig funktionieren könnte? Ich nicht.

Zweite , Das Erlernen einer neuen Art, Dinge zu tun, bedeutet nicht, dass Sie sie in jeder Situation anwenden sollten. Vor ein paar Wochen stieß ich auf ein Muster namens Test Data Builder. Die Idee dieses Musters ist

1. Verstecken Sie die Konstruktionslogik neuer Objekte hinter der API der Testdaten-Builder-Klasse.
2. Erstellen Sie eine DSL, die den Geschäftswert der in unseren Tests erstellten Objekte kommuniziert.

Da dies ein wirklich cooles Konzept ist und es einen enormen positiven Einfluss auf die Lesbarkeit meiner Tests hat, war ich WIRKLICH BEGEISTERT darüber und fing an, es überall zu verwenden. Ich habe Test Data Builder für jedes Objekt erstellt, das ich in meinen Tests verwendet habe.

Wenn das Konzept so cool ist, warum sollte ich es nicht verwenden?

Es hat ein paar Wochen gedauert, bis ich bemerkte, dass es Situationen gibt, in denen die Verwendung von Test Data Buildern zu Overengineering führt. Ich hatte vergessen, dass das grundlegendste Ziel dieses Konzepts darin besteht, die Dinge einfacher zu machen.

Mir wurde klar, dass ich, als ich damit beschäftigt war, all diese Test-Data-Builder zu schreiben, auf Autopilot programmierte. Ich erinnere mich an einige Situationen, in denen ich das Gefühl hatte, dass die Erstellung eines Testdatengenerators die Dinge nicht einfacher macht. Ich ignorierte dieses Gefühl. Es war ein Fehler .

Es spielt keine Rolle, wie cool dieses neue Muster/Technik/Programmiersprache ist. Wann der Einsatz sinnvoll ist, müssen Sie selbst entscheiden.

Machen Sie nicht den gleichen Fehler wie ich und ignorieren Sie Ihr Bauchgefühl. Hören Sie es sich an .

Dritter , SQL ist wieder in Mode. Ich stieß auf eine Bibliothek namens jOOQ. Auf der Website der Bibliothek heißt es dazu

JOOQ ist eine fließende API für die Erstellung und Ausführung von typsicheren SQL-Abfragen

Die API sieht sehr gut aus und macht Spaß. Wenn Sie SQL in Ihrem Java-Projekt verwenden möchten, sollten Sie sich unbedingt einen Gefallen tun und einen Blick auf jOOQ werfen.

Allerdings kann jOOQ die traditionellen ORM-Tools nicht in jeder Anwendung ersetzen. Was es tun kann, ist, eine andere Möglichkeit zum Implementieren von Datenzugriffsschichten anzubieten.

Herkömmliche ORM-Tools konzentrieren sich auf das Domänenmodell der Anwendung und sehen die relationale Datenbank als notwendiges Übel. Dieser Ansatz funktioniert sehr gut bei domänengesteuerten Anwendungen .

jOOQ dreht das um. Es konzentriert sich auf das relationale Datenmodell und umfasst SQL. Es gibt Situationen, in denen die Verwendung eines solchen Tools absolut sinnvoll ist.

Nehmen wir zum Beispiel an, dass Sie komplexe Berichte aus Daten erstellen müssen, die in einer relationalen Datenbank gespeichert sind, und zwar mit Java.

Das Problem herkömmlicher ORM-Tools besteht darin, dass die Optimierung komplexer Abfragen nicht gerade ein Kinderspiel ist. Aus diesem Grund sind diese Tools für diese Situation nicht geeignet.

Wie wäre es mit jOOQ? Es scheint eine interessante Option zu sein, aber da ich es selbst nicht benutzt habe, ist es schwer, es sicher zu wissen. Es wäre jedoch interessant, es herauszufinden.

Vierter , Das grundlegendste Ziel einer Schnellstart-Projektvorlage besteht darin, Ihnen dabei zu helfen, so schnell wie möglich loszulegen . Wenn es einfacher ist, ein neues Projekt von Grund auf neu zu erstellen, als eine Schnellstart-Projektvorlage zu verwenden, hat die Vorlage überhaupt keinen Wert.

Das scheint offensichtlich, aber das Problem von „Enterprise-Entwicklern“ ist, dass wir dazu neigen, alles zu überkonstruieren . Dazu gehören auch Projektvorlagen. Wenn wir endlich mit dem Ergebnis zufrieden sind, kann die Vorlage so komplex sein, dass es unmöglich ist, zu verstehen, was sie tut, ohne viel Zeit damit zu verbringen, sie herauszufinden.

Eine Projektvorlage wie diese kann ein hervorragender Beweis für die Ingenieurskunst der Personen sein, die sie erstellt haben. Das ist oft eine bewundernswerte Leistung.

Trotzdem ist die traurige Tatsache, dass es mir nichts wert ist, wenn es mein Leben nicht einfacher macht .

Wenn Sie Schnellstartvorlagen erstellen, sollten Sie diese drei Regeln befolgen:

1. Machen Sie die Dinge einfacher. Nicht schwerer.
2. Stellen Sie sicher, dass es möglich ist, auf neuere Versionen von Bibliotheken und Frameworks zu aktualisieren, ohne alles zu beschädigen.
3. Wenn Ihre Projektvorlage ein Benutzerhandbuch erfordert, ist es zu kompliziert.

Fünfter , Das Sammeln von Daten ist nicht genug, wenn wir sie nicht verwenden. Ich begann Buyology von Martin Lindstrom zu lesen und fand den folgenden Satz im Vorwort:

Das Problem ist, dass wir beim Sammeln von Daten immer besser werden, als irgendetwas damit zu tun.

Das Lesen dieses Satzes hatte eine phänomenale Wirkung auf mich. Ich mag Statistiken. Ich habe eine natürliche Tendenz, viele Daten zu sammeln, die ich später brauchen könnte. Das Problem ist, dass ich nur einen kleinen Teil der Daten verwende die ich sammle.

Das Gute daran ist, dass ich die Daten noch habe. Alles, was ich tun muss, ist, es zu benutzen.

Ich weiß, was mit Code-Coverage-Daten zu tun ist, und ich verwende sie regelmäßig. Meine Schwäche ist, dass ich zwar gerne Daten über die Nutzer meiner Anwendung sammle, aber keine Ahnung habe, was ich damit anfangen soll.

Ich weiß, dass diese Daten wertvoll sind, aber ich muss herausfinden, wie ich sie nutzen kann. Irgendwelche Ideen?

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.