Was ich beim Entwickeln von Googles Frameworks gelernt habe

Artikel vom 5. Oktober 2017. ISSN 1614-3124, #54. Schwerpunkt: (RSS-Feed für alle Themen).

Das hier oft erwähnte Buch zu Frameworks ist auch auf Deutsch erhältlich: Das kleine Buch der HTML-/CSS-Frameworks. Es beinhaltet auch diesen Artikel.

In The Little Book of HTML/CSS Frameworks (überarbeitet) habe ich eine Übersicht und viele Praxistipps zu Frameworks veröffentlicht; ich halte das Buch für eines meiner besten Werke, auch wenn nicht jeder seinen Empfehlungen zustimmt (in den meisten Fällen sollten wir externe Frameworks vermeiden, weil sie die Vision bzw. das erste Paradigma der Webentwicklung verletzen).

Nirgendwo habe ich jedoch bisher über die Erfahrung gesprochen, einige große Frameworks entwickelt zu haben – weder über das 2004er Framework (auch wenn wir es damals nicht so genannt haben) von GMX und Partner-Sites wie 1&1, was wahrscheinlich zur ersten europäischen Milliarden-Besucher-Website führte, die auf validem HTML und vollständig entkoppeltem CSS basierte (ich bin immer noch etwas stolz auf das damals Erreichte), noch über die 2008er und 2012er Frameworks, die ich bei Google baute, die letztlich auf zehntausenden Google-Seiten verwendet und damit einige Milliarden Mal aufgerufen wurden. Was folgt, erzählt einen Teil der Google-Geschichte.

Diese Geschichte sollte mit dem Zustand von Googles informationsbezogenen Websites in 2008 beginnen, als einige qualitätsbewusste Webentwickler, einer von ihnen ich, bei Google anfingen, zu arbeiten. Gelinde gesagt: Es war nicht schön, und wir erhielten viel Kritik von einer Vielzahl angesehener Entwickler (dies machte dann einen der Gründe aus, warum es spannend war, sich dem Webmaster-Team anzuschließen).

Von außen, und so einige andere Googler waren sich dessen bewusst, bestand die Unschönheit hauptsächlich in der schlechten Code-Qualität von Googles Websites und Produkten. Die Google-Homepages bekam dabei die meiste Aufmerksamkeit, aber auch bei Produkten, die sonst gut ankamen, wurden Qualitätsprobleme von Fachleuten nicht übersehen.

Von innen, und von hier an werde ich nur noch von Google-Websites (und nicht mehr Produkten) sprechen, war klar, dass uns effektivere Prioritäten, Prozesse und – noch wichtiger – Werkzeuge fehlten; zu diesem Zeitpunkt wurden die meisten von Googles Websites händisch erstellt und gewartet.

An diesem Problem arbeitete das Team, speziell das Kernteam in Mountain View sowie ein paar Entwickler in Zürich, um ein Content-Management-System zu implementieren, das auch in Google-Dimensionen funktionierte. Wir veröffentlichten regelmäßig Websites und Einstiegsseiten in dutzenden Sprachen, und unsere Code-Basis, HTML-Dokumente mitsamt anderem Beiwerk, umfasste schon 2008 eine sechsstellige Zahl von Dateien.

Eine Herausforderung wie auch Gelegenheit war die Diversität der Sites und Seiten, die wir erstellten. Ja, es gab eine Google-Kernidentität und Google arbeitete an einem unternehmensweiten Styleguide (die UX-Organisation um Irene hatte sich dem angenommen) – aber viele unserer Websites, zumindest Elemente darauf, waren einzigartig und einmalig. Diese Einzigartigkeit machte einen Grund aus, warum es noch keine solide technische Basis gab, und ich begann proaktiv, das erste Google’sche HTML-/CSS-Framework zu entwickeln: Go (es ging der Programmiersprache voraus, dessen Team der Namenskonflikt entging).

Go

