Die Softwarearchitektur wird überbewertet, das einfache Design wird unterschätzt

Wir bieten Ihnen die Übersetzung des Postens von Gergel Oros an, der die Position des Engineering Managers bei Uber innehat. Darin teilt er seine Ansicht zum Design von Großsystemen auf der Grundlage seiner eigenen praktischen Erfahrung in Uber und Microsoft. In Kombination mit Kommentaren zu Hacker News , die gewichtige Gegenargumente hinzufügen und die Sichtweise des Autors ergänzen, ist sein Artikel zu einem der interessantesten Beiträge der Woche geworden. Der Begriff „Code-Design“ wird im Artikel zum Vergleich mit traditioneller „Architektur“ verwendet - mehr dazu finden Sie hier .

Ich habe genug Erfahrung im Entwerfen und Erstellen von Großsystemen. Ich war an der Umschreibung eines verteilten Zahlungssystems bei Uber beteiligt, habe Skype auf der Xbox One entworfen und veröffentlicht und RIBs , ein von Uber erstelltes Framework für mobile Architektur, öffentlich veröffentlicht . Alle diese Systeme hatten ein sorgfältig durchdachtes Design, durchliefen mehrere Iterationen und es fanden viele Besprechungen am Whiteboard und andere Diskussionen statt. Dann entwickelte das Design ein Designdokument, das unter anderen Entwicklern verteilt wurde, um zusätzliches Feedback zu sammeln, das fortgesetzt wurde, bis wir mit der Entwicklung fortfuhren.

Alle diese Systeme waren großformatig: Hunderte von Entwicklern haben sie erstellt - oder sie haben sie in ihren Entwürfen verwendet - und heute schlagen sie in die Herzen von Systemen, die Millionen von Menschen täglich verwenden. Darüber hinaus wurden diese Projekte nicht von Grund auf neu erstellt. Das Zahlungssystem sollte zwei andere bestehende Zahlungssysteme ersetzen, die von Dutzenden anderer Systeme und Dutzenden von Teams verwendet werden, ohne das Geschäft zu schädigen. Das Umschreiben der Uber-Anwendung war ein Projekt, an dem mehrere Hundert Ingenieure gleichzeitig arbeiteten. Dazu gehörte die Portierung aller vorhandenen Funktionen auf die neue Architektur.

Lassen Sie mich mit etwas beginnen, das unerwartet klingen kann. Erstens haben wir nie Standard-Planungswerkzeuge für die Softwarearchitektur verwendet, um an den Entwürfen dieser Systeme zu arbeiten. Wir haben weder UML noch das 4 + 1- Modell, noch ADR , noch C4 oder die Abhängigkeitsdiagramme verwendet . Wir haben viele Diagramme gezeichnet, aber keines davon folgte strengen Regeln. Es wurden nur gute alte Rechtecke und Pfeile benötigt - und wir haben ähnliche Diagramme erhalten, die den Informationsfluss beschreiben , oder ein anderes, das die Struktur der Klasse und die Beziehung zwischen den Komponenten darstellt . Zwei Diagramme im selben Designdokument hatten häufig einen unterschiedlichen Stil, da sie häufig von unterschiedlichen Personen hinzugefügt oder bearbeitet wurden.

Zweitens hatten wir keine Architekten, denen das Design gehören würde. Es gab weder IT Architect noch Enterprise Architect . Dies ist wahr - weder Uber noch Skype / Mircrosoft haben eine Vollzeitstelle für Softwarearchitekten. Von übergeordneten Ingenieuren, beispielsweise in der Position des Staff Engineer, wird weiterhin erwartet, dass sie regelmäßig Code schreiben. Alle unsere Projekte haben erfahrene Ingenieure - jedoch besitzt keine einzige Person Architektur oder Design allein. Während erfahrene Ingenieure die treibende Kraft hinter dem Entwurfsprozess waren, waren andere Entwickler an der Diskussion beteiligt, einschließlich sogar des grünen „Juni“. Darüber hinaus stellten sie häufig die Entscheidungen anderer in Frage und brachten alternative Diskussionsoptionen vor.

