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

Es scheint jedoch eine Reihe von Problemen zu geben, für die es keine offensichtliche Lösung gibt - Dinge wie die Softwarearchitektur. Diese Dinge verwirren mich und bereiten mir große Sorgen.

Ich verbringe Stunden und Stunden damit zu entscheiden, wie ich meine Programme und Systeme "architektonisch" gestalten 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 beanspruchen so viel Zeit und es frustriert mich sehr. Ich möchte nur das Programm erstellen - Architektur, verdammt.

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

Perfekt ist der Feind des Guten.

Das heißt, Sie sollten keine Ecken schneiden. Das Softwaredesign hat eine länger anhaltende Wirkung und spart Ihnen (und Ihren Kollegen) in Zukunft jede Menge Zeit und Mühe. Es wird länger dauern, bis alles in Ordnung ist. Die meiste Zeit des Programmierens wird nicht auf einer Tastatur gespielt, sondern auf 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 dieselbe Güte haben. Geh einfach mit. Es ist nicht so, dass man Dinge nicht ändern kann, wenn man die Fehler in diesem Design herausgefunden hat.

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

Für einfache und kleine Programme (z. B. mit weniger als zehntausend Zeilen Quellcode) können Sie diese beim Schreiben des Codes erstellen. Wenn Sie einen iterativen und inkrementellen Entwicklungsansatz wählen , treffen Sie schrittweise architektonische Entscheidungen: Schreiben Sie ein paar Dutzend Codezeilen (fügen Sie ein einzelnes Mikro-Feature hinzu), und verbessern Sie sie, bis keine Warnungen mehr von Ihrem Compiler zurückkehren. Testen Sie dies in Ihr Debugger und wiederholen.

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 beanspruchen so viel Zeit

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

Vergleichen Sie dies mit vielen freien Softwareprojekten (auch großen wie dem Linux-Kernel). Die Entwickler haben in der Anfangsphase keine nennenswerten Anstrengungen zum "Entwerfen" unternommen. UML wird in freier Software fast nie verwendet . Außerdem lernst du einiges, indem du den Quellcode mehrerer freier Softwareprojekte studierst.

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 (in der Regel weniger als ein paar Dutzendtausend) 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 komme ich schneller durch die Architekturphase und in die Codierungs- und Debugging-Phase, die mir Spaß macht?

Bei kleinen Softwareprojekten, die weniger als ein Jahr dauern, ist es sehr einfach: Mach keine Architektur. Verbringen Sie vielleicht eine halbe Stunde mit dem Brainstorming des gesamten Designs. Beginnen Sie dann mit dem Schreiben von Code mit einem iterativen und inkrementellen Entwicklungsansatz : Schreiben Sie ein paar Dutzend Zeilen, kompilieren Sie ihn (mit allen aktivierten Warnungen und Debug-Informationen, z. B. g++ -Wall -Wextra -gmit GCC für C ++), bis Sie keine Warnungen mehr erhalten (und übergeben Sie ihn in einer einfachen statischen Quelle Code-Analyzer (falls vorhanden, z. B. Clang-Analyzer ), testen Sie diesen Code mit einem Debugger , übergeben Sie ihn an Ihre Versionskontrolle (z. B. git), spülen Sie ihn und wiederholen Sie ihn. Vermeiden Sie jedoch unbedingt technische Schulden: Wenn etwas schlecht riecht, arbeiten Sie daran (indem Sie es umgestalten und neu implementieren), um es zu verbessern.

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

Ich möchte nur das Programm erstellen, die Architektur aufgestaut werden.

Hervorragende Intuition (zumindest für kleine Projekte). Denken Sie also ein paar Minuten über Ihr Programm nach und beginnen Sie, es mit einem iterativen und inkrementellen Entwicklungsansatz zu codieren: Codieren Sie ein paar Dutzend Zeilen und stellen Sie sicher, dass sie gut funktionieren. Wiederholen Sie dann den Vorgang. Studieren Sie zuvor 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 über einen Metaprogrammierungsansatz nach: Es gibt Situationen, in denen Sie eine "Quelldatei" generieren möchten (Beispiele hierfür sind Parsergeneratoren wie Bison , Glue-Code-Generatoren wie SWIG , Google Protobuf und manchmal möchten Sie vielleicht eine einfaches Skript - oder verwenden Sie einen generischen Präprozessor wie GPP -, um einen Teil Ihres C ++ - oder Java-Codes auszugeben, um wiederholtes Codieren zu vermeiden).

PS. Ich bin ein Forschungsingenieur, habe einen Doktortitel in Informatik und 40 Jahre Erfahrung und ich 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 im Traum oder im Schlaf und ganz sicher ohne Computer und normalerweise sogar ohne Bleistift). Auch wenn ich Forschungsstipendien schreibe , entwerfe ich 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 wie beim Schreiben einer durchschnittlichen Mobiltelefonanwendung. Siehe auch Norvig's Teach yourself-Programmierung in zehn Jahren Seite.

