Wie stoppe ich das Entwerfen und beginne mit der Architektur dieses Projekts, wie von meinem Leiter vorgeschlagen? [geschlossen]

Ich bin ein Junior-Entwickler (ca. 3 Jahre) und bei meiner Arbeit sind wir dabei, ein neues System zu entwerfen. Mein Hauptentwickler wird der Hauptarchitekt sein, er hat mich jedoch aufgefordert, das System selbst (parallel) zu entwerfen.

Während ein paar Durchläufen von Brainstorming-Ideen und Vorschlägen zu Architekturvorschlägen gab mir mein Leiter die Rückmeldung, dass das meiste, was ich getan habe, "Entwerfen" und nicht "Architekten" war.

Er beschrieb den Unterschied als implementierungsunabhängig, während ein Entwurf die Beschreibung einer Implementierung ist. Er sagte, ich müsse meinen Designerhut abnehmen und meinen Architektenhut aufsetzen. Er hat mir ein paar Ratschläge gegeben, aber ich möchte Sie auch fragen:

Wie verlasse ich den Software-Designer-Modus und beginne, mehr wie ein Architekt zu denken?

Hier sind einige Beispiele für "Entwürfe", die ich mir ausgedacht habe und die von meinem Vorgesetzten nicht als relevant für die Architektur angesehen wurden:

1. Ich habe einen Algorithmus zum Laden und Entladen von Ressourcen aus unserem System entwickelt und mein Chef sagte, dass Algorithmen grundsätzlich keine Architektur sind.
2. Ich hatte eine Reihe von Ereignissen, die das System auslösen sollte und in welcher Reihenfolge es sie auslösen sollte, aber auch dies schien es nicht als Architektur zu erkennen.

Ich scheine in die Details verstrickt zu sein und nicht weit genug zurückzutreten. Ich stelle fest, dass ich selbst dann, wenn ich etwas auf der Ebene der Architektur finde, oft verschiedene Implementierungen ausprobiert habe und mich in Details vertieft habe, um dann zu verallgemeinern und zu abstrahieren. Als ich dies meiner Führung beschrieb, sagte er, dass ich den falschen Ansatz gewählt habe: Ich musste "von oben nach unten" und nicht "von unten nach oben" denken.

Hier sind einige genauere Details zum Projekt :

• Das Projekt, das wir planen, ist eine Webanwendung.
• Ich schätze ungefähr 10-100.000 Codezeilen.
• Wir sind ein Startup. Unser Engineering-Team besteht aus ca. 3-5 Mitarbeitern.
• Das Beste, was ich mit unserer Anwendung vergleichen kann, ist ein leichtes CMS. Es hat eine ähnliche Komplexität und befasst sich hauptsächlich mit dem Laden und Entladen von Komponenten, Layout-Management und Plug-In-Stil-Modulen.
• Die Anwendung ist Ajax-y. Der Benutzer lädt den Client einmal herunter und fordert die erforderlichen Daten vom Server an.
• Wir werden das MVC-Muster verwenden.
• Die Anwendung verfügt über eine Authentifizierung.
• Wir sind nicht sehr besorgt über die Unterstützung alter Browser (Puh!), Daher versuchen wir, die neuesten und besten zu nutzen, die es gibt und die herauskommen werden. (HTML5, CSS3, WebGL ?, Media Source Extensions und mehr!)

Hier sind einige Ziele des Projekts :

• Die Anwendung muss skaliert werden. In naher Zukunft werden unsere Benutzer in der Größenordnung von Hunderten bis Tausenden sein, aber wir planen Zehntausende bis Millionen und mehr.
• Wir hoffen, dass die Anwendung für immer verfügbar sein wird. Dies ist keine vorübergehende Lösung. (Tatsächlich haben wir bereits eine vorübergehende Lösung, und was wir planen, ist der langfristige Ersatz für das, was wir haben.)
• Die Anwendung sollte sicher sein, da sie möglicherweise Kontakt mit vertraulichen persönlichen Daten hat.
• Die Anwendung muss stabil sein. (Im Idealfall ist es auf Google Mail-Niveau stabil, aber es muss nicht unbedingt das Extrem eines Mars-Rovers sein.)