Drittens haben wir fast nie auf gängige Architekturmuster und andere allgemein anerkannte Fachsprache verwiesen , die in der populären Literatur zur Softwarearchitektur wie dem Handbuch von Martin Fowler verwendet werden . Es gab keine Verweise auf Microservices, serverlose Architektur, Anwendungsgrenzen , ereignisgesteuerte Architektur oder irgendetwas anderes. Einige dieser Begriffe tauchten während Brainstorming-Sitzungen auf. Wir mussten uns jedoch nicht selbst in der Konstruktionsdokumentation darauf beziehen.

Software-Design bei Technologieunternehmen und Startups

Wie sind wir mit allem umgegangen? Und warum haben wir keine gemeinsamen Ansätze für die Softwarearchitektur verfolgt?

Ich habe dieses Problem mit Kollegen besprochen, die in anderen Technologieunternehmen arbeiten - sowohl FANG-Größen (Facebook, Amazon, Netflix, Google) als auch kleine Startups. Die meisten Teams und Projekte - ob groß oder klein - kombinierten einen ähnlichen Ansatz für Design und Implementierung:

1. Beginnen Sie mit einer Geschäftsaufgabe. Welches Problem versuchen wir zu lösen? Welches Produkt versuchen wir zu erstellen und warum? Wie können wir den Erfolg messen?
2. Brainstorming für den gewählten „Ansatz“. Treffen Sie sich mit dem Team und finden Sie in wenigen Sitzungen eine funktionierende Lösung. Verzögern Sie nicht zu sehr mit dieser Phase. Beginnen Sie von der obersten Ebene und senken Sie sich allmählich auf die darunter liegenden Ebenen ab.
3. Zeichnen Sie Ihren Ansatz an die Tafel. Sammeln Sie das Team und lassen Sie einen von Ihnen den Ansatz darstellen, zu dem sich das Team neigt. Sie sollten in der Lage sein, die Architektur Ihres Systems / Ihrer Anwendung mithilfe einer Karte klar zu erklären - ausgehend von der höchsten Ebene und, falls erforderlich, immer tiefer. Wenn Sie Schwierigkeiten mit einer Erklärung haben oder diese für Kollegen nicht klar genug ist, müssen Sie die Details Ihrer Entscheidung besser ausarbeiten.
4. Korrigieren Sie es in Form einer einfachen Dokumentation mit einfachen Diagrammen, die auf dem basieren, was Sie zuvor mit Whiteboarding erklärt haben. Halten Sie den Jargon auf ein Minimum: Sie möchten, dass auch Junioren verstehen, was gesagt wird. Verwenden Sie in Ihrer Beschreibung eine klare und einfache Sprache . Bei Uber verwenden wir ein RFC-ähnliches Dokument, das auf einer einfachen Vorlage basiert.
5. Diskutieren Sie Kompromisse und Alternativen . Gutes Software-Design und gute Architektur sind die richtige Wahl für Kompromisse. An und für sich ist keine der Designentscheidungen schlecht oder gut: Alles hängt vom Kontext und den Zielen ab. Ist Ihre Architektur in verschiedene Dienste unterteilt? Erwähnen Sie, warum Sie sich entschieden haben, keinen großen Dienst zu leisten, für den es weitere Vorteile wie eine einfachere und schnellere Bereitstellung geben könnte. Haben Sie beschlossen, das Modul oder den Dienst um neue Funktionen zu erweitern? Wägen Sie stattdessen die Möglichkeit ab, einen separaten Dienst oder ein separates Modul zu entwickeln, und welche Vor- und Nachteile dieser Ansatz hat.
6. Verteilen Sie das Designdokument innerhalb des Teams / der Organisation und sammeln Sie Feedback. Früher in Uber haben wir alle Konstruktionsdokumente für die Software an alle unsere Ingenieure gesendet - bis unsere Mitarbeiter auf 2.000 Mitarbeiter angewachsen sind. Jetzt, da wir so groß geworden sind, versuchen wir immer noch, das größtmögliche Publikum zu erreichen - aber gleichzeitig haben wir begonnen sicherzustellen, dass der Pegel des Informationsrauschens die zulässige Grenze nicht überschreitet. Ermutigen Sie andere, Fragen zu stellen und Alternativen vorzuschlagen. Seien Sie pragmatisch in Bezug auf die Fristen für die Erörterung von Rückmeldungen und deren Aufnahme in das Dokument, falls erforderlich. Spezifische Wünsche können sofort und schnell umgesetzt werden, während detailliertes Feedback besser ist, um es mit einer Person persönlich zu zerlegen.

