it-swarm.com.de

So vermeiden Sie Zeitverschwendung beim Entwerfen von Architektur

Ich habe vor kurzem mein Studium abgeschlossen und meine Arbeit als Programmierer aufgenommen. Ich finde es nicht so schwer, "technische" Probleme zu lösen oder mit Dingen zu debuggen, von denen ich sagen würde, dass sie eine Lösung haben.

Aber es scheint eine Klasse von Problemen zu geben, die nicht eine offensichtliche Lösung haben - Dinge wie Softwarearchitektur. Diese Dinge verwirren mich und bereiten mir große Sorgen.

Ich verbringe Stunden damit, zu entscheiden, wie ich meine Programme und Systeme "entwerfen" soll. Zum Beispiel - teile ich diese Logik in 1 oder 2 Klassen auf, wie benenne ich die Klassen, sollte ich diese privat oder öffentlich machen usw. Diese Art von Fragen nehmen so viel Zeit in Anspruch und es frustriert mich sehr. Ich möchte nur das Programm erstellen - Architektur verdammt noch mal.

Wie komme ich schneller durch die Architekturphase und in die Codierungs- und Debugging-Phase, die mir Spaß macht?

53
JRG

Perfekt ist der Feind des Guten.

Das heißt, Sie sollten keine Ecken schneiden. Das Software-Design wird länger anhaltende Auswirkungen haben und Ihnen (und Ihren Kollegen) in Zukunft jede Menge Zeit und Mühe sparen. Es wird länger dauern, bis alles richtig ist. Die meiste Zeit verbrachte ich mit dem Programmieren nicht Hämmern auf einer Tastatur, aber mit einem Whiteboard, um herauszufinden, wie man ein Problem löst.

Aber Sie sollten sich auch keine Sorgen um Perfektion machen. Wenn zwei Entwürfe zu einer Pattsituation führen, bedeutet dies, dass sie wahrscheinlich ungefähr die gleiche Güte haben. Geh einfach mit einem. Es ist nicht so, dass Sie nichts ändern können, wenn Sie die Fehler in diesem Design herausgefunden haben.

(Und hoffentlich hilft es auch, wenn Sie herausfinden, dass es nicht nur einen Weg gibt, technische Probleme zu debuggen/zu lösen.)

59
Telastyn

Bei einfachen und kleinen Programmen (z. B. mit weniger als zehntausend Zeilen Quellcode) können Sie diese beim Schreiben des Codes erstellen. Wenn Sie einen iterative und inkrementelle Entwicklung Ansatz wählen, treffen Sie schrittweise architektonische Entscheidungen: Schreiben Sie also einige Dutzend Codezeilen (Hinzufügen einer einzelnen Mikrofunktion), verbessern Sie diese, bis keine Warnungen mehr von Ihrem Compiler zurückkehren, testen Sie dies in Ihrem Debugger und wiederholen Sie den Vorgang.

teile ich diese Logik in 1 oder 2 Klassen auf, wie benenne ich die Klassen, sollte ich diese privat oder öffentlich machen usw. Diese Art von Fragen nimmt so viel Zeit in Anspruch

Sie sollten nicht. Und sie sind für ein kleines Programm nicht so wichtig (weil kleine, einfache Programme leichter zu verbessern sind, zB um Namen zu ändern, etc ...). Sie müssen nur konsistent sein und die Lesbarkeit Ihres Quellcodes priorisieren. Möglicherweise müssen Sie von Zeit zu Zeit leicht Refactor einige kleine Teile Ihres Programms (und das ist nicht eine große Sache).

Vergleichen Sie dies mit vielen freier Software Projekten (auch großen wie dem Linux-Kernel). Die Entwickler haben in der Anfangsphase keine nennenswerten Anstrengungen unternommen, um "zu architektonisieren". ML wird in freier Software fast nie verwendet . Außerdem lernen Sie einiges, indem Sie den Quellcode mehrerer freier Softwareprojekte studieren.

Als Neuling arbeiten Sie entweder an einem großen Softwareprojekt in einem Team, in dem Sie einfach dem leitenden Entwickler vertrauen können (der Architekturentscheidungen trifft), oder Sie arbeiten alleine an kleinen Projekten (normalerweise weniger als ein paar Dutzend Tausend) Zeilen des Quellcodes). Im letzteren Fall treffen Sie inkrementelle Architekturentscheidungen und überarbeiten Ihre Anwendung von Zeit zu Zeit. Danach entwickelt sich das "Architekturdesign" auf natürliche Weise weiter.

Wie kann ich schneller durch die Architekturphase und in die Codierungs- und Debugging-Phase gelangen, die mir Spaß macht?

Bei kleinen Softwareprojekten, die weniger als ein Jahr Arbeit in Anspruch nehmen, ist es sehr einfach: Architektur nicht zu betreiben. Nehmen Sie sich vielleicht eine halbe Stunde Zeit für das Brainstorming Design. Beginnen Sie dann mit dem Schreiben von Code mit einem iterative und inkrementelle Entwicklung Ansatz: Schreiben Sie ein paar Dutzend Zeilen, kompilieren Sie ihn (mit aktivierten Warnungen und Debug-Informationen, z. B. g++ -Wall -Wextra -g mit GCC für C++), bis Sie keine Warnungen mehr erhalten (und übergeben Sie diese in einem einfachen statischen Quellcode-Analysator, falls Sie einen haben, z. B. clang-analyzer ), testen Sie diesen Code mit einem Debugger , übergeben Sie ihn an Ihre Versionskontrolle (zB git =), spülen und wiederholen. Vermeiden Sie jedoch unbedingt technische Schulden : Wenn etwas schlecht riecht, arbeiten Sie (durch Umgestaltung und Neuimplementierung), um es zu verbessern.