Es gibt drei Mottos, an die ich mich gerne erinnere.

• "Alles sollte so einfach wie möglich sein, 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 Bugs" versus "Offensichtlich keine Bugs"

  Letzteres ist vorzuziehen!

  Und das ist der Grund, warum es einfach sein muss, dh, Sie können darüber nachdenken. Eine große Klasse könnte zu groß und zu kompliziert sein (oder werden), 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 das, was es verspricht. und ihre Schnittstellen sind einfach und sie kombinieren auf die richtige Weise. "

  1. Der Code sollte theoretisch (dh in Ihrem Kopf) ausgeführt werden.
  2. Wenn es dann in der Praxis nicht funktioniert, können Sie es debuggen, bis die Praxis mit der Theorie übereinstimmt.

  Ein Anfänger kümmert sich manchmal nicht um Schritt 1, dh um das Laufen im Kopf (z. B. weil es zu kompliziert ist) - aber in diesem Fall läuft es nur "zufällig" und nicht "theoretisch", möglicherweise, weil Sie Es wurde nicht genug getestet, um nicht offensichtliche Fehler zu finden.

• Gall'sches Gesetz

  Dies ist auch als "Refactor" bekannt.

  In der Praxis bedeutet dies:

  1. Beginnen Sie mit einem einfachen System, das funktioniert
  2. Jetzt ist es Zeit, eine neue Funktion hinzuzufügen
  3. Refaktorieren Sie das vorhandene System so, dass (dh bis) das neue Feature einfach hinzugefügt werden kann

  4. Fügen Sie die neue Funktion hinzu

  5. ... und wiederhole wie oben

  Dies passt zu Mottos wie YAGNI, dh Sie müssen sich nicht um die Architektur kümmern, bevor Sie sie umgestalten müssen. Sie müssen jedoch die richtige Architektur genau zum richtigen Zeitpunkt erstellen, dh wenn Sie sie für einen bestimmten Zweck benötigen.

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 Features hinzufügen, sehen Sie Dinge, die in eine andere Abstraktion verschoben werden müssen. Das Prinzip der einmaligen Verantwortung (S von SOLID) besagt beispielsweise, dass Sie in der Klasse Person keine Methoden zum Parsen von Adressen verwenden dürfen. Sie wissen jetzt, dass Sie eine Adressklasse benötigen.

Es ist jedoch immer gut, sich etwas Zeit zu nehmen, um zu überlegen, wie die "minimale Anzahl von Abstraktionen" für Ihr System aussieht. Gehen Sie von einer Architektur aus, die gut genug ist, und verbessern Sie sie nach und nach.

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

Zeit zum Nachdenken über die Architektur eines Systems ist keine Zeitverschwendung.

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

Meine kurze Antwort darauf wäre: Sie müssen die Kernprinzipien ermitteln, die es Ihnen ermöglichen, zuverlässig und effizient Entscheidungen zu treffen, und dann müssen Sie tatsächlich ein Stück Software in die Realität umsetzen. Dies wird eine lange Reise der Suche nach Wissen, Versuch und Irrtum und persönlicher Entwicklung sein.

-

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

Ich sollte zuerst die Konzepte klarstellen: 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 ich glaube, Sie sprechen in diesem Zusammenhang von Design .

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