Warum unterscheidet sich unser Ansatz von dem, was normalerweise in der Literatur zur Softwarearchitektur erwähnt wird? Tatsächlich unterscheidet sich unser Ansatz grundsätzlich nicht so sehr von dem, was in den Architekturhandbüchern beschrieben wird. In fast allen Handbüchern wird empfohlen, mit einer Geschäftsaufgabe zu beginnen und Lösungen und Kompromisse zu beschreiben - das tun wir auch. Was wir nicht tun, ist, keine ausgefeilteren Werkzeuge zu verwenden, für die sich viele Architekten und Architekturbücher einsetzen. Wir dokumentieren das Design so einfach wie möglich und verwenden dabei die einfachsten und offensichtlichsten Tools wie Google Text & Tabellen oder Office 365.

Ich glaube, dass der Hauptunterschied in unserem Ansatz in der Ingenieurkultur verschiedener Unternehmen liegt. Ein hohes Maß an Autonomie und eine minimierte Hierarchie sind ein Merkmal, das modernen Technologieunternehmen und Start-ups gemeinsam ist. Bei traditionelleren Unternehmen ist dies bei weitem nicht immer der Fall. Dies ist auch der Grund, warum sie an diesen Orten häufig auf „Design basierend auf gesundem Menschenverstand“ anstatt auf Design basierend auf einem Prozess mit strengen Regeln zurückgreifen.

Ich weiß, dass Banken und Automobilunternehmen, bei denen Entwickler aktiv davon abgehalten werden, architektonische Entscheidungen zu treffen, ohne die Kette hochgehen zu müssen, die Genehmigung von Architekten auf mehreren Ebenen erhalten, die mehrere Teams beaufsichtigen. Dies verlangsamt den Prozess und bei einer großen Anzahl von Anforderungen werden Architekten überlastet. Daher erstellen diese Architekten noch formellere Dokumente in der Hoffnung, dass das System verständlicher wird - unter Verwendung aller Werkzeuge, die in der Ihnen bekannten Literatur beschrieben werden. Diese Dokumente werden durch einen Top-Down-Ansatz gesichert, da er die Ingenieure einschüchternd beeinflusst - schließlich sind sie keine Architekten und sollten Entscheidungen nicht bezweifeln oder bestreiten, da sie bereits mit formalen Methoden dokumentiert wurden, mit denen sie sich nicht auskennen. Daher tun sie dies normalerweise nicht. Ehrlich gesagt tun diese Unternehmen dasselbe, um Entwickler zu einer austauschbaren Ressource zu machen - denn so können sie in kurzer Zeit Menschen von einem Projekt zu einem anderen transferieren. Es wird Sie wahrscheinlich nicht überraschen, dass verschiedene Tools für verschiedene Umgebungen besser geeignet sind.

Einfaches Software-Design ohne Fachsprache anstelle von Architekturmustern

Das Ziel des Systemdesigns sollte die Einfachheit sein. Je einfacher das System ist, desto leichter ist es zu verstehen - und desto einfacher ist es, Probleme darin zu finden und zu implementieren. Je klarer die Sprache ist, in der es beschrieben wird, desto zugänglicher ist sein Design. Vermeiden Sie die Verwendung von Jargon, den jedes Mitglied des Teams nicht versteht - selbst der unerfahrenste Ihrer Kollegen sollte verstehen können, worum es auf der Ebene anderer geht.

Ein sauberes Design ist wie sauberer Code: Es ist leicht zu lesen und leicht zu verstehen. Es gibt viele großartige Möglichkeiten, sauberen Code zu schreiben. Sie werden jedoch häufig hören, dass jemand vorschlägt, mit dem Anwenden von Designmustern der Vierergruppe auf Ihren Code zu beginnen. Sauberer Code beginnt mit dem Prinzip der alleinigen Verantwortung, klaren Namen und leicht verständlichen Konventionen. Diese Prinzipien gelten gleichermaßen für reine Architektur.