Andererseits beinhaltet die Architekturarbeit in einer Teamumgebung die erste Diskussion, um die Verantwortung jedes Teammitglieds zu definieren. Diese Diskussion wird vom leitenden Entwickler (der kein Neuling ist) geleitet. Lesen Sie mehr über agile Softwareentwicklung und The Mythical Man-Month .

Ich möchte nur das Programm erstellen, die Architektur wird gestaut.

Hervorragende Intuition (zumindest für kleine Projekte). Denken Sie also ein paar Minuten über Ihr Programm nach und beginnen Sie mit dem Codieren mit einem iterative und inkrementelle Entwicklung Ansatz: Codieren Sie ein paar Dutzend Zeilen und stellen Sie sicher, dass sie gut funktionieren, und wiederholen Sie dann. Studieren Sie vorher den Quellcode (und beobachten Sie die Architektur) ähnlicher freier Softwareprojekte und führen Sie im Allgemeinen einige bibliografische Arbeiten und Recherchen durch.

Denken Sie in einigen Fällen an einen Metaprogrammierung Ansatz: Es gibt Situationen, in denen Sie generieren eine "Quelldatei" ( Beispiele hierfür sind Parser-Generatoren wie Bison , Klebercode-Generatoren wie SWIG , Google protobuf und manchmal Vielleicht möchten Sie ein einfaches Skript schreiben - oder einen generischen Präprozessor wie GPP - verwenden, um einen Teil Ihres C++ oder Java) auszugeben = Code, um wiederholte Codierung zu vermeiden).

PS. Ich bin ein Forschungsingenieur, habe einen Doktortitel in Informatik und 40 Jahre Erfahrung und habe nie "Architektur" gemacht, wie Ihre Frage nahelegt, während ich erfolgreich an mehreren mittelgroßen und einigen großen Projekten gearbeitet habe (dem GCC-Compiler selbst) ). Für mich ist "Architektur" nur die Planungsphase der Arbeit der nächsten Tage oder Wochen (und das mache ich normalerweise beim Träumen oder Schlafen und sicherlich ohne Computer und normalerweise ohne Bleistift). Außerdem entwerfe ich beim Schreiben von Forschungsstipendien irgendwie und unvollständig eine Architektur.

NB: Einige Softwareprojekte benötigen viel mehr Architektur als andere. Wenn Sie beispielsweise das Steuerungssystem eines künstlichen Herzens oder eines neurochirurgischen Roboters schreiben, arbeiten Sie nicht auf die gleiche Weise wie beim Schreiben einer durchschnittlichen Mobiltelefonanwendung. Siehe auch Norvigs Bring dir das Programmieren in zehn Jahren bei Seite.

39

Es gibt drei Mottos, an die ich gerne denke.

  • "Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher"

    Um Ihr Beispiel für "eine Klasse oder zwei?" Zu nehmen, würde ich fragen: "Was ist die einfachere Lösung?"

  • "Keine offensichtlichen Fehler" versus "Offensichtlich keine Fehler"

    Letzteres ist vorzuziehen!

    Und das ist der Grund, warum es einfach sein muss, d. H. Damit Sie darüber nachdenken können. Eine große Klasse ist möglicherweise zu groß und zu kompliziert, um darüber nachzudenken. In diesem Fall teilen Sie sie in mehrere kleinere Klassen auf, in denen Sie sagen können: "Jede Klasse ist klein und tut, was sie verspricht - und ihre Schnittstellen sind einfach und sie werden auf die richtige Weise kombiniert. "

    1. Der Code sollte theoretisch ausgeführt werden (d. H. In Ihrem Kopf).
    2. Wenn es in der Praxis nicht funktioniert, können Sie es debuggen, bis die Praxis der Theorie entspricht.

    Ein Anfänger kümmert sich manchmal nicht um Schritt 1, dh er läuft in Ihrem Kopf (z. B. weil es zu kompliziert ist) - aber in diesem Fall läuft er nur "aus Versehen" und nicht "theoretisch", möglicherweise weil Sie es getan haben. Ich habe es nicht genug getestet, um nicht offensichtliche Fehler zu finden.

  • Gall'sches Gesetz

    Dies ist a.k.a. "Refactor".

    In der Praxis bedeutet dies:

    1. Beginnen Sie mit einem [ny] einfachen System, das funktioniert
    2. Jetzt ist es Zeit, eine neue Funktion hinzuzufügen
    3. Überarbeiten Sie das vorhandene System so, dass (d. H. Bis) die neue Funktion einfach hinzugefügt werden kann
    4. Fügen Sie die neue Funktion hinzu

    5. ... und wie oben wiederholen

    Dies entspricht Mottos wie YAGNI, d. H. Nicht umgestalten (Sorgen um die Architektur), bevor Sie ... sondern die richtige Architektur rechtzeitig erstellen müssen, d. H. Wenn Sie sie für einen bestimmten Zweck benötigen.

