Das volle Java-Leben: Was macht ein Software-Architekt wirklich den ganzen Tag?

Softwarearchitekten haben es einfach, oder so viele Programmierer und Ingenieure glauben. In diesem vollständigen Java-Lebensinterview erfahren Sie, wie das tägliche Arbeitsleben eines Architekten wirklich aussieht . Der Java-Programmiertier Bruce Brouwer erläutert seinen Ansatz zur Aktualisierung älterer Java-Webanwendungen auf eine serviceorientierte Front-End-Architektur, sein sich schnell entwickelndes Web-UI-Toolkit und warum er es im Allgemeinen vorzieht, mit Javas Einschränkungen zu arbeiten, anstatt sich für eine weniger strenge JVM-Sprache zu entscheiden.

Wie viele Softwareentwickler war ich Architekten gegenüber immer skeptisch. Zu oft scheinen sie Anforderungen zu stellen, wie die Arbeit des Codierens erledigt werden soll, ohne mit den Konsequenzen leben zu müssen. Ich bin der Typ, der einmal einen Artikel mit dem Titel "Warum ich kein Architekt bin" geschrieben hat, und es ist bekannt, dass ich "Seine Lieblings-IDE ist MS Outlook" witzele.

Dann traf ich Bruce Brouwer, einen Anwendungsarchitekten bei Gordon Food Service (GFS), einem in Familienbesitz befindlichen Lebensmittelhändler mit Büros in Michigan. Als ich Bruce traf, war er tief in seinem Computerbildschirm und sah sich den tatsächlichen Code an. Seine Aufgabe war es, den Ruby-basierten Compass-Compiler von GFS in eine Anwendungserstellung mit JRuby zu integrieren, und seine Herangehensweise an die Arbeit schien alles andere als abstrakt. Ich war fasziniert.

Bruce 'Aufgabe bei GFS sei es, sowohl die Vision für zukünftige Webanwendungen festzulegen als auch seine Vision mit Proof-of-Concept-Anwendungen zu demonstrieren. Er arbeitet normalerweise mit Entwicklungsteams an den ersten Implementierungen eines Roll-outs. Das neueste Thema, an dem Bruce an dem Tag, an dem wir uns trafen, arbeitete, war, wie GFS an herkömmlichen Anforderungs- / Antwort-Webanwendungen vorbei in eine serviceorientierte Front-End-Architektur (SOFEA) verschoben werden kann, in der die gesamte Präsentationslogik im Browser verwaltet wird eher als auf dem Server.

Bruce teilte einige seiner Ideen, um über klassische serviceorientierte Architekturen (SOA) hinaus zu mehr nachrichtenbasierten Paradigmen zu gelangen. Diese Ideen müssen auf dem Papier funktionieren, aber Bruce muss sich von den technischen Teams einkaufen lassen, damit sie funktionieren. Als Architekt bietet er Implementierungsanleitungen für Teams, Technologien und sogar Legacy-Systeme. Seine Perspektive ist faszinierend und ich dachte, sie sollte geteilt werden.

Matt Heusser : Sprechen Sie mit mir über Ihre Karriere als Programmierer und Architekt. Wie hat sich Ihre Rolle im Laufe der Zeit verändert? Wie sind Sie heute zu Ihrer Rolle als Junior-Programmierer im Vergleich zu einem Programmierer in der Mitte der Karriere oder als Architekt gekommen?

Bruce Brouwer : Nach dem College bin ich in meinen ersten richtigen Job gezogen. Fast von Anfang an habe ich die Grenzen überschritten. Es gab diesen langwierigen Prozess des Aktualisierens der Datenzugriffsschicht dieser Anwendung. Alle neuen Mitarbeiter waren dem Schmerz ausgesetzt, diesen Prozess durchzuführen. Nach meinem ersten Mal habe ich beschlossen, es zu automatisieren. Das Management war beeindruckt und bat mich, es für alle Tabellen in der Datenbank auszuführen. Es dauerte ungefähr eine Woche, um das Chaos von meiner Automatisierung zu beseitigen, was sich als fehlerhafter Prozess herausstellte.

Im Laufe meiner Karriere fand ich viel mehr Möglichkeiten, die Entwicklung zu vereinfachen. Ein Satz wurde schnell mit mir assoziiert: "Eine Codezeile." Ich habe meine Arbeit weiter vorangetrieben, um es den Entwicklern einfacher zu machen. Ich war mit meiner Arbeit nicht wirklich zufrieden, bis Sie etwas tun konnten, das vorher kompliziert war, aber jetzt so einfach wie eine Codezeile war.