• 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 es einer der größten blinden Flecken für die 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 ein lebendiges ding ist, das sich mit der zeit entwickelt, müssen sich architektur und design ebenfalls weiterentwickeln. Sie werden sich entweder kontrolliert durch bewusste Entscheidungen entwickeln, die zum richtigen Zeitpunkt getroffen wurden, oder sie werden sich chaotisch entwickeln, angetrieben durch die Kodierung. Dies ist für das Verständnis von entscheidender Bedeutung, da dies bedeutet, dass der traditionelle Ansatz von "erst Architekt und dann Code schreiben" fehlerhaft ist. Wenn Sie ein Projekt von Grund auf neu beginnen, müssen Sie natürlich einige architektonische und gestalterische Arbeiten im Voraus ausführen. Abgesehen davon müssen jedoch noch viele architektonische und gestalterische Entscheidungen getroffen werden, während das System entwickelt wird.

Die weiter oben zu destillieren, ist es sehr wichtig , sich der Tatsache bewusst zu sein , dass Sie werden Design Entscheidungen treffen , während das Schreiben von Code, bewusst oder nicht. 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 in der Codebasis, die sich nur schwer ändern lässt, um Fehler zu beheben oder Features zu implementieren). Robert C. Martin illustriert dies sehr schön mit Daten in seinem Buch "Clean Architecture" (das ich übrigens sehr empfehle).

Nun, da wir wissen, warum Architektur und Design wichtig sind, was sind die Kernprinzipien, die uns einen geeigneten Rahmen für eine gute Entscheidungsfindung geben können? Ich hatte diese Frage zu Beginn meiner Karriere. Ich hatte das Gefühl, dass etwas in meinem Toolset fehlt , wusste aber nicht, was, wusste nicht, wie ich es beschreiben sollte oder suchte danach. Ich werde einige dieser Prinzipien, die ich mit der Zeit entdeckt habe, mit Ihnen teilen und hoffe, dass sie Ihnen das Leben ein wenig erleichtern:

• In Martin Fowlers Buch "Refactoring: Verbessern des Designs von vorhandenem Code" finden Sie einige sehr einfache, aber leistungsstarke Codierungstricks. Es gibt zu viele, um sie hier aufzulisten, aber es handelt sich um Entscheidungen auf sehr niedriger Ebene, die Sie in Bezug auf die Codierungszeit treffen können, um Ihre Codestruktur erheblich zu verbessern und die Entwurfsentscheidungen zu treffen. Das Buch ist auch ein gutes Beispiel dafür, wie Sie Unit-Tests in Ihren persönlichen Workflow integrieren und testbaren Code schreiben können.

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

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

Open / Closed-Prinzip : "Software-Entitäten… sollten für Erweiterungen offen, für Änderungen jedoch geschlossen sein."

• das Konzept der Komposition über die Vererbung

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