9
ChrisW

Sie können mit der minimalen Anzahl von Abstraktionen beginnen, die Sie benötigen. Zum Beispiel eine Personenklasse in einer Datei. Wenn Sie nun Code und Funktionen hinzufügen, sehen Sie Dinge, die in eine andere Abstraktion verschoben werden müssen. Zum Beispiel sagt Ihnen das Prinzip der Einzelverantwortung (S of SOLID), dass Sie keine Methoden zur Adressanalyse in der Person-Klasse haben sollen. Sie wissen jetzt, dass Sie eine Adressklasse benötigen.

Es ist jedoch immer gut, sich etwas Zeit zu nehmen, um darüber nachzudenken, wie "minimale Anzahl von Abstraktionen" für Ihr System aussieht. Beginnen Sie mit einer ausreichend guten Architektur und verbessern Sie diese im Laufe der Zeit.

edit: @Basile answer gibt ein Beispiel dafür, wie Sie Ihre Minimalarchitektur iterieren und verbessern können.

6
sul4bh

Zeit, die für das Nachdenken über die Architektur eines Systems aufgewendet wird, ist keine Zeitverschwendung.

Ich glaube, Ihre Frage könnte wie folgt umformuliert werden: "Wie kann ich architektonische Entscheidungen effizienter treffen?".

Meine kurze Antwort darauf wäre: Sie müssen die Grundprinzipien entdecken, die es Ihnen ermöglichen, zuverlässig und effizient Entscheidungen zu treffen, und dann müssen Sie tatsächlich eine echte Software entwickeln. Dies wird ein langer Weg sein, um Wissen, Versuch und Irrtum und persönliche Entwicklung zu suchen.

- -

Und für eine längere Antwort ...

Ich sollte zuerst die Konzepte klären: Ich benutze das Wort Architektur, um die Struktur eines komplexen Softwaresystems zu beschreiben, wenn ich mit Prozessen, Diensten, APIs und Datenbanken arbeite. Ich benutze das Wort design, um die Struktur von nur einem Teil eines komplexeren Systems zu beschreiben, wenn ich mit Klassen, Funktionen und Bibliotheken arbeite. Dies sind meine Definitionen, einige Leute haben unterschiedliche Definitionen. Aber in diesem Zusammenhang glaube ich, dass Sie über Design sprechen.

Ich denke, es gibt drei wichtige Dinge, die bei der Diskussion dieses Themas zu beachten sind:

  • architektur und Design existieren, ohne dass sie explizit über Diagramme oder Dokumentationen beschrieben werden, auch ohne dass sie von einem Team oder einer Person (einem Architekten) gepflegt werden. Jedes System hat eine intrinsische Architektur und ein intrinsisches Design, das nachträglich beschrieben werden kann.

  • softwareentwicklung programmiert nicht, sondern im Laufe der Zeit. Ich mache diese Unterscheidung, weil ich denke, dass dies einer der größten blinden Flecken für Leute ist, die in die Branche kommen (ich selbst zu einem bestimmten Zeitpunkt eingeschlossen). Dies bedeutet, dass die Arbeit an einem realen Softwaresystem im Vergleich zu Universitätsprojekten oder persönlichen Nebenprojekten exponentiell komplexer ist, da jede architektonische Entscheidung mit der Zeit einen großen Einfluss auf die Entwicklung des Systems haben wird. Ihre Entscheidungen werden Sie jetzt garantiert verfolgen.

  • da Architektur und Design instrumentell existieren und die Codebasis eine lebendige Sache ist, die sich mit der Zeit weiterentwickelt, müssen sich auch Architektur und Design weiterentwickeln. Sie entwickeln sich entweder kontrolliert durch bewusste Entscheidungen, die zum richtigen Zeitpunkt getroffen werden, oder sie entwickeln sich chaotisch, angetrieben von der Kodierung. Dies ist wichtig zu verstehen, da dies bedeutet, dass der traditionelle Ansatz von "Architekt zuerst und Code zuerst schreiben" fehlerhaft ist. Wenn Sie ein Projekt von Grund auf neu starten, müssen natürlich einige Architektur- und Designarbeiten im Voraus durchgeführt werden. Abgesehen davon müssen bei der Entwicklung des Systems noch viele architektonische und gestalterische Entscheidungen getroffen werden.

Um das oben Gesagte weiter zu destillieren, ist es sehr wichtig zu wissen, dass Sie beim Schreiben von Code bewusst oder unbewusst Entwurfsentscheidungen treffen. Sie sollten sich bemühen, möglichst viele dieser Entscheidungen bewusst und kritisch zu treffen, da jede leicht getroffene Entscheidung einen großen Einfluss auf die zukünftige Arbeit haben kann (dieser Einfluss äußert sich normalerweise darin, dass es sehr schwierig wird, die Codebasis zu ändern, um Fehler zu beheben oder Funktionen zu implementieren). Robert C. Martin illustriert dies wunderschön mit Daten in seinem Buch "Clean Architecture" (das ich übrigens sehr empfehlen kann).