Zunächst würde ich sagen, dass der Unterschied zwischen Architektur und Design hauptsächlich in der Semantik liegt. Einige Teams haben Kontrollpunkte zwischen den beiden. Ihr technischer Leiter definiert die Architektur wie vor dem Design und die Architektur als implementierungsunabhängig. Ich gehe davon aus, dass es sich um Design wie im Wasserfallmodell und nicht um Industriedesign handelt, mit dem Sie das Produkt im Hinblick auf die Benutzer entwerfen können, bevor Sie sich mit der Softwarearchitektur befassen. Ich denke, Architektur schlüpft oft in das Design und das ist nicht unbedingt eine schlechte Sache. Für den Architekten ist es oft sehr hilfreich, ein tiefes Wissen darüber zu haben, was im vorliegenden System möglich ist.

Wenn Sie das alles gesagt haben, brauchen Sie einige Ratschläge für die Situation, in der Sie sich befinden. Es gibt eine ganze Welt von Softwarearchitektur, Papieren, Büchern, Konferenzen, aber Sie suchen im Allgemeinen nach Mustern und Abstraktionen. Ohne nähere Angaben zum Projekt kann ich nur ein breites Beispiel geben. Wenn Sie beispielsweise in der Integration gearbeitet haben, gibt es die Service Oriented Architecture ( SOA)) Muster, in dem Sie Teile des Systems in "Dienste" aufteilen, so dass Sie mit jedem Teil auf definierte Weise arbeiten können. In Webprogrammen wird dies häufig als Webdienste implementiert (obwohl dies nicht so beschränkt sein sollte). und in jüngerer Zeit, als RESTful APIs mit JSON auf den Markt kamen, würde ich wieder sagen, dass dies ein Design ist, das aus der Architektur von SOA stammt. Ich würde sagen, Model, View, Controller (MVC) ist ein weiteres Beispiel für ein allgemein verwendetes Architekturmuster, das die Verantwortung der Komponenten eines Systems aufteilt, damit Teile ausgetauscht werden können, Fehler und Tests enthalten sind.

Ab einem Level von 10.000 Fuß ist es wahrscheinlich Architektur, wenn Sie es auf ein Whiteboard zeichnen und es einem kompetenten Programmierer erklären können, der nicht auf Ihrem Gebiet arbeitet und Ihre Programmiersprache und die aktuellen Implementierungsdetails nicht kennt. Wenn Sie ein Buch darüber schreiben können, das jedem außerhalb Ihres Unternehmens wichtig ist, dann ist es wahrscheinlich Architektur. Wenn Sie selbsterklärende Details finden und diese nicht auf andere Codebasen / Unternehmen / Branchen übertragen können, handelt es sich wahrscheinlich um Design.

Ich stimme zu, dass die beiden Beispiele, die Sie nennen, Code-Design und nicht Architektur sind. Das erste, weil ich denke, als Sie sagten, Sie hätten einen 'Algorithmus' zum Laden von Ressourcen entwickelt, meine ich, Sie haben eine Reihe von Anweisungen entworfen, um diese Aufgabe zu erfüllen, und nicht, dass Sie einen neuen Algorithmus entworfen haben, den sie im ersten Jahr lehren werden COMSC nächstes Jahr. Im zweiten Beispiel stimme ich wieder zu, dass es Design ist. Wenn Sie mir eine dieser Ideen zeigen würden, wäre ich nicht in der Lage, sie in meinem zufälligen Softwareprojekt zu verwenden. Sie müssen in Java auf eine höhere Ebene, objektorientiert (Object Oriented, OO), wechseln, anstatt dass die Kundenklasse eine Unterklasse der Personenklasse sein soll. Selbst wenn über Ausnahmen im Allgemeinen gesprochen wird, könnte dies als zu niedrig eingestuft werden (zu nahe an der Implementierung).