Welche Rolle spielen architektonische Muster? Ich finde sie nützlich - genauso nützlich wie die Code-Design-Muster. Sie können Ihnen Ideen geben, wie Sie Ihren Code oder Ihre Architektur verbessern können. Nehmen Sie Code-Design-Muster: Ich merke es selbst, wenn ich einen Singleton im Code bemerke - und ich hebe die Augenbrauen und grabe tiefer, wenn ich eine Klasse sehe, die sich wie eine Fassade verhält, aber tatsächlich nur Anrufe tätigt. Aber der Tag ist noch nicht gekommen, an dem ich gedacht hätte: "Eine abstrakte Fabrik fragt hier nur danach." In Wahrheit habe ich lange gebraucht, um herauszufinden, was dieses Muster bewirkt und bevor es mir dämmerte. Das Verständnis resultierte aus harter Arbeit mit der Abhängigkeitsinjektion , einem der wenigen Bereiche, in denen dieses Muster weit verbreitet und äußerst nützlich ist . Ich gebe auch zu, dass ich, obwohl ich viel Zeit damit verbracht habe, die Designmuster der „Viererbande“ zu lesen und zu verstehen, meine berufliche Entwicklung als Programmierer viel weniger beeinflusst habe als das Feedback, das ich von anderen Entwicklern zu meinem Code erhalten habe.

Ebenso ist es gut, gängige Architekturmuster zu kennen: Sie reduzieren den Zeitaufwand für Diskussionen mit Personen, die sie genauso verstehen wie Sie. Architekturmuster sind jedoch nicht das Ziel und werden einfachere Systemdesignoptionen nicht ersetzen. Wenn Sie ein System entwerfen, stellen Sie möglicherweise plötzlich fest, dass Sie versehentlich ein allgemeines Muster angewendet haben - und das ist gut so, weil Sie später leichter auf den verwendeten Ansatz verweisen können. Aber Sie sollten niemals ein oder mehrere Muster nehmen und sie als Hammer verwenden, für den Sie immer Nägel sehen werden.

Architekturmuster entstanden, als Ingenieure darauf aufmerksam machten, dass es in bestimmten Situationen sinnvoll ist, ähnliche Entscheidungen in Bezug auf Design und Implementierung zu treffen. Im Laufe der Zeit erhielten diese Entscheidungen Namen, wurden aufgezeichnet und von der Öffentlichkeit diskutiert. Architekturmuster sind Werkzeuge, die nach der Suche nach Lösungen entstanden sind, in der Hoffnung, dass dies anderen das Leben erleichtern würde. Als Ingenieur sollten Sie eine unabhängige Suche nach Lösungen für Ihre Probleme als Ziel festlegen und während dieses Prozesses lernen - anstatt ein „Hype“ -Architekturmuster zu verwenden, in der Hoffnung, dass dies Ihr Problem löst.

Wie man lernt, wie man Systeme besser entwirft

Die Leute fragen mich oft um Rat: Wie kann man die Architektur und das Design von Systemen "pumpen"? Erfahrene Ingenieure empfehlen normalerweise, über Architekturmuster sowie Bücher über Softwarearchitektur zu lesen. Ich unterstütze voll und ganz die Empfehlung, so viel wie möglich zu lesen - insbesondere Bücher, da Sie so viel tiefer in das Thema eintauchen können als kurze Beiträge. Ich habe jedoch einige weitere praktische Empfehlungen.