• die Konzepte der Kopplung ("der Grad der gegenseitigen Abhängigkeit zwischen Softwaremodulen") und der Kohäsion ("der Grad, zu dem die Elemente innerhalb eines Moduls zusammengehören").
• das DRY-Konzept (Don't Repeat Yourself)
• 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 statusbehafteten und zustandslosen Systemen (meine Faustregel lautet: Vermeiden Sie den Umgang mit Zuständen; Erstellen Sie so viele zustandslose 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. Der nächste Schritt ist, sie in der Praxis anzuwenden und Erfahrungen zu sammeln, 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 sind gerade einen langen, aber erfüllten Weg gegangen. Üben und experimentieren Sie weiter, achten Sie darauf, was funktioniert und was nicht und Sie werden erst mit der Zeit besser.

Das meiste, was Sie beschreiben, ist nicht wirklich (wichtige) Architektur - gutes Benennen und gutes Design sollten für Sie selbstverständlich sein. Dies wird einfach besser, je mehr Sie codieren. Am hilfreichsten bei solchen Problemen ist in der Regel die Paarprogrammierung. Sie hilft dabei, solche Probleme zu klären und zu lernen, wie dies effizient funktioniert.

Wo Architektur notwendig ist, ist VOR dem Projekt:

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

2. Definieren Sie gegebenenfalls die begrenzten Kontexte Ihres Systems und vergewissern Sie sich, dass Ihr Wortschatz klar ist. Wenn das Unternehmen von "Frobbels" spricht, vergewissern Sie sich, dass Sie Klassen / Schnittstellen usw. mit "*** Frobbels" benennen. Klingt trivial, aber wenn Sie über Workflows sprechen, während das Geschäft ü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ß. Du baust zB einen Bananenbildgenerator, aber dein Frontend-Entwickler benötigt einen Apfelbildgenerator. Oder Sie bauen etwas, das 100 Anfragen / Sekunde beantworten kann, aber 10000 U / Sek benötigt werden.

Hinweis: Dies wird stark von meiner Arbeit an einer Microservice-Architektur beeinflusst. Wie die Server intern aufgebaut sind, lässt sich auch KÖNNEN - aber meistens ist es weitaus weniger wichtig, als den Überblick zu behalten.

Ich werde Sie nicht mit einer Reihe von Begriffen und Abkürzungen konfrontieren (die meisten davon werden von der Mehrheit der Programmierer / Software-Ingenieure kaum akzeptiert). 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 in ein Problem mit der ersten Lösung eintauchen, die Ihnen einfällt, 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 der vielen möglichen Kompromisse gegeneinander abwägen. 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 in jüngster Zeit kann das Codieren und Debuggen sehr aufregend sein, aber dies wird mit der Zeit nachlassen und die Fähigkeiten, die Sie jetzt erlernen, werden Ihnen dabei gute Dienste leisten.

4. Ich würde argumentieren, dass das Erstellen von Software mehr Kunst / Handwerk als Ingenieurwesen ist. Bei großartiger Kunst geht es nicht nur um den individuellen Pinselstrich, sondern auch um Entscheidungen und Kompromisse auf höchster Ebene, die vom Künstler / Handwerker getroffen wurden.

Ich werde versuchen, diese Frage vom Standpunkt der Webentwicklung aus zu beantworten (dh von einem Gebiet aus, in dem sich die Menschen häufig mit Architektur auseinandersetzen). Ich beginne mit der Erklärung, warum sich die Leute für Architektur interessieren, und zeige dann Möglichkeiten auf, wie man schneller an der Architektur 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 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 bereitstellt, die Sie erkennen und zum Navigieren verwenden können. Ebenso können Sie anhand einer guten Architektur feststellen, wo sich der Code befindet, der eine bestimmte Funktion verarbeitet. In den meisten Webprojekten hängt die Architektur beispielsweise stark davon ab, wie Ordner und Dateien sortiert werden. Auf der anderen Seite sollte eine gute Architektur Ihnen helfen, weniger über den Code nachzudenken, da sie bereits eine intuitive Stelle haben sollte, zu der jeder Code gehört.

Darüber hinaus bietet eine gute Architektur eine Abkürzung, um viele Fallstricke zu vermeiden, die verhindern könnten, dass Ihr Code problemlos verwendet wird. Wenn Sie eine Architekturentscheidung treffen, sollte eine Konvention festgelegt werden, mit der Sie weniger über das Schreiben von Code nachdenken können.

Nun der Teil, für den du eigentlich hier bist:

Was können Sie durch den Architekturteil schneller erreichen:

1. Tu es nicht

Da haben schon viele Antworten darauf hingewiesen. Fragen Sie sich zunächst, ob Sie tatsächlich Architektur benötigen. Wenn Sie nicht viel Code haben (und sicher sein können, dass das Projekt in naher Zukunft nicht wächst), können Sie einfach den Architekturteil überspringen und etwas zusammenfügen, das einfach funktioniert. Wenn Sie jedoch früh in 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 dann ist es wahrscheinlich zu spät, um etwas zu lernen.

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

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

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

An diesem Punkt ist es Zeit, schamlos zu stehlen. Es gibt eine Menge Literatur darüber, wie man eine Programmarchitektur richtig einrichtet, und diese vorhandenen Architekturprototypen decken eine erstaunliche Menge von Anwendungsfällen ab. Sie sollten sich einen groben Überblick über die vorhandenen Architekturen verschaffen, auch wenn Sie nicht wissen, wie Sie diese implementieren sollen.

Wenn Sie sich für eine Art Architektur entschieden haben, bleiben Sie dabei. Die Entscheidung über die Architektur sollte größtenteils intuitiv sein und nur wenige Sekunden nach der Ersteinrichtung erfolgen. Vieles davon hängt von der Erfahrung ab.

Denken Sie nicht zu viel darüber nach. Sie geben das Beispiel, ob etwas öffentlich oder privat sein soll, 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 häufen sich nach einiger Zeit, aber am Ende des Tages wird es wahrscheinlich auch Ihr Projekt nicht töten. In erster Linie erstellen Sie 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.)

Die Antwort ist sehr einfach,

• Erstellen Sie einen Prototyp (Time Boxed)
• Refactor (verbringen Sie so viel Zeit, wie Sie möchten oder aufgrund einer Vielzahl von Faktoren haben)

Bei der Erstellung eines Prototyps sollte der Schwerpunkt auf einem Produkt mit minimaler Funktionsfähigkeit liegen, und bei der Umgestaltung sollte der Schwerpunkt auf der Skalierbarkeit Ihres Projekts oder Ihrer Lösung liegen.

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

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

Es fehlt Ihnen einfach die Erfahrung, um solche Entscheidungen schnell zu treffen. Uni hat dir einen schönen theoretischen Hintergrund, 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 schnellste Möglichkeit, Dinge zu lernen, besteht darin, mit Menschen zusammenzuarbeiten, die besser im Job sind als Sie. 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 grösstes Bedürfnis, wie Ihr Dilemma beweist. Sie genießen die Codierungs- und Debugging-Phase? Klingt nach einem perfekten Junior. Aber ein Junior braucht die Führung eines Senioren. Das ist der Sinn dieser Stellenbeschreibungen. Fremde im Internet können dir nur soweit helfen, du brauchst einen Mentor.

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

So verschwenden Sie keine Zeit mehr mit dem Entwerfen von Architektur

Diese Frage ist eher geladen. Sie entwerfen auch keine Architektur. Du Architekt . Architektur und Design sind komplementäre und verwandte Aktivitäten, aber nicht dasselbe, selbst wenn sie sich überschneiden.

Auf die gleiche Art und Weise, wie Sie Zeit mit der Ausführung von Architekturen (durch Überarchitekturen) verschwenden können, können Sie auch Zeit mit Überdesignen und -codierungen (durch Codieren von Inhalten, die weitaus komplexer als nötig sind, oder wenn dies nicht der Fall ist) verschwenden Code für die Dinge, die erforderlich sind.)

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 behoben und 6) endgültig stillgelegt werden soll.