Ich denke, Sie sollten sich überlegen, wie Sie ein webbasiertes CMS erstellen, um die von Ihnen aufgeführten Besonderheiten zu berücksichtigen. Wordpress hat einen Site-Architektur-Kodex, in dem sie viel über Details der Design-Implementierung sprechen, aber aus dem Beitrag geht hervor, dass sich ihre Hauptarchitektur darauf konzentriert, Wordpress mit Themen erweiterbar zu machen. Es war eindeutig eine Architekturentscheidung, eine klare Benutzeroberfläche für ein Thema zu entwerfen, damit es von jemandem außerhalb des Unternehmens geschrieben werden kann. Dies ist die Art von Dingen, die es gut ist, sich bei der Entwicklung Ihrer langfristigen (nicht temporären) Lösung auf Papier zu bringen, damit alle Entscheidungen zu Design und Implementierung, die während der Entwicklung getroffen werden (von allen Entwicklern, nicht nur vom Architekten). sind im Einklang mit dieser Idee.

Weitere Architekturbeispiele für Ihre Situation:

1. Das Ganze auf virtuellen Maschinen bereitstellen, die auf einem Cloud-Anbieter oder im eigenen Haus gehostet werden und über zustandslose Maschineninstanzen verfügen, sodass alle fehlerhaften Maschinen durch eine neue Instanz einer virtuellen Maschine ersetzt werden können, ohne dass eine Kopie in einem beliebigen Status erforderlich ist oder Informationen verloren gehen.
2. Mit Chaos Simians von Anfang an Fehler in der Live-Produktion testen .

Versuchen Sie vielleicht, das gesamte System auf einem Whiteboard zu zeichnen. Probieren Sie es mit verschiedenen Detaillierungsgraden aus. Das erste Board könnte GUI-> Dispatcher-> Backend-> DB oder so sein. Führen Sie dann einen Drilldown durch, bis Sie anfangen, Pronomen zu verwenden.

Die Unterscheidung zwischen diesen beiden Ideen ist wirklich wichtig, wo ich arbeite.

Was Sie als "Architektur" bezeichnen, bezeichnen wir als "Programmieren auf Englisch". Dies ist zum Teil wichtig, denn wenn Sie es einem Nicht-Programmierer nicht beschreiben können, stimmt etwas nicht. Es kann sein, dass Sie das Problem nicht gut genug verstehen, ODER dass Sie ein "Phantom" -Problem lösen (hier nicht beschrieben).

Die Begriffe, die für diese beiden unterschiedlichen Aspekte des Designs verwendet werden, sind oft unterschiedlich, aber die Prinzipien sind überall leicht zu erkennen. Ein Aspekt (in Ihrem Fall der Architekt, in meinem Fall der Designer) programmiert auf Englisch, während der andere (in Ihrem Fall "Designer", in meinem Fall "Entwickler") in einer bestimmten Sprache programmiert. Sie werden auch häufig als "Design" und "Implementierung" unterschieden. "Design" ist das, was es leisten soll, und "Implementierung" ist der Code, der es ermöglicht.

Einige Beispiele aus dem, woran ich gearbeitet habe:

Die Architektur eines Programms lautet: Wir benötigen einen zentralen Manager oder Hub, dem wir problemlos Module hinzufügen können. Dieser Manager würde Ereignisse an alle registrierten Module verteilen. Ein Modul kann sich beim Event Manager registrieren und damit Ereignisse für den Rest des Systems veröffentlichen und Ereignisse empfangen, die ihm wichtig sind. Jedes Modul verfügt über eine "Mailbox", die es nach Belieben prüfen und leeren kann. Auf diese Weise könnten wir neue Module aufnehmen, die wir noch nicht benötigen.

Kein Code da. Könnte in jeder Sprache geschrieben werden. Die Implementierung wird durch diese Beschreibung nicht vorgeschrieben.

Die Architektur eines anderen Projekts lautet: Wir brauchen eine Möglichkeit, andere Programme zuverlässig zu starten und zu stoppen, ohne auf sie zu warten. Wir könnten einen Manager haben, der für ein bestimmtes Programm verantwortlich ist. Wir können ihm nur sagen, dass er sein Programm starten oder stoppen soll, und der Manager kümmert sich darum. Wenn dieses andere Programm zum Stoppen aufgefordert wird und dies in einer bestimmten Zeit nicht der Fall ist, weiß der Manager, wie er es zum Stoppen zwingen und das Durcheinander beseitigen kann. Das Programm wird von nichts anderem gestartet oder gestoppt, und der Manager kann gefragt werden, ob das Programm ausgeführt wird, gestoppt wird oder auf den Stopp wartet. Auf diese Weise können wir mit den anderen Aufgaben weitermachen, während die anderen Programme weiterhin ordnungsgemäß gestartet und gestoppt werden.