Aber Sie können nur so weit gehen, indem Sie bessere Werkzeuge herstellen. Ich musste anfangen, in größerem Maßstab zu denken. Wenn Sie anfangen, in dieser größeren Welt zu spielen, müssen Sie erneut die Grenzen überschreiten. Möglicherweise ist eine SQL-Datenbank nicht erforderlich. Vielleicht ist das Warten auf eine Antwort von diesem Dienst nicht die beste Zeitnutzung. Vielleicht schneidet Java es nicht mehr.

Okay, dieser letzte Punkt ist ein bisschen umstritten, aber es ist eine Frage, die ich gestellt habe. Aber diese Fragen einfach zu stellen, ist nicht die eigentliche Aufgabe eines Architekten. Selbst das Entwerfen einer absolut brillanten Architektur reicht nicht aus. Sie müssen in der Lage sein, anderen Schritt für Schritt zu zeigen, wie sie dorthin gelangen. Ein Architekt muss in der realen Welt verankert sein und die Probleme erleben, die sich aus dem ergeben, was er entworfen hat. Dies erfordert sowohl technische als auch soziale Anstrengungen.

Matt Heusser : Mit welchen Technologien arbeiten Sie gerade?

Bruce Brouwer : Vor nicht allzu langer Zeit habe ich beschlossen, mein LinkedIn-Profil auszufüllen und alle Technologien aufzulisten, die ich tatsächlich verwende. Während dieser Bemühungen habe ich erfahren, dass LinkedIn ein Limit hat. Ich sage das nicht, um zu prahlen, ich denke, das ist ein Problem. Es gibt einfach zu viele Dinge, die Sie wissen müssen, um in der heutigen Welt ein guter Entwickler zu sein. Wir müssen die Liste der Werkzeuge, mit denen wir unsere Arbeit erledigen, besser einschränken.

Ich benutze hauptsächlich Java und Spring. Ich habe kürzlich daran gearbeitet, die Zukunft der Entwicklung von Webanwendungen bei GFS zu gestalten. GFS hat Webanwendungen mit Java EE entwickelt, seit es Frameworks wie Struts oder JSF gab. Jetzt gibt es einige neue Ideen, die diese serverseitigen Web-Frameworks herausfordern, wie SOFEA und Responsive Design. Ja, wir könnten diese Ideen in die aktuelle Struts 2-Infrastruktur einbinden, aber es ist Zeit, eine echte Pause zwischen der Benutzeroberfläche und dem Back-End einzulegen. Auf diese Weise sind wir besser positioniert, um auf das Tempo der Änderungen in der Web-UI-Schicht zu reagieren, ohne solch drastische Änderungen in der Service-Schicht vornehmen zu müssen.

"Jetzt gibt es einige neue Ideen, die serverseitige Web-Frameworks herausfordern, wie SOFEA und Responsive Design. Ja, wir könnten diese Ideen in die aktuelle Struts 2-Infrastruktur integrieren, aber es ist Zeit, eine echte Pause zwischen der Benutzeroberfläche und der Rückseite einzulegen Ende."

Für diese neue Web-Benutzeroberfläche habe ich fast eine völlig neue Tool-Suite: Angular und Twitter Bootstrap und natürlich jQuery. Was ich verfolge, ist, die gesamte Benutzeroberfläche aus statischen Ressourcen zu erstellen. Keine der Benutzeroberflächen ist darauf angewiesen, dass der Server dynamische Benutzeroberflächeninhalte generiert. Es muss in einem einfachen Apache-Webserver funktionieren. kein PHP, kein Perl, nichts.

In Bezug auf die Service-Schicht verfügt GFS über ein enormes Java-Erbe. Und zum größten Teil ist es eigentlich ziemlich gut. GFS verfolgt seit Jahren eine serviceorientierte Architektur unter Verwendung von Spring POJOs. Dienstleistungen bilden den Kern von SOFEA. JSON ist heutzutage der Datentransport der Wahl, und Spring MVC macht es einfach, diese POJOs über JSON verfügbar zu machen. SOFEA passt also wirklich gut zu GFS.

