Читать книгу Spring Boot - Mark Heckler - Страница 11

Die Autokonfiguration, die Spring-Boot-Neulingen manchmal wie Zauberei erscheinen mag, ist vielleicht der größte »Machtmultiplikator«, den Entwickler durch Spring Boot gewinnen. Ich bezeichne sie oft als die Superkraft eines Entwicklers: Spring Boot gibt Ihnen wahnsinnige Produktivität, indem es Meinungen zu weit verbreiteten und oft wiederholten Use Cases äußert.

Meinungen in Software? Und das hilft?!?

Wenn Sie schon lange als Entwickler unterwegs sind, dann haben Sie zweifellos bemerkt, dass sich manche Muster oft wiederholen. Natürlich nicht perfekt, aber zu einem großen Teil; vielleicht 80 bis 90 Prozent der Zeit bewegen sich die Dinge in einem bestimmten Bereich aus Design, Entwicklung oder Aktivität.

Ich habe bereits auf diese Wiederholung in der Software hingedeutet, da sie es ist, die Spring-Boot-Starter so unglaublich konsistent und nützlich macht. Wiederholung bedeutet auch, dass sich diese Aktivitäten, wenn wir dann zu dem Code kommen, der zum Erledigen einer bestimmten Aufgabe geschrieben werden muss, hervorragend für eine Rationalisierung anbieten.

Um einmal ein Beispiel aus Spring Data zu borgen, ein mit Spring Boot verwandtes und durch Spring Boot ermöglichtes Projekt: Wir wissen, dass wir jedes Mal, wenn wir Zugriff auf eine Datenbank benötigen, irgendeine Art von Verbindung zu dieser Datenbank öffnen müssen. Wir wissen außerdem, dass diese Verbindung geschlossen werden muss, wenn unsere Anwendung ihre Aufgaben erledigt hat, um potenzielle Probleme zu vermeiden. Zwischen dem Öffnen und Schließen richten wir wahrscheinlich zahlreiche Anforderungen an die Datenbank, für die wir Abfragen benutzen – einfache und komplexe, schreibgeschützte und schreibbare. Die korrekte Erstellung dieser Abfragen erfordert eine gewisse Mühe.

Stellen Sie sich nun vor, wir könnten all das rationalisieren. Automatisch eine Verbindung öffnen, wenn wir die Datenbank angeben. Automatisch die Verbindung schließen, wenn die Anwendung fertig ist. Einfachen und erwarteten Konventionen folgen, um mit minimalem Aufwand Ihrerseits automatisch Abfragen zu erzeugen. Wieder durch eine einfache Konvention eine einfache Anpassung selbst dieses minimalen Codes erlauben, um komplexe, spezialisierte Abfragen zu erzeugen, die zuverlässig konsistent und effizient sind.

Diese Herangehensweise an Code wird manchmal als Konvention vor Konfiguration bezeichnet und kann auf den ersten Blick irritierend wirken, wenn eine bestimmte Konvention Ihnen neu ist. Falls Sie jedoch vorher schon einmal Ähnliches implementiert haben und viele Hundert Zeilen lang den immer wieder gleichen Setup/Teardown/Konfigurationscode schreiben mussten, um selbst die einfachen Aufgaben zu erledigen, dürfte dies sehr erfrischend sein. Spring Boot (und die meisten Spring-Projekte) folgen dem Mantra Konvention vor Konfiguration und bieten Ihnen damit die Versicherung, dass Sie nur ein Minimum an Konfigurationscode (oder überhaupt keinen) schreiben müssen, wenn Sie sich an einfache, wohletablierte und -dokumentierte Konventionen halten.

Ein anderer Aspekt, über den die Autokonfiguration Ihnen Superkräfte verleiht, ist die Tatsache, dass für das Spring-Team die Entwickler an erster Stelle stehen, vor allem auch, wenn es um die Konfiguration der Umgebung geht. Als Entwickler sind wir am produktivsten, wenn wir uns auf die zu lösende Aufgabe konzentrieren können und uns nicht mit einer Unmenge von Setup-Kleinigkeiten befassen müssen. Wie schafft Spring Boot das?

Borgen wir uns ein Beispiel aus einem anderen Spring-Boot-verwandten Projekt, Spring Cloud Stream: Wenn eine Verbindung zu einer Messaging-Plattform wie RabbitMQ oder Apache Kafka hergestellt werden soll, muss ein Entwickler typischerweise zuerst bestimmte Einstellungen für die genannte Plattform festlegen, um sich mit ihr verbinden und sie nutzen zu können – Hostname, Port, Zugangsdaten und mehr. Die Konzentration auf das eigentliche Entwickeln bedeutet, dass Standardwerte angegeben werden, die das lokale Arbeiten des Entwicklers unterstützen, falls keine festgelegt wurden: Localhost, Standardport und so weiter. Das ist quasi eine Meinung, weil es für Entwicklungsumgebungen fast zu 100 Prozent konsistent ist, wenn es auch in Produktionsumgebungen nicht der Fall ist. In diesen müssten Sie aufgrund der vielen unterschiedlichen Plattformen und Hosting-Umgebungen spezielle Werte angeben.

Nutzt man diese Standardwerte in geteilten Entwicklungsprojekten, spart man ebenfalls viel Zeit beim Setup für die Entwicklungsumgebung. Das ist ein Vorteil für Sie und für Ihr Team.

Es gibt natürlich Gelegenheiten, bei denen Ihre speziellen Anwendungsfälle nicht exakt zu den 80 bis 90 Prozent der typischen Anwendungsfälle passen. Sollte Ihr Fall in die Kategorie der restlichen 10 bis 20 Prozent Anwendungsfälle gehören, kann die Autokonfiguration selektiv außer Kraft gesetzt oder ganz deaktiviert werden. Sie verlieren dann aber natürlich Ihre Superkräfte. Das Übergehen bestimmter Meinungen ist üblicherweise eine Angelegenheit, bei der eine oder mehrere Eigenschaften gesetzt werden, um etwas zu erreichen, was Spring Boot normalerweise automatisch für Sie konfigurieren würde. Meist ist das relativ einfach, selbst wenn es selten vorkommt. Die Autokonfiguration ist ein machtvolles Werkzeug, das stillschweigend und pausenlos in Ihrem Sinne tätig ist, um Ihnen das Leben zu erleichtern und Sie unglaublich produktiv zu machen.