Auch hier schreibt nichts die Implementierung vor, obwohl einige Implementierungen eindeutig nützlicher sind als andere.

Der Unterschied zwischen Design (was wir als Muster oder Implementierung bezeichnen) und Architektur (was wir als Design bezeichnen würden) besteht darin, dass einer von ihnen ein Codierungs- / Implementierungsproblem und der andere ein Problem der realen Welt löst.

Vielleicht hilft das ja. Ich habe das Dienstalter eines Ingenieurs immer als eine Frage gesehen, wie groß das Problem ist, das er alleine lösen kann.

Grob gesagt, um die Idee zu vermitteln:

• Sie können jemandem die Programmierung kleiner, enthaltener Aufgaben mit vielen expliziten Anweisungen über die Integration der Aufgabe in andere Teile anvertrauen

• Ein Entwickler auf mittlerer Ebene ist jemand, der eine Beschreibung eines Teils einer Anwendung erstellen und diese im Kontext dieser Anwendung ausführen kann.

• Ein erfahrener Entwickler kann eine mittelgroße Anwendung innerhalb der technischen Grenzen eines Geschäfts von Grund auf neu erstellen.

• Ein erfahrener Entwickler kann dies tun und auf dem Weg darüber, welche Technologien verwendet werden müssen, damit es gut funktioniert, eine Auswahl an Technologien treffen.

... aber das sind keine festen Regeln. Und einige Leute kommen aus dem Tor als "Senior" IMHO, auch wenn sie einige Zeit mit einem anderen Titel verbringen müssen.

Was der Architekt fordert, ist, das Problem noch allgemeiner zu betrachten. Wenn Sie eine Reihe von Anwendungen zusammenstellen mussten, damit das System funktioniert:

• Welche Anwendungen und Dienste benötigen Sie?
• Welche Stücke interagieren mit Kunden und welche interagieren miteinander?
• Wie werden sie kommunizieren?
• Wo werden sie Daten speichern?
• Wo liegen die Risiken von Ausfällen?
• Wie sorgen Sie für Zuverlässigkeit?
• Wie geben Sie Sicherheit?

Technische Architektur ist also in gewissem Sinne wie eine Gebäudearchitektur. Es ist das Layout oder der Plan. Es zeigt, was für die verschiedenen Teile benötigt wird, wie sie zusammenhalten und warum .

(Übrigens, für Architekten wurde mir eine ähnliche Wachstumskurve erklärt, die von der Erstellung einer Familie verwandter Anwendungen oder einer Reihe sehr komplexer Features über die Festlegung der technischen Richtung für eine Gruppe bis hin zu strategischen technischen Entscheidungen für eine gesamte Organisation reicht .)

Trotzdem denke ich, dass die meisten Ingenieure auf allen Ebenen auch ein bisschen "architektonisch" arbeiten müssen. Es ist keine helle Linie. Es hört sich so an, als ob Sie sich zuerst auf das Gesamtbild konzentrieren und sich nicht auf die Implementierungsdetails festlegen müssen, da Sie eher dem entsprechen, wonach er sucht. Übrigens ist die Fähigkeit, sowohl das Gesamtbild als auch die kleinen Details zu sehen, ein großer Vorteil in dieser Branche. Das klingt nach einer großartigen Gelegenheit.

... Hier ist eine Analogie. Angenommen, Sie werden aufgefordert, eine Magic Black Box zu erstellen. Von einem Ingenieur wird erwartet, dass er von der Funktionsweise der Magic Black Box besessen ist. Aber als Architekt liegt Ihr Fokus anders. Sie könnten aus Neugier in die Box spähen, aber Sie erwarten , über alles obsess um alle Magic Black Boxes.

Ähnlich wie bei dieser Analogie könnte man sich die Rolle der Architektur so vorstellen, dass das gesamte System als magische Kiste betrachtet wird. Wenn Sie also eine gigantische Glasbox nehmen und die Kunden, die Client-Apps, die Firewall, die Serviceschicht, die Datenbank und sogar die Entwickler darin platzieren, müssen Sie als Architekt überlegen, wie diese riesige Systembox hergestellt werden soll arbeiten gut .