Go ist speziell, was schlicht den einmaligen Umständen geschuldet war. Go ist, und selbst in minifizierter Form kriegt man davon einen Eindruck, ein kompaktes Framework. Das ist by design. Aber wie wurde es entworfen, und warum? Dazu sollten wir nochmal auf Googles Landschaft an Websites blicken – ein Blick, der tatsächlich Pflicht ist, wenn wir Frameworks entwerfen (aber auch benutzen).

Besagte Landschaft bestand aus einem international verteilten Team – dem Webmaster-Team – mit bunt gemischten internen Kunden, die von Googles Corporate Communications über Legal bis hin zu Marketing reichten, das eine große Zahl von unterschiedlichen und lokalisierten – bis zu 40, manchmal 50 Sprachen – Websites betrieb. Das erschuf einiges an Einzigartigkeit. Gleichzeitig geschah alle Arbeit unter dem Schirm von Google, einige Designaspekte wurden entsprechend von allen Seiten geteilt.

Sie nehmen sicher schon wahr, dass dieser übereinstimmende Teil klein war, und dass das, und nicht die hohe Zahl von Unterschieden, einen zentralen Teil von Gos Vision ausmachen musste: Go sollte nicht versuchen, »alles« abzudecken, was wir taten, sondern gut an der Basis funktionieren. Den kleinsten gemeinsamen Nenner finden und abbilden, das war die Idee.

Das nächste Prinzip hinter Go war Einfachheit, da diese Einfachheit große Gewinne versprach: Zum einen hat Einfachheit eine große Zahl großer technischer Vorteile, von höherer Geschwindigkeit über größere Robustheit bis hin zu leichterer Wartbarkeit. Zum anderen führt Einfachheit zu guter Entwicklerbenutzerfreundlichkeit (Entwicklerfreundlichkeit?) mitsamt, etwas das für die Arbeit an Go relevant war, einer besseren Chance auf Akzeptanz und Annahme.

Diese Chance resultierte dann in etwas, das ich auswendig illustrieren möchte, fünf oder sechs Jahre, nachdem ich die letzte Go-Seite erstellt habe; man konnte ein HTML-Dokument wie folgt schreiben: 

<!DOCTYPE html>
<title>Google Test</title>
<link rel=stylesheet href=/css/go.css>
<h1><a href=/><img src=/logo alt=Google></a> Test</h1>
<p>Das ist nur ein Test [mit validem HTML].

Ebenso auswendig hervorgekramt, Go verwendete dann so wenig Klassen und IDs wie möglich – und zwar die folgenden: .rtl, .compact, #about, #nav und #aux. Die Grundseitentypen waren ganze Breite, ganze Breite mit Navigation, kompakte (schmale) Seite und kompakte Seite mit Navigation. Die Zentrierung wurde durch die .compact-Klasse erzielt (auf body); das Hinzufügen einer Navigationsliste (#nav) erzeugte »automatisch« die Navigationsseitentypen; &c. Alle Seitentypen waren liquid und inhärent mobil-bereit. Das nur, um einen Eindruck von der Simplizität und Benutzerfreundlichkeit zu geben. (Als HTML 5 noch keimte und es noch keine logischen Eigenschaften in CSS gab, beruhte #about auf meiner Präferenz gegenüber #footer (und <footer>), und #nav spiegelte das sich zu dem Zeitpunkt noch in Planung befindliche nav-Element wider.)

Wie befriedigte Go dann die vielen Bedürfnisse, die in den Projekten mit unseren internen Kunden aufkamen? Wie auch schon durchscheinen mag: Go tat das nicht. Eines der Designziele war tatsächlich, dies gar nicht erst zu probieren. Go definierte den Kern von Googles Websites auf eine Weise, die so einfach wie möglich gehalten wurde, und erkannte die Einzigartigkeit und systemische Nicht-Managebarkeit all der unterschiedlichen Google-Sites durch zwei andere Entscheidungen an:

  1. das Definieren anderer populärer Seitenelemente (wie Formulare) in einer Bibliothekserweiterung, »Go X« (man importierte in diesem Fall go-x.css, was leicht zu merken war);

  2. das Teilen der Verantwortung und das Ăśberlassen von allem anderen an die Webentwickler, die an dem jeweiligen Projekt arbeiteten (so dass diese Go oder Go X in ihrem default.css-Projekt-Stylesheet importierten und ihr eigenes Ding machten).