Der herausfordernde Teil war jedoch die Vision, diese Web-Benutzeroberfläche wirklich statisch zu machen. Um eine gute Web-App zu erstellen, die schnell ist, sind einige andere Tools erforderlich. Ich verwende Compass zum Verwalten von CSS. Für JavaScript verwende ich den Google Closure-Compiler, der die großartige Funktion von Quellkarten bietet. Wenn Sie einige andere Anforderungen an das Cache-Busting stellen und die Entwicklung vereinfachen, benötigen Sie plötzlich eine vollständige Build-Lösung für etwas, das nur noch aus einer Reihe von Textdateien besteht.

Es gibt einige beeindruckende Tools, die begonnen haben, diese Herausforderungen zu beantworten. Ich war ziemlich beeindruckt von Grunt und Yeoman und habe sogar den Pitch zu GFS gemacht, um Maven für Yeoman aufzugeben. Zumindest für die Web-Benutzeroberfläche. Ich hatte den Eindruck, dass es für Werkzeuge, die noch nicht einmal ein Jahr alt sind, etwas zu weit gehen könnte, Maven loszuwerden. Also fing ich an, ein Maven-Plugin zu erstellen, um das alles zusammenzubringen. Es gibt Maven-Plugins für Compass und Closure, aber sie bieten keine vollständige Lösung, die sogar die HTML-Entwicklung im Vergleich zur Produktion ändern und Live-Reload-Funktionen bieten kann. Dies war tatsächlich eine wundervolle Erfahrung beim Schreiben dieses Maven-Plugins, das natürlich in Java geschrieben ist.

Vielleicht kann ich das Management bald davon überzeugen, dass ich dies der Open-Source-Community zurückgeben kann.

Matt Heusser : Wie lange sind Sie schon Architekt? Woran haben Sie vor einem Jahr gearbeitet?

Bruce Brouwer : Ich bin jetzt seit acht Jahren Anwendungsarchitekt. Als ich zu GFS wechselte, machte ich den Sprung vom leitenden Programmierer zum Architekten.

Mein vorheriges großes Projekt, an dem ich vor einem Jahr gearbeitet habe, war der Übergang zu Google Apps. Dies war auch für mich eine echte Lernerfahrung. Ich hatte die großartige Idee, den alten Kalender während des Übergangs mit Google Kalender zu synchronisieren. Ich habe die Google-APIs von Java zusammen mit Spring Integration verwendet, um alles möglich zu machen. Zumindest für eine Weile. Nach ein paar ernsthaften Pannen musste ich zugeben, dass es das Risiko nicht wert war. Als Architekt und Entwickler dieses Projekts konnte ich die reale Welt im Blick behalten.

"Wir mussten eine Linie in den Sand ziehen, um festzustellen, wofür Google bei der Integration in unsere vorhandenen Systeme geeignet ist und was nicht. Es kann schwierig sein, wenn Sie gezwungen sind, einen Teil dieser Begeisterung zu mildern."

Google bietet GFS eine völlig neue Welt der Möglichkeiten. Wir spüren die Auswirkungen erst bei der Gestaltung unserer Systeme. Ich habe bereits viele Gespräche mit Leuten geführt, die Google nutzen möchten, weil es das glänzende neue Spielzeug ist. Wir mussten eine Linie in den Sand ziehen, um festzustellen, wofür Google bei der Integration in unsere vorhandenen Systeme geeignet ist und was nicht. Es kann schwierig sein, wenn Sie gezwungen sind, einen Teil dieser Begeisterung zu mildern.

Matt Heusser : Als Architekt haben Sie ein Niveau erreicht, das nur ein kleiner Prozentsatz der Programmierer erreicht. Haben Sie Ratschläge für Programmierer, die ihre Karriere beginnen?

Bruce Brouwer : Ich liebe es, wenn neue Programmierer auf die Idee kommen, den aktuellen Status Quo in Frage zu stellen. Normalerweise möchten sie ein neues Tool verwenden, um eine Aufgabe zu vereinfachen. In diesem Fall kann ich ihnen helfen, das Gesamtbild zu betrachten. Oft bedeutet dies, auf die Probleme bei der Einführung dieses Tools hinzuweisen. Das Durchsprechen der Probleme zwingt den neuen Programmierer manchmal dazu, die Augen für größere Probleme zu öffnen.

Mein Rat an einen neuen Programmierer ist also, einige Ideen herauszufordern. Finden Sie einen erfahrenen Programmierer oder Architekten, den Sie als Mentor einsetzen können, und äußern Sie Ihre Idee. Wahrscheinlich wird die Idee nicht aufgehen, aber Sie werden viel lernen, indem Sie herausfinden, warum Sie falsch liegen, und nicht nur, dass Sie falsch liegen. Aber denken Sie auch daran, dass erfahrene Programmierer und Architekten unter Kurzsichtigkeit leiden können und Sie möglicherweise eine Idee finden, die es wert ist, verfolgt zu werden.