Nun, da wir wissen, warum Architektur und Design wichtig sind, was sind die Grundprinzipien, die uns einen angemessenen Rahmen für eine gute Entscheidungsfindung geben können? Ich hatte diese Frage früher in meiner Karriere, ich hatte das Gefühl, dass etwas fehlt In meinem Toolset ist, wusste aber nicht was, wusste nicht, wie ich es beschreiben oder danach suchen sollte. Ich werde einige dieser Prinzipien teilen, die ich mit der Zeit entdeckt habe, und ich hoffe, sie werden Ihr Leben etwas einfacher machen:

  • eine Reihe sehr einfacher, aber leistungsstarker Codierungstricks kann durch Lesen von Martin Fowlers Buch "Refactoring: Verbesserung des Designs vorhandenen Codes" aufgegriffen werden. Es gibt zu viele, um sie hier aufzulisten, aber dies sind sehr einfache Entscheidungen zur Codierungszeit, die Sie treffen können, um Ihre Codestruktur erheblich zu verbessern und die Entwurfsentscheidungen zu treffen. Das Buch ist auch ein gutes Beispiel für die Integration von Unit-Tests in Ihren persönlichen Workflow und für das Schreiben von testbarem Code.

  • speziell für OOP sollten Sie sich die SOLID-Prinzipien ansehen. Sie sind ein bisschen abstrakt und schwer in den Kopf zu bekommen, aber sehr mächtig. Ich schlage vor, Sie beginnen mit den ersten 2, um schnell den größten Nutzen zu erzielen:

Prinzip der Einzelverantwortung : Eine Klasse sollte nur eine Einzelverantwortung haben (dh nur Änderungen an einem Teil der Softwarespezifikation sollten die Spezifikation der Software beeinflussen können Klasse).