Ich habe die Erfahrung gemacht, dass Leute, die einfach nur Spaß am Codieren haben, einfach codieren, ohne darüber nachzudenken, wie ein System auf lange Sicht zu betreiben und zu warten ist, und zur nächsten heißen Kartoffel übergehen, die eine arme Seele hinterlässt, um einen hässlichen Golem aufrechtzuerhalten.

Aber ich schweife ab...

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

Dies gilt nur für große Systeme, an denen eine große Anzahl von Personen oder Software auf Systemebene beteiligt ist, die sehr komplexe Aufgaben ausführen, 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, die ich sagen würde, haben 1 Lösung.

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

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

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

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

- Dinge wie Software-Architektur.

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

Wenn wir Software für solche Systeme entwickeln (ein Bankensystem, ein Stromüberwachungssystem, ein Ticketverkaufssystem usw.), möchten wir eine Software erstellen, die die Funktionen und Anforderungen eines solchen Systems nachahmt .

Wir können einfach nicht einfach improvisieren und Code es Cowboy - Stil. Wir brauchen eine Art Architektur. Dies gilt insbesondere dann, wenn das Projekt Dutzende von Ingenieuren erfordert, wenn nicht sogar 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 und Stunden damit zu entscheiden, wie ich meine Programme und Systeme "architektonisch" gestalten soll. ZB 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 beanspruchen so viel Zeit und es frustriert mich sehr. Ich möchte nur das Programm erstellen, die Architektur ist verdammt.