• Binden Sie eines der Teammitglieder ein und machen Sie gemeinsam Whiteboarding. Zeichnen Sie an die Tafel, woran Sie gerade arbeiten, und erklären Sie die Bedeutung des Bildes. Stellen Sie sicher, dass Ihre Kollegen verstehen, was gesagt wird. Und wenn Sie endlich verstanden sind, bitten Sie um Feedback.
• Beschreiben Sie Ihr Design in einem einfachen Dokument, teilen Sie es Ihrem Team mit und bitten Sie es um Feedback. Es spielt keine Rolle, wie einfach oder komplex die Aufgabe ist, an der Sie arbeiten - es kann sich entweder um ein kleines Refactoring oder um ein großes Projekt handeln - Sie sollten es kurz zusammenfassen. Tun Sie es so, dass dieses Dokument für Sie Sinn macht, und im Übrigen ist es klar; zur Inspiration - hier ist ein Beispiel, wie dies in Uber gemacht wird . Teilen Sie dieses Dokument mit Ihrem Team in einem Format, das das Kommentieren ermöglicht, z. B. mithilfe von Google Text & Tabellen, Office 365 oder ähnlichem. Bitten Sie andere, es mit ihren Gedanken und Fragen zu ergänzen.
• Erstellen Sie zwei verschiedene Designs und kontrastieren Sie sie. Wenn die meisten von uns Architektur entwerfen, gehen sie normalerweise einen Weg: den, der in ihrem Kopf auftaucht. Architektur ist jedoch nicht schwarz-weiß. Überlegen Sie sich eine zweite Option für das Architekturdesign, die möglicherweise auch in Ihrer Situation funktioniert. Vergleichen Sie beide Designs und erklären Sie, warum eines besser ist als das andere. Geben Sie an, dass Sie die zweite Option seit einiger Zeit als Alternative in Betracht gezogen haben, und erklären Sie, warum Sie eine Entscheidung getroffen haben, die nicht zu seinen Gunsten ist.
• Entscheiden Sie sich für die Kompromisse , die Sie eingehen möchten - finden Sie heraus, warum Sie sie akzeptieren und was Sie mit ihrer Hilfe erreichen möchten. Stellen Sie klar die bestehenden Einschränkungen fest, die Sie berücksichtigen mussten.
• Führen Sie eine Überprüfung der Designs anderer Personen durch. Und mach es mit Bedacht. Wenn Ihr Unternehmen die Kultur hat, Designs zu teilen, die Menschen mithilfe von Whiteboarding, Besprechungen oder Dokumenten teilen, können Sie mehr aus ihnen herausholen. Normalerweise nehmen die Leute während einer Überprüfung das Code-Design eines anderen als Beobachter wahr. Stellen Sie stattdessen klärende Fragen für Teile, die Sie nicht ganz verstehen. Fragen Sie, welche Alternativen sie in Betracht gezogen haben. Fragen Sie, welche Kompromisse sie eingegangen sind und welche Einschränkungen sie berücksichtigt haben. Seien Sie der Anwalt des Teufels und schlagen Sie eine andere, möglicherweise einfachere Alternative vor - auch wenn sie nicht besser ist als ihre Lösung - und fragen Sie, was sie über Ihren Vorschlag denken. Auch wenn Sie Ihr Design im Vergleich zu dem, der es präsentiert, nicht so gut durchdacht haben, kann Ihre Diskussion dennoch etwas Neues bringen und Ihnen helfen, die von Ihnen ausgeführte Aufgabe besser zu verstehen.

Das beste Software-Design ist einfach und leicht zu verstehen. Wenn Sie das nächste Mal ein neues Projekt starten, anstatt über die Frage nachzudenken: „ Wie werde ich dieses System entwerfen, welche Muster sollte ich im Kampf verwenden und mit welcher formalen Methodik sollte ich es dokumentieren? “, Denken Sie - „ Wie kann ich zu einem möglichst einfachen Design kommen - eines, das von jedem leicht verstanden wird? "

Die Best Practices der Softwarearchitektur, Architekturmuster von Unternehmensanwendungen und formale Methoden zur Beschreibung von Systemen sind nützliche Tools, da sie eines Tages für Sie sehr nützlich sein können. Beim Entwerfen von Systemen lohnt es sich jedoch, mit einem einfachen System zu beginnen und weiterhin so einfach wie möglich zu bleiben. Vermeiden Sie die Komplexität, die komplexere Architekturen und formale Tools unweigerlich für Ihre Systeme mit sich bringen.

Dieser Beitrag löste eine hitzige Diskussion unter Branchenarbeitern aus, die ihre Erfahrungen und Einstellungen zur Softwarearchitektur teilten. Sie können diese Diskussionen unter Hacker News , Lobste.rs und Reddit lesen.

Während die meisten Kommentatoren der Hauptbotschaft des Artikels zustimmen, stellen andere fest, dass ein solcher Ansatz in der Realität für die Welt der „blutigen Unternehmen“, in der Architekten aus gutem Grund „ihr Brot essen“, möglicherweise schlecht anwendbar ist. — 20 « », 300 IT- , — API, 5000 7000 .