Open/Closed-Prinzip : "Software-Entitäten ... sollten zur Erweiterung geöffnet, aber zur Änderung geschlossen sein."

  • das Konzept von Zusammensetzung über Vererbung

    das Prinzip, dass Klassen ein polymorphes Verhalten und eine Wiederverwendung von Code durch ihre Zusammensetzung erreichen sollten (indem sie Instanzen anderer Klassen enthalten, die die gewünschte Funktionalität implementieren), anstatt von einer Basis- oder Elternklasse zu erben.

  • die Konzepte von Kopplung ("Grad der gegenseitigen Abhängigkeit zwischen Softwaremodulen") und Kohäsion ("Grad der Zugehörigkeit der Elemente innerhalb eines Moduls")
  • das DRY (Don't Repeat Yourself) -Konzept
  • das Befehls-/Abfragetrennungskonzept ("Jede Methode sollte entweder ein Befehl sein, der eine Aktion ausführt, oder eine Abfrage, die Daten an den Aufrufer zurückgibt, aber nicht beide")
  • das Konzept von Stateful versus Stateless System (meine Faustregel lautet: Vermeiden Sie den Umgang mit State; bauen Sie so viel Stateeless-Systeme wie möglich).

Dies sind natürlich nur Konzepte, keine Regeln. Der erste Schritt besteht darin, sie zu verstehen und sich ihrer bewusst zu sein. Als nächstes werden sie tatsächlich in der Praxis eingesetzt und Erfahrungen aufgebaut, wann Sie ihnen folgen sollten und wann nicht. Und dann gibt es einen kontinuierlichen Prozess, in dem Sie Ihr Verständnis dieser Konzepte, ihrer negativen Seiten und ihrer komplexen Wechselwirkungen miteinander verfeinern.

Ich denke, der wertvollste Rat, den ich Ihnen geben kann, ist: Haben Sie Geduld mit sich. Sie haben gerade einen langen, aber erfüllenden Weg eingeschlagen. Übe und experimentiere weiter, beachte, was funktioniert und was nicht und du wirst erst mit der Zeit besser.

5
Mihai Coman

Das meiste, was Sie beschreiben, ist keine wirklich (wichtige) Architektur - gute Benennung und gutes Klassendesign sollten für Sie selbstverständlich sein. Dies wird einfach besser, je mehr Sie codieren. Am hilfreichsten für solche Probleme ist normalerweise die Paarprogrammierung. Sie hilft, solche Probleme zu klären, und hilft Ihnen dabei, effizient zu lernen.

Wo Architektur notwendig ist, ist VOR dem Projekt:

  1. Sammeln Sie die genauen Anforderungen und nicht funktionalen Anforderungen (wie viele Anfragen/Sekunde muss ich unterstützen?). Jedes Missmatch in dieser Phase führt zur Codierung der Hölle - die Integration verpasster Ideen nachträglich ist zeitaufwändig, nervig und manchmal unmöglich. Ich weiß, dass dies als Codierung keinen Spaß macht, aber es macht noch weniger Spaß, den Code dazu zu bringen, etwas zu tun, für das er nicht entwickelt wurde.

  2. Definieren Sie gegebenenfalls die begrenzten Kontexte Ihres Systems und stellen Sie sicher, dass Ihr Wortschatz klar ist. Wenn das Unternehmen beispielsweise über "Frobbels" spricht, stellen Sie sicher, dass Sie Klassen/Schnittstellen usw. mit "*** Frobbels" benennen. Klingt trivial, aber wenn Sie über Workflows sprechen, während das Unternehmen über Vorgänge spricht, wird das Übersetzen sehr schnell ärgerlich.

  3. Wenn Sie mit mehreren Personen/Teams zusammenarbeiten, beschreiben Sie Ihre Schnittstellen frühzeitig und stellen Sie sicher, dass alle Annahmen und Probleme von allen verstanden werden. Wenn Sie keinen gemeinsamen Kontext haben, macht die Integration "Spaß". Z.B. Sie bauen einen Bananenbildgenerator, aber Ihr Frontend-Entwickler benötigt einen Apple Bildgenerator. Oder Sie bauen etwas, das 100 Anfragen/Sekunde beantworten kann, aber 10000 U/s benötigt.

Hinweis: Dies wird stark von meiner Arbeit an einer Microservice-Architektur beeinflusst. Wie die Serves intern erstellt werden, kann auch entworfen werden - aber meistens ist es viel weniger wichtig, als das Gesamtbild richtig zu machen.

1
Christian Sauer

Ich werde keine Reihe von Begriffen und Abkürzungen auf Sie werfen (von denen die meisten von der Mehrheit der Programmierer/Softwareentwickler kaum akzeptiert werden). Beachten Sie stattdessen Folgendes:

  1. Sie lernen - Sie verschwenden keine Zeit, Sie probieren verschiedene Ansätze aus und lernen, was funktioniert. Sie können dies tun, ohne viel im Voraus zu planen, indem Sie sich mit der ersten Lösung, die Ihnen in den Sinn kommt, auf ein Problem einlassen und es ändern, wenn es nicht funktioniert. Wenn es gut funktioniert, großartig! Sie haben eine einfache Lösung für ein Problem gefunden. Einfache Lösungen sind in Ordnung, wenn sie gut funktionieren, und manchmal sind sie gut genug.

  2. Alles ist ein Kompromiss - Sie können dasselbe System auf viele verschiedene Arten entwerfen und dabei Zeit und Raum, Komplexität und Flexibilität, Abstraktion und Lesbarkeit oder einen von vielen möglichen Kompromissen in Einklang bringen. Keine Lösung ist in jeder Hinsicht perfekt und keine Regel ist ohne Ausnahmen in der Softwareentwicklung. Wer dir etwas anderes sagt, ist entweder naiv oder verkauft etwas.

  3. Als Absolvent vor kurzem kann das Codieren und Debuggen sehr aufregend sein, aber dies wird mit der Zeit nachlassen, und die Fähigkeiten, die Sie jetzt lernen, werden Ihnen dabei gute Dienste leisten.

  4. Ich würde argumentieren, dass das Erstellen von Software mehr Kunst/Handwerk als Technik ist. Bei großartiger Kunst geht es nicht nur um den einzelnen Pinselstrich, sondern auch um Entscheidungen und Kompromisse auf hoher Ebene, die der Künstler/Handwerker getroffen hat.

1
idoby

Ich werde versuchen, diese Frage unter dem Gesichtspunkt der Webentwicklung zu beantworten (dh aus einem Bereich, in dem sich die Menschen viel mit Architektur auseinandersetzen). Ich werde zunächst erklären, warum sich Menschen für Architektur interessieren, und dann Möglichkeiten skizzieren, wie man schneller am Architekturteil vorbeikommt.

Architektur macht zwei Dinge für Ihren Code:

  1. Es macht es einfacher, Ihren Code für Sie und andere zu verstehen.
  2. Es hilft Ihnen dabei, Ihren Code so zu strukturieren, dass er einfacher erweitert und integriert werden kann.

Ein Codestil erleichtert das Lesen eines bestimmten Teils des Codes, indem er Ihnen Konventionen zur Verfügung stellt, die Sie erkennen und zum Navigieren verwenden können. Ebenso hilft Ihnen eine gute Architektur zu identifizieren, wo Sie tatsächlich den Code finden, der eine bestimmte Funktion behandelt. In den meisten Webprojekten hängt die Architektur beispielsweise eng mit der Sortierung von Ordnern und Dateien zusammen. Auf der anderen Seite sollte eine gute Architektur Ihnen tatsächlich helfen, weniger über den Code nachzudenken, da sie bereits einen intuitiven Ort haben sollte, zu dem jeder Code gehört.

Darüber hinaus bietet eine gute Architektur eine Abkürzung, um viele der Fallstricke zu vermeiden, die dazu führen könnten, dass Ihr Code nicht einfach verwendet werden kann. Wenn Sie eine Architekturentscheidung treffen, sollte eine Konvention eingerichtet werden, die Ihnen hilft, weniger über das Schreiben von Code nachzudenken.

Nun der Teil, für den Sie tatsächlich hier sind:

Was können Sie schneller durch den Architekturteil bekommen:

  1. Tu es nicht

Wie viele Antworten bereits darauf hingewiesen haben. Fragen Sie sich zuerst, ob Sie tatsächlich Architektur benötigen. Wenn Sie nicht viel Code haben (und Sie können ziemlich sicher sein, dass das Projekt in naher Zukunft nicht wachsen wird), können Sie einfach den Architekturteil überspringen und etwas zusammenschustern, das einfach funktioniert. Wenn Sie jedoch zu Beginn Ihrer Karriere stehen, würde ich die Gelegenheit nutzen, um zu üben, wann immer Sie können. Irgendwann werden Sie größere Projekte durchführen, und an diesem Punkt ist es wahrscheinlich zu spät, um etwas zu lernen.

Was können Sie tun, um die Architektur weniger schmerzhaft zu machen:

  1. Mach es früh
  2. Stehlen
  3. Lernen/dabei bleiben
  4. Übertreibe es nicht

Die Entscheidung für eine Architektur sollte ein früher Teil des Planungsprozesses sein. Sobald Sie eine Vorstellung davon haben, welche Art von App/Programm/Website Sie erstellen werden, sollten Sie darüber nachdenken, welche Art von Architektur dies unterstützen würde.

An diesem Punkt ist es Zeit, schamlos zu stehlen. Es gibt eine Menge Literatur darüber, wie eine Programmarchitektur richtig eingerichtet werden kann, und diese vorhandenen Architekturprototypen decken eine erstaunliche Anzahl von Anwendungsfällen ab. Sie sollten einen groben Überblick darüber erhalten, welche Art von Architekturen es gibt, auch wenn Sie nicht wissen, wie Sie sie implementieren sollen.

Wenn Sie sich für eine Art Architektur entschieden haben, bleiben Sie dabei. Zum größten Teil sollte die Architekturentscheidung intuitiv sein und nur wenige Sekunden nach der Ersteinrichtung dauern. Vieles davon hängt von der Erfahrung ab.

Zum Schluss überdenken Sie nichts. Sie geben das Beispiel, ob etwas öffentlich oder privat sein sollte, und die Wahrheit ist, dass es wahrscheinlich egal ist, ob Sie alles öffentlich machen. Ja, Sie sollten es nicht so machen, und viele dieser kleinen Fehler werden sich nach einiger Zeit häufen, aber am Ende des Tages wird es wahrscheinlich auch Ihr Projekt nicht töten. Erstellen Sie in erster Linie funktionierende Software!

(PS: Dieser letzte Satz ist keine Entschuldigung dafür, faul zu sein. Das Priorisieren von funktionierender Software bedeutet nicht, dass Sie eines Tages keine gute Codierung lernen müssen.)

1
TheSexyMenhir

Die Antwort ist sehr einfach,

  • Erstellen Sie einen Prototyp (Zeitbox)
  • Refactor (verbringen Sie so viel Zeit, wie Sie möchten oder haben, basierend auf einer Vielzahl von Faktoren)

Wenn Sie einen Prototyp erstellen, sollte der Fokus auf einem minimal lebensfähigen Produkt liegen, und wenn Sie ein Refactoring durchführen, sollte der Fokus darauf liegen, Ihr Projekt oder Ihre Lösung skalierbar zu machen.

1
Mathematics

Wie kann ich schneller durch die Architekturphase und in die Codierungs- und Debugging-Phase gelangen, die mir Spaß macht?

Indem Sie diese Aufgabe an Ihre erfahreneren Mitarbeiter weiterleiten (oder um Hilfe bitten).

Ihnen fehlt einfach die Erfahrung, um solche Entscheidungen schnell zu treffen. Uni hat dir einen schönen theoretischen Hintergrund gegeben, aber es bringt dich nur zu einer Startlinie. Es gibt keine andere Möglichkeit, eine bestimmte Architektur in einer bestimmten Situation zu beurteilen, als zu wissen, wie sich ähnliche Architekturen in der Vergangenheit in ähnlichen Situationen verhalten haben.

Die Arbeit mit Menschen, die besser im Job sind als Sie, ist der schnellste Weg, Dinge zu lernen. Wenn Sie niemanden haben, an den Sie sich wenden können, brauchen Sie einen besseren Job. "Besser" als in "Ihren Bedürfnissen besser entsprechen". Das Bedürfnis nach Wissen und Erfahrung ist in diesem Moment Ihr dringendstes Bedürfnis, wie Ihr Dilemma zeigt. Sie genießen die Codierungs- und Debugging-Phase? Klingt nach einem perfekten Junior. Aber ein Junior braucht die Anleitung eines Senioren. Darum geht es in diesen Stellenbeschreibungen. Fremde im Internet können Ihnen bisher nur helfen, Sie brauchen einen Mentor.

1
Agent_L

Ich sehe einige ernsthafte Probleme mit dieser Frage. Lasst uns beginnen.

So verschwenden Sie keine Zeit mehr mit der Gestaltung von Architekturen

Diese Frage ist eher geladen. Außerdem haben Sie keine design Architektur. Sie Architekt . Architektur und Design sind komplementäre und verwandte Aktivitäten, aber sie sind nicht gleich, auch wenn sie sich überschneiden könnten.

Auf die gleiche Weise, wie es möglich ist, Zeit mit Architektur zu verschwenden (durch Überarchitektur), können Sie auch Zeit mit Überdesign und Übercodierung verschwenden (indem Sie Dinge auf eine Weise codieren, die weitaus komplexer als nötig ist, oder indem Sie dies nicht tun Code für die Dinge, die benötigt werden.)

Die richtige Architektur zielt darauf ab, diese Verschwendung bei der Codierung zu verhindern. Dies geschieht durch Einschränkung, Eingrenzung und Dokumentation der Möglichkeiten, wie ein komplexes System 1) entworfen, 2) codiert und getestet, 3) geliefert, 4) gewartet, 5) nach einem Ausfall wiederhergestellt und 6) endgültig außer Betrieb genommen werden soll.