Der genaue Unterschied zwischen "Design" und "Architektur" ist etwas subjektiv und es gibt einige Überschneidungen. Dies ist jedoch der Unterschied, wie ich es verstehe:

Architektur befasst sich mit Konzepten auf hoher Ebene. Wer sind die Akteure im System? Was sind die Hauptobjekte und welche sind für was verantwortlich? Wenn ich an Architektur denke, denke ich an Visio, nicht an Code.

Beispielsweise verfügt ein Ereignissystem möglicherweise über einen Ereignismanager, der eingehende Ereignisse akzeptiert und an Ereignishandler weiterleitet. Die Idee von Threads, asynchronen und synchronen Konzepten und anderen Konzepten auf niedrigerer Ebene kommt hier nicht ins Spiel. MVC ist ein weiteres Beispiel: Auf der hohen Ebene der Interaktion der drei Teile werden keine spezifischen Details angegeben, sondern nur, dass drei verschiedene Probleme von verschiedenen Codepaketen behandelt werden.

Das Entwerfen umfasst das Prototyping, das Skizzieren von Code-Schnittstellen, Code-Skeletten usw. Es bewegt sich zwischen der abstrakten Architektur und der Arbeit mit einfachen "Code-Affen".

In einem Ereignis-Framework könnte der Entwurf "Ein Ereignis verwendet diese Schnittstelle" und "Es gibt einen Thread-Pool, den der Ereignis-Manager zum Versenden von Ereignissen an Worker verwendet" anzeigen. Ein Entwurf für MVC könnte "Ruhezustand für das Modell, Feder für den Controller und GWT für die Ansicht verwenden" sein.

Wenn ich Entwurfsarbeiten mache, skizziere ich Schnittstellen und Codeskelette und übergebe die Ergebnisse an Programmierer. Manchmal bin ich dieser Programmierer. Aber es sind zwei getrennte Phasen, und beide existieren eher im Hinblick auf den Beton als auf die Architektur.

Wenn Sie den Architekturhut aufsetzen , müssen Sie sich vom Code klar werden und an Objekte auf einem Whiteboard denken. Denken Sie an Objekte, Pakete, Frameworks und den Nachrichtenfluss zwischen ihnen. Wenn Sie nur an eine Codezeile denken, machen Sie es falsch. Lassen Sie sich nicht in etwas wie "Oh, diese Nachricht könnte ein String sein, oder verwenden Sie SOAP oder was auch immer." Auf dieser Ebene ist die Tatsache, dass Kommunikation stattfindet, ausreichend. Details sind irrelevant.

Wenn ich hier etwas hinzufügen kann , ist es das: Denken Sie nicht an Code . Überhaupt.

Überlegen Sie nicht, wie Sie den Code schreiben, um etwas zu erreichen, sondern welche Methode am besten geeignet ist, um dies zu erreichen. Ihre Beschreibung der zu erledigenden Aufgaben sollte sprachunabhängig sein , sodass Sie über Entwurfsmuster - eine gemeinsame "Sprache" von Benutzern verschiedener Programmiersprachen - sprechen, um zu besprechen, wie Sie fortfahren können.

Weitere architektonische Fragen für Ihren speziellen Anwendungsfall lauten meiner Meinung nach:

• Warum benutzt du MVC? Ist es alles, was du weißt? Gibt es bessere Muster? Warum?
• Welches Framework verwenden Sie und warum ?
• Wie skalierst du? Nicht in Bezug auf den Code, denn das spielt noch keine Rolle. Wie werden die Bedingungen sein, um horizontal zu skalieren? Welchen Service (AWS) werden Sie dazu verwenden?
• Wie wird die Authentifizierung durchgeführt? Nicht codebezogen: Werden Sie bei jeder Anforderung ein zufälliges, eindeutiges Token generieren und es mit dem erwarteten Token abgleichen lassen? Überlegen Sie nicht, wie Sie dies im Code tun werden. Überlegen Sie, warum Sie dies tun - denn dies kann in praktisch jeder Web-Sprache erfolgen.

Sprechen Sie grundsätzlich überhaupt nicht über Code. Auch wenn Sie nicht wissen, wie man etwas macht, wenn es einen Willen gibt, gibt es einen Weg . Überlegen Sie sich, wie die Puzzleteile am besten zusammenpassen, bevor Sie sich Gedanken darüber machen, wie sie tatsächlich zusammengesetzt werden.