Auf rasche Akzeptanz und Annahme hoffte ich nicht nur durch Benutzerfreundlichkeit – die Stylesheet-URL verinnerlichen und in ein einfaches HTML-Dokument mit Google-Logo packen –, sondern auch durch ein paar weitere Faktoren, die an qualitätsverwandte Logistik erinnern:

Aus technischer Sicht halte ich Go für eines der elegantesten Dinge, die ich bisher entwickelt habe. Go war einfach, leicht, robust, erweiterbar, skalierbar und wartbar. Bis heute erscheint es basal und unspektakulär, und genau das war sorgfältig überlegt und funktionierte außerordentlich gut. Acht Jahre später gibt es wenig, das ich ändern würde (ich würde neuere HTML- und CSS-Features einsetzen, um Go noch kompakter zu machen).

Bei alldem aber muss ich auch sagen, dass ich aus technischer und leitender Perspektive damit gescheitert war, größere Akzeptanz für Go zu finden. Ich hatte Fehler gemacht, andere erfahrene Entwickler im Team einzubeziehen und besser mit ihnen zusammenzuarbeiten. Ich hatte versäumt, Gos Vorteile näher zu erläutern und damit mehr Unterstützung in Team und Management zu gewinnen. Manche Reibung im Team und einige verlorene Zeit dabei, Go zum Standard zu machen, waren das Ergebnis davon. Ich musste lernen.

Maia

Vorwärts. Eine der dringendsten Fragen, die ich mir 2012 stellen musste, war, wann wir ein neues Framework bauen würden. (Wann würden Sie?) In meinem Kopf war das Denken bislang zu aktualisieren, iterieren, ohne Versionierung, weil Webdesign, ebenso Webentwicklung, ein Prozess ist – und trotzdem wich ich das erste Mal von dieser Position ab. Warum?

Als wir – immer noch Googles Webmaster-Team – an einem neuen Design für alle informationsbezogenen Google-Sites arbeiteten, war absehbar, dass dies Konsequenzen für unseren Einsatz von Frameworks haben würde. Als Leiter des Projekts mutete dies für mich erst nach einem Update für Go an. Ich änderte diese Ansicht jedoch angesichts folgender Überlegungen:

Diese Punkte führten mich dazu, Bemühungen zu unterstützen und dann anzuführen, ein neues Google-Web-Framework zu entwickeln, ein Framework, dass ich »Maia« taufte (es ist ebenfalls noch in Gebrauch, obwohl ich nicht weiß, ob es gewartet und wie sehr es modifiziert wurde) – »Maia« wegen eines Faibles für griechische Mythologie: Maia, Mutter von Hermes.

Die Geschichte von Maia ist anders als die von Go, insbesondere dadurch, dass Maia eine offiziell abgesegnete Teamunternehmung war, mit einem Team von fünf Webmastern, für deren Arbeit ich verantwortlich war. Der Prozess und die Organisation waren ähnlich zu dem, das ich in The Little Book of HTML/CSS Frameworks beschreibe – angefangen bei der Motivation, eine zugeschnittene Lösung zu den eigenen (Design-)Problemen zu schaffen, über die Gründung eines Team, das über entsprechende Ziele und Werkzeuge verfügte, bis hin zur Kommunikation an eine nochmal größere Organisation. Ich glaube, dass The Little Book of HTML/CSS Frameworks ein nützliches Buch ist, um mehr über solche Entwicklung zu erfahren, aber es folgen hier die Eckpfeiler für die Arbeit an Maia:

Abgesehen von den komplexeren visuellen und technischen Anforderungen war die Entwicklung von Maia als Team der größte Unterschied zur Arbeit an Go, und zusammen mit stärkerem Management-Support wohl der wesentliche Faktor dabei, weitreichende Akzeptanz zu gewährleisten und zu beschleunigen.

Es fällt auf, dass ich Maias Geschichte knapp halte, sie gar abrupt beende; aber genau der Umstand, dass Maia Teamarbeit war, lässt es mich bevorzugen, hierüber – wenn das möglich wäre – mit dem Team zu schreiben.

Erkenntnisse

Das Geschilderte ist schon mit einigen Lektionen versehen, aber dies ist, was ich betonen möchte.

  1. Auch wenn ich das nicht direkt bei Google lernte – ich bin Idealist –, will ich es doch erwähnen, weil es mir wichtig erscheint: Nicht nur durch die Fokussierung und Segmentierung von Framework-Verantwortlichkeiten (wie bei Go und Go X getan) ist es absolut möglich, zugeschnittene, effiziente und trotzdem benutzbare Frameworks zu bauen und zu warten. (Das ist auch ein Kernpunkt in The Little Book of HTML/CSS Frameworks. Es gibt keinen Grund, unnötigen Code und schlechte Qualität hinzunehmen.)

  2. Um eine hochwertige Lösung zu bauen, ist Kommunikation wichtiger als Konsens. Ich habe meine Probleme mit Demokratie als Entscheidungswerkzeug, da ich diese selten die beste Lösung erbringen sehe – und im Technischen gibt es oft so etwas wie ein »bestes«. Aber ich habe auch Probleme gehabt, als ich ein Team vernachlässigte, um einfach die Lösungen voranzutreiben, die nur ich für am besten erachtete. Eine Alternative ist, die beidseitige Kommunikation zu verbessern: dem Team zuhören, andere Experten aus dem Team involvieren, Unterstützung vom Management einholen, &c.

  3. Dies kam gar nicht auf, als ich über Maia sprach, und ich widerspreche auch meinem vergangenen Selbst: Es ist kritisch, zu vermeiden, ein zusätzliches Framework zu bauen. Die Vision muss sein, zu iterieren und zu warten – und nicht »Fire and Forget«. Ich hatte nichts großartig probiert, nicht gekämpft; ich hatte den Gewinn mitgenommen, den ich mit Go hatte, und dann den bequemen Weg beschritten, halbherzig ein kleines Team zu führen, um Konfrontation innerhalb der Organisation zu vermeiden (Unternehmenspolitik hatte dann auch mich erreicht, so scheint es). Das ist ein sehr anderer Schnack so plötzlich, aber ich hatte den wohl technisch inferioren Pfad genommen, als ich uns zugestand, an einem anderen Framework zu arbeiten, und damit einiges von dem geopfert, von dem wir zuvor so profitierten und was Go auszeichnete.

❧ Zum Abschluss wünsche ich, dass hier einige Dinge dabei sind, die für Ihre eigenen Framework-Entscheidungen nützlich sind, so dass Sie ernten können, was wir geerntet haben, ohne die Fehler zu machen, die ich gemacht habe. Selbst wenn ich diese lediglich anschnitt. (Und wenn Sie noch mehr mögen, werfen Sie einen Blick auf The Little Book of HTML/CSS Frameworks und meine englischen Beiträge zum Thema Webentwicklung.)

Mit herzlichen WĂĽnschen an das alte Webmaster-Team. Die Arbeit mit euch allen war eine groĂźe Ehre und ein groĂźes VergnĂĽgen. Ich denke gerne daran zurĂĽck.

War dies nützlich oder interessant? Teile diesen Beitrag, und unterstütze meine Arbeit, indem du mit meinen E-Books lernst!

Ăśber mich

Jens Oliver Meiert, am 9. November 2024.

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)