Ich habe die Erfahrung gemacht, dass Leute, die einfach nur Spaß am Codieren haben, einfach code sind, ohne darüber nachzudenken, wie ein System auf lange Sicht funktionieren und gewartet werden soll, und zum nächsten heiße Kartoffel eine arme Seele zurücklassen, um einen hässlichen Golem zu erhalten.

Aber ich schweife ab...

Dies ist die Sache: Für Systeme, die einfach genug sind, ist die Architektur selbstverständlich und geht von soliden Entwurfs- und Implementierungspraktiken aus.

Nur für große Systeme, an denen eine relativ große Anzahl von Personen oder Software auf Systemebene beteiligt ist, werden sehr komplexe Aufgaben ausgeführt, für die eine explizite Architektur erforderlich ist.

Ich habe vor kurzem mein Studium an der Uni abgeschlossen und angefangen, als Programmierer zu arbeiten. Ich finde es nicht so schwer, "technische" Probleme zu lösen oder Fehler zu beheben. Dinge, von denen ich sagen würde, dass sie eine Lösung haben.

Das ist das Minimum, das für diesen Beruf erforderlich ist, und ich bin froh, dass Sie kein Problem damit haben (ich würde mir Sorgen machen, wenn Sie das tun würden.)

Aber es scheint eine Klasse von Problemen zu geben, für die es keine einzige Lösung gibt