Denken Sie an alle Operationen (dh Anwendungsfälle), die Ihr System ausführen kann. Dokumentieren Sie für jeden Vorgang, was in Bezug auf Ihre Geschäftsdomäne für jeden Vorgang geschieht. Sie sollten nur in Bezug auf Ihre Problemdomäne sprechen und keine Implementierungsdetails beschreiben. Zeichnen Sie einen großen Block und nennen Sie ihn System. Die Kombination dieses "großen Blocks" und der Operationsbeschreibungen ist die Systemarchitektur auf höchster Ebene.

Diese Architektur auf hoher Ebene bietet zwar einen vernünftigen Ausgangspunkt, ist jedoch für die Erstellung eines tatsächlichen Systems nicht von großem Wert. Sie müssen eine Detailebene herunterfahren, um daraus eine nützliche Architektur zu machen.

Sie folgen also der gleichen allgemeinen Idee wie beim "Big Block" -Ansatz, nur dass Sie mit dem Hinzufügen von "Unterblöcken" beginnen, die für die Ausführung der einzelnen Vorgänge erforderlich sind. Diese "Unterblöcke" werden häufig als Domänenklassen oder -module bezeichnet. Diese lassen sich anhand Ihrer Operationsbeschreibungen (aus dem Big-Block-Ansatz) und Zeichnungssequenzdiagrammen leicht identifizieren. Sie werden Domänenklassen genannt, da sie keine "echten" Klassen sein sollen, sondern Ihr System in Bezug auf die Problemdomäne Ihres Systems beschreiben sollen.

Das Endergebnis der Erstellung des gesamten Sequenzdiagramms und der Identifizierung aller "Unterblöcke" ist, dass Sie jetzt eine Liste der Domänenklassen und ihrer Operationslisten haben. Dies führt normalerweise zu einer ziemlich brauchbaren Software-Architektur, in der jeder der "Unterblöcke" / Module an verschiedene Entwickler verteilt werden kann, um sie zu entwerfen und zu implementieren.

Wenn Sie es so lassen, wie es ist, werden Ihre Designer natürlich viel Interaktion miteinander haben, um die Schnittstellen zwischen den Modulen zu definieren. Somit kann der Architekt auch entscheiden, welche spezifischen Schnittstellenmechanismen und Datentypen zwischen den Modulen verwendet werden sollen.

Außerdem werden einige "Unterblöcke" unter der Haube immer noch sehr kompliziert sein. Daher ist möglicherweise eine weitere Iteration des "Unterblock" -Ansatzes erforderlich, diesmal jedoch nur für eines der neu identifizierten Module.

Schließlich kann es einige spezifische Muster / Einschränkungen zwischen Schnittstellen geben, an die sich das System halten soll (z. B. Ereignisrückrufe im Vergleich zu direkten Methodenaufrufen), sodass diese Entscheidungen im Architekturentwurf besprochen werden müssen. Außerdem kann es "allgemeine" Module geben, die vom Architekten von jedem verwendet werden sollen.

Als Entwickler sind Sie wahrscheinlich daran gewöhnt, Lösungen bereitzustellen. Das ist eine sehr gute Denkweise, kann Sie aber beim Denken über Architektur behindern.

Ich finde, dass es hilfreich ist, das Problem zu beschreiben, das Sie zuerst zu lösen versuchen. Was sind die Anforderungen? Was sind die Einschränkungen? Können Sie mit Stakeholdern sprechen, um diese Anforderungen herauszufinden?

Es kann hilfreich sein, wenn Sie auch Ihre eigenen Entwurfsziele beschreiben können. Muss Ihre Lösung skaliert werden oder ist ein Design für einen einzelnen Benutzer ausreichend? Wie lange muss Ihre Lösung gültig bleiben? Handelt es sich um eine einmalige Lösung oder um eine langfristige Infrastrukturlösung? Vielleicht auch wichtig: Was sind die akzeptierten Grenzen Ihrer Architektur?

Und da dies eine Lernerfahrung ist, haben Sie keine Angst, Fragen zu stellen, auch wenn sie albern sind.