Leider ist das keine Software-Architektur.

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, darauf eine Antwort zu finden, 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 oft nicht.

Es ist großartig, Dinge zu tun, die uns Spaß machen, aber in einem so komplexen Beruf wie dem unseren ist es nicht sinnvoll, sich auf das zu konzentrieren, was uns Spaß macht, um 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, lohnt es sich nicht" und mein Favorit: "Wenn es saugt (und es ist wichtig), tun Sie es, bis es aufhört zu saugen."

Meine Empfehlungen:

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

1. Codierung (wie Sie Ihre Klassen, Module oder was nicht codieren, Namenskonventionen, Zugriffssichtbarkeit, Gültigkeitsbereich 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 Stufe zu heben.

Code bereinigen

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 an Zusammenhalt mangelt.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://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 beherrschen zu können.

Während wir uns durch die SOLID-Prinzipien bewegen, müssen wir uns auch mit den "GRASP" -Prinzipien vertraut machen , die bestimmen oder vielmehr steuern, wie wir Klassen codieren.

Zusätzliche Bücher

Abschließend möchte ich noch Folgendes vorschlagen:

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

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

Hiermit sollten Sie einen guten Einblick in das Codieren und Entwerfen sowie in das Bewegen und Beherrschen (oder zumindest Verstehen) der Softwarearchitektur erhalten.

Ich bin sicher, dass es andere Fachleute geben wird, die diese Vorschläge ergänzen, subtrahieren oder ablehnen. Sie werden mit anderen Vorschlägen aufwarten, die wahrscheinlich durch ihre eigenen Erfahrungen bestätigt wurden.

Ich kann nur folgendes sagen: Es gibt keine Abkürzungen.

Alles Gute.

Es gibt viele Informationen hier und ehrlich gesagt TL; DR. Es gibt eine Hauptsache, von der ich denke, dass die Leute beim Versuch, das Entwerfen eines Systems zu lernen, falsch liegen: Sie versuchen, in der Reihenfolge, in der die Arbeit erledigt wird, darüber nachzudenken. 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 beginnt nicht damit, sich Fragen zu stellen wie: "Wie viele Fenster sollte dieses Haus haben?", "Wo soll der erste Ziegelstein platziert werden?". Diese Implementierungsdetails sind nicht das Design, sie leiten sich aus dem Design ab. 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 der Architektur zu tun, ob Variablen privat sind und ob Sie eine Klasse teilen.

Beginnen Sie zuerst damit, herauszufinden, was die Ziele Ihres Designs sind. Ist dies beispielsweise eine einmalige Lösung? Wird es über Jahrzehnte erweitert, überarbeitet und gepflegt? Die Antwort darauf wird auf sehr unterschiedliche Designs hinweisen und das ist der Punkt der Architektur. Sobald Sie herausgefunden haben, was Sie tun müssen, folgen die Details des Entwurfs natürlich. Nicht, dass diese Details offensichtlich oder einfach sind, aber es ist der übergeordnete Plan, auf dem diese Auswahl basiert.

Es ist ziemlich einfach zu beurteilen, wie viel Zeit Sie für die Architektur einer Software aufwenden sollten, bevor Sie eine Schreib-Kompilier-Test-Schleife erhalten: genug Informationen, um in Ihren Kopf zu passen, und nicht mehr. Sofern das Projekt, an dem Sie arbeiten, keine strengere Methodik vorschreibt. In diesem Fall sollten Sie als Anfänger wahrscheinlich ein Architekturdokument lesen und nicht schreiben.

Was das Benennen von Dingen angeht, so ist das für mich Teil des "Schreibens", aber es ist zweifellos ein sehr wichtiger Teil des Programmierens: Zögern Sie nicht, sich Gedanken darüber zu machen, wie Sie Dinge benennen, und umso mehr zu überlegen, je umfangreicher der Name ist.

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