Matt Heusser : Wer ist Ihr Kunde? (Oder um eine Zeile von den Bobs in "Office Space" auszuleihen: Was würden Sie sagen, was Sie hier tun?)

Bruce Brouwer : Ich unterstütze keinen Kunden direkt in dem Sinne, dass es einen direkten Geschäftsfokus geben würde. Ich bin tatsächlich auf der Infrastrukturseite von IS, zusammen mit den DBAs und Serveradministratoren. Der Rest des IS konzentriert sich wirklich darauf, einen bestimmten Geschäftsbereich zu bedienen. Es mag seltsam erscheinen, einen Java-Entwickler in die Infrastruktur zu integrieren, aber ich kann mich auf Probleme konzentrieren, die einen größeren architektonischen Fokus haben als andere. Während andere versuchen, Geschäftsprozesse zu definieren, konzentriere ich mich mehr auf die Technologie, mit der alle Probleme auf wiederverwendbare Weise gelöst werden.

Ich werde oft gebeten, andere Projekte zu unterstützen. manchmal für längere Zeit. Dies hilft mir, in der realen Welt geerdet zu bleiben. Es hilft mir auch, neue Ideen im Rest der Entwicklungsteams zu verbreiten. Ich habe festgestellt, dass mein Einfluss auf mehr Nachwuchsentwickler beschränkt war, als ich gebeten wurde, die Rolle des Architekten des Projekts zu übernehmen. Tatsächlich war es für mich nützlicher, an anderen Projekten mitzuwirken, für die bereits ein Architekt zuständig ist, da ich meine Ideen mit denen teilen kann, die in ihrem Teil der Organisation einen größeren Einfluss haben.

Matt Heusser : Wie lange programmieren Sie schon in Java? Wie haben Sie gesehen, dass sich die Sprache und die Java-Programmierung in diesen Jahren geändert haben?

Bruce Brouwer : Ich habe Java bis Java 1.3 nicht wirklich ernst genommen. Das wären also ungefähr 13 Jahre. Aber selbst dann wurde Java nicht wirklich zu einer Freude bei der Entwicklung, bis 1.5 mit Generika auf den Markt kam. Es gibt so viele gute Verwendungsmöglichkeiten von Generika, und die meisten Leute scheinen sie nicht über das Java-Sammlungs-Framework hinaus zu verwenden.

Als ich mit Java angefangen habe, haben wir fast alles selbst geschrieben. Im Laufe der Zeit habe ich gesehen, wie der Rest der Welt Java angenommen hat, insbesondere in der Open Source-Community. Diese Explosion von Open Source ist die wichtigste Änderung, die ich während meiner Karriere in der Java-Programmierung durchgemacht habe. Es ist etwas, das bis vor kurzem von keiner anderen Sprache erreicht wurde.

Matt Heusser : Sprechen Sie mit mir über die Verwendung von JRuby bei GFS. Wie sehen Sie JVM-Sprachen? Sollen wir jetzt alle Clojure-Programmierer werden?

Bruce Brouwer : JRuby war wirklich ein Mittel zum Zweck in Gordons. Compass ist wirklich die erste Sass-Implementierung, die es gibt, und sie ist zufällig in Ruby geschrieben. Ich habe auch Rhino und Groovy für die JVM verwendet. Ich habe gesehen, wie mächtig und fähig diese anderen Sprachen sind, aber auch Java.

Andere Sprachen wie Scala und Sie haben Clojure erwähnt, haben in letzter Zeit an Popularität gewonnen. Während Sie in Scala mit etwa der Hälfte des Java-Codes dasselbe tun können, kann die Lesbarkeit meiner Meinung nach schneller leiden als in Java. Vor einiger Zeit sah ich eine Reihe von Auftragnehmern mit Aufklebern auf ihrem Laptop, auf denen stand: "Tippen ist nicht der Engpass." Ich stimme vollkommen zu. Es ist wichtiger, das Problem zu durchdenken und es dem nächsten klar zu machen, als clevere Wege zu finden, um die Anzahl der von Ihnen geschriebenen Codezeilen zu reduzieren. Versteh mich nicht falsch, weniger Code zu pflegen ist besser als mehr Code, aber es muss klar sein, was los ist.