Das ist das A und O unseres Berufs, die Art von Problemen, für die Arbeitgeber bereit sind, unsere (normalerweise) weit überdurchschnittlichen Gehälter zu zahlen.

In der Tat sind Probleme, die es wert sind, gelöst zu werden, diejenigen, die mehr als eine Lösung haben können. Probleme der realen Welt, sie sind so. Und die Welt benötigt unser Fachwissen als Softwareentwickler, um akzeptable Kompromisse zu finden.

- Dinge wie Softwarearchitektur.

Die Architektur der Dinge ist ein unvermeidliches Merkmal eines komplexen Systems, sei es virtuell/Software oder in der konkreten Welt. Jedes System, das arbeitet, Eingaben aufnimmt und Ausgaben erzeugt, wird komplex sein und eine Architektur haben.

Wenn wir Software für solche Systeme entwickeln (ein Bankensystem, ein Stromüberwachungssystem, ein Ticketverkaufssystem usw.), wollen wir eine Software entwickeln, die imitiert die Funktionen und Anforderungen eines solchen Systems.

Wir können es einfach nicht einfach wing it und im Cowboy-Stil codieren. Wir brauchen eine Art Architektur. Dies gilt insbesondere dann, wenn für das Projekt Dutzende von Ingenieuren erforderlich sind, wenn nicht mehr.

Diese Dinge verwirren mich und bereiten mir große Sorgen.

Das ist ok. Es ist kein leichtes Thema zu lernen oder zu lehren, nicht ohne viel Übung.

Ich verbringe Stunden damit, zu entscheiden, wie ich meine Programme und Systeme "entwerfen" soll. Teilen Sie diese Logik beispielsweise in 1 oder 2 Klassen auf, wie benenne ich die Klassen, sollte ich diese privat oder öffentlich machen usw. Diese Art von Fragen nimmt so viel Zeit in Anspruch und frustriert mich sehr. Ich will nur das Programm erstellen, die Architektur ist verdammt.

Leider ist das keine Softwarearchitektur.

Es ist nicht einmal Design, sondern nur Codierung. Ich werde am Ende dieses Beitrags einige Vorschläge machen.

Wie komme ich schneller durch die Architekturphase und in die Codierungs- und Debugging-Phase , die mir Spaß macht ?

Es fällt mir schwer, einen Weg zu finden, dies zu beantworten, denn es ist ziemlich emotional.

Versuchen wir, einen Job zu erledigen, oder versuchen wir nur, die Praxis zu genießen? Es ist großartig, wenn beide ein und dasselbe sind, aber im wirklichen Leben sind sie es oft nicht.

Es ist großartig, Dinge zu tun, die uns Spaß machen, aber in einem so komplexen Beruf wie unserem, sich nur auf das zu konzentrieren, was uns Spaß macht, ist es nicht förderlich, eine fruchtbare Karriere zu haben.

Sie werden nicht weiterkommen, Sie werden nicht reifen oder neues Wissen erwerben.

Es gibt dieses Sprichwort in der Armee: "Umarme das Saugen."

Andere Sätze haben ähnliche Ratschläge. "Wenn es nicht saugt, ist es das nicht wert" und mein Favorit: "Wenn es saugt (und es ist wichtig), mach es, bis es aufhört zu saugen."

Meine Empfehlungen:

Es scheint mir, dass Sie immer noch Schwierigkeiten haben, die Unterschiede zwischen zu verstehen

  1. codierung (wie Sie Ihre Klassen, Module oder was nicht codieren, Namenskonventionen, Zugriffssichtbarkeit, Umfang usw.),

  2. design (wie viele Ebenen, Front-End/Back-End/DB, wie jedes kommuniziert, was wohin geht) und die impliziten Architekturentscheidungen, die sich aus dem Design einfacher Systeme ergeben,

  3. architektur (wie in komplexen Systemen, die Tausende, wenn nicht Hunderttausende von Arbeitsstunden erfordern).

Daher würde ich vorschlagen, dass Sie sich eingehend mit dem ersten Thema (Codierung) befassen, um es auf die nächste Ebene zu bringen.

Code reinigen

Robert "Onkel Bob" Martins "Clean Code" ist ein guter Anfang.

Software-Zusammenhalt

Außerdem würde ich vorschlagen, dass Sie sich mit einer bestimmten objektorientierten Softwaremetrik namens LCOM bzw. LCOM4 vertraut machen.

Es kann ziemlich mathematisch werden und ist nicht kugelsicher, aber Ihr Ziel sollte es sein, empirisch zu verstehen und zu erkennen (oder Augapfel, wenn Sie es wünschen), ob eine Klasse zusammenhängend ist oder ob es keinen Zusammenhalt gibt.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4https://www.computing.dcu.ie/~renaat/ca421 /LCOM.html

Software-Prinzipien

Dies hängt eng mit dem "Single Responsibility Principle" oder SRY zusammen, mit dem wir alle vertraut sein sollten. SRY ist eines der 5 "SOLID" , mit denen wir alle vertraut sein müssen, um die Codierung zu beherrschen.

Während wir uns durch SOLID Prinzipien) bewegen, müssen wir uns auch mit "GRASP" Prinzipien vertraut machen, die regeln oder vielmehr leiten, wie wir Klassen codieren.

Zusätzliche Bücher

Zuletzt würde ich auch Folgendes vorschlagen:

  • "Refactoring" von Martin Fowler und Ken Beck wäre das nächste Buch, das ich in dieser Liste lesen würde.

  • "Design by Contract, by Example" von Richard Mitchell, Jim McKim und Bertrand Meyer (der spätere von Eiffels Ruhm). Dieses Buch ist vergriffen, aber Sie können billige, gebrauchte Exemplare bei Amazon finden.

Auf diese Weise sollten Sie einen guten Überblick darüber erhalten, wie Sie mit dem Codieren und Entwerfen beginnen und mit der Praxis die Softwarearchitektur verschieben und beherrschen (oder zumindest verstehen) können.

Ich bin sicher, dass es andere Fachleute geben wird, die diese Vorschläge hinzufügen, entfernen oder ablehnen. Sie werden andere Vorschläge einbringen, die wahrscheinlich durch ihre eigenen Erfahrungen bestätigt werden.

Ich kann nur Folgendes sagen - es gibt keine Abkürzungen.

Alles Gute.

1
luis.espinal

Hier gibt es viele Informationen und ehrlich gesagt TL; DR. Es gibt eine Hauptsache, von der ich denke, dass die Leute falsch liegen, wenn sie lernen wollen, wie man ein System entwirft: Sie versuchen, darüber in der Reihenfolge nachzudenken, in der die Arbeit erledigt wird. Stattdessen müssen Sie rückwärts arbeiten. Das heißt, das Hauptziel von Design/Architektur besteht darin, das Endergebnis zu bestimmen.

Betrachten Sie als Analogie die Architektur eines Hauses. Ein Architekt stellt sich nicht zunächst Fragen wie: "Wie viele Fenster sollte dieses Haus haben?", "Wo soll der erste Ziegelstein platziert werden?". Diese Implementierungsdetails sind nicht das Design, sondern werden vom Design abgeleitet. Die Architektur beginnt mit einer Vision, vielleicht einer Skizze, wie das fertige Haus aussehen könnte. Ist es ein Einfamilienhaus, eine Maisonette? Ist es ein Luxushaus oder ein leicht erschwingliches? Ebenso hat es wenig mit Architektur zu tun, ob Variablen privat sind und ob Sie eine Klasse aufteilen.

Beginnen Sie zunächst damit, herauszufinden, welche Ziele Ihr Design verfolgt. Ist dies beispielsweise eine einmalige Lösung? Wird es über Jahrzehnte erweitert, überarbeitet und gewartet? Die Antwort darauf zeigt sehr unterschiedliche Designs und das ist der Punkt der Architektur. Sobald Sie herausgefunden haben, was Sie tun müssen, folgen die Details des Designs natürlich. Nicht dass diese Details offensichtlich oder einfach wären, aber es ist der Plan auf hoher Ebene, auf dem diese Entscheidungen basieren.

1
JimmyJames

Es ist ziemlich einfach zu beurteilen, wie viel Zeit Sie für die Architektur einer Software aufwenden sollten, bevor Sie eine Schreib-Kompilierungs-Testschleife erhalten: genug Informationen, um in Ihren Kopf zu passen, und nicht mehr. Es sei denn, das Projekt, an dem Sie arbeiten, schreibt eine strengere Methodik vor. In diesem Fall sollten Sie als Anfänger höchstwahrscheinlich ein Architekturdokument lesen und nicht schreiben.

Was das Benennen von Dingen betrifft, so ist dies für mich Teil des "Schreibens", aber es ist zweifellos ein sehr wichtiger Teil des Programmierens: Zögern Sie nicht, genau darüber nachzudenken, wie Sie Dinge benennen, und überlegen Sie umso mehr, je größer der Umfang des Namens ist.

Das Finden der richtigen Namen, der richtigen Architektur, der richtigen Modularität und der richtigen Abstraktionen ist Teil der Erfahrung, die Sie durch Fehler gewinnen. Im Laufe der Jahre habe ich ungefähr fünf Mal ein Programm geschrieben, das dasselbe tut, und der Code war jedes Mal sehr unterschiedlich, weil jede vergangene Iteration mir Hinweise auf ein besseres Design gab.

0
Kafein