architecture news - Software Design vs.Software Architektur




in projects (25)

Cliff Notes Version:

Design: Implementierung einer Lösung basierend auf den Spezifikationen des gewünschten Produkts.

Architektur: Die Grundlage / Tools / Infrastruktur / Komponenten, die Ihr Design unterstützen.

Dies ist eine ziemlich breite Frage, die viele Antworten hervorrufen wird.

Könnte jemand den Unterschied zwischen Software-Design und Software-Architektur erklären?

Genauer; Wenn Sie jemandem sagen, Ihnen das "Design" zu präsentieren - was würden Sie von ihm erwarten? Gleiches gilt für "Architektur".

Mein derzeitiges Verständnis ist:

  • Design: UML-Diagramm / Flussdiagramm / einfache Wireframes (für UI) für ein bestimmtes Modul / einen Teil des Systems
  • Architektur: Komponentendiagramm (zeigt, wie die verschiedenen Module des Systems miteinander und mit anderen Systemen kommunizieren), welche Sprache soll verwendet werden, Muster ...?

Korrigiere mich, wenn ich falsch liege. Ich habe Wikipedia erwähnt Artikel auf http://en.wikipedia.org/wiki/Software_design und http://en.wikipedia.org/wiki/Software_architecture , aber ich bin mir nicht sicher, ob ich sie richtig verstanden habe.


  1. Architektur bedeutet die konzeptionelle Struktur und logische Organisation eines Computers oder eines computerbasierten Systems.

    Design bezeichnet einen Plan oder eine Zeichnung, die erstellt wurden, um das Aussehen und die Funktion oder Funktionsweise eines Systems oder eines Objekts vor der Erstellung anzuzeigen.

  2. Wenn Sie eine Komponente "entwerfen", definieren Sie, wie sie sich im größeren System verhält.

    Wenn Sie dieselbe Komponente "entwerfen", definieren Sie, wie sie sich intern verhält.

Alle Architektur ist Design, aber nicht alles Design ist Architektur.

What ist das Design, das How ist die konkrete Umsetzung und die Schnittmenge von What und How ist Architektur What

Bild für die Differenzierung von Architektur und Design :

Es gibt auch Designentscheidungen, die nicht architektonisch signifikant sind, also nicht zum Architekturzweig des Designs gehören. Zum Beispiel die internen Designentscheidungen einiger Komponenten, die Auswahl des Algorithmus, die Auswahl der Datenstruktur usw.

Jede Designentscheidung, die außerhalb ihrer Komponentengrenze nicht sichtbar ist, ist das interne Design einer Komponente und ist nicht architektonisch. Dies sind die Designentscheidungen, die ein Systemarchitekt dem Ermessen des Moduldesigners oder dem Implementierungsteam überlassen würde, solange deren Design die architektonischen Einschränkungen der Architektur auf Systemebene nicht verletzt.

Die Verbindung, die gute Analogie gibt


Du hast recht, ja. Die Architektur eines Systems ist sein "Skelett". Es ist die höchste Abstraktionsebene eines Systems. Welche Art von Datenspeicherung ist vorhanden, wie interagieren Module miteinander, welche Wiederherstellungssysteme sind vorhanden? Genau wie Designmuster gibt es architektonische Muster: MVC, 3-Tier-Schichtdesign usw.

Beim Softwaredesign geht es um die Gestaltung der einzelnen Module / Komponenten. Was sind die Verantwortlichkeiten, Funktionen, von Modul x? Von Klasse Y? Was kann es tun und was nicht? Welche Designmuster können verwendet werden?

Kurz gesagt, geht es bei der Software-Architektur mehr um das Design des gesamten Systems, während das Software-Design auf der Ebene von Modulen, Komponenten und Klassen liegt.



Ich betrachte Architektur wie Patrick Karcher - das große Ganze. Zum Beispiel können Sie die Architektur für ein Gebäude bereitstellen, seine strukturelle Unterstützung, die Fenster, Ein- und Ausgänge, Wasserabfluss usw. sehen. Aber Sie haben nicht die Grundriss-, Kabinenpositionen usw. "entworfen".

Während Sie das Gebäude entworfen haben, haben Sie nicht das Layout jedes Büros entworfen. Ich denke, das gilt auch für Software.

Sie könnten das Design des Layouts sehen, als "das Layout erstellen" aber ...


Ich denke, wir sollten die folgende Regel verwenden, um zu bestimmen, wann wir über Design vs. Architecture sprechen: Wenn die Elemente eines von Ihnen erstellten Softwarebildes einer syntaktischen Konstruktion einer Programmiersprache eins zu eins zugeordnet werden können, dann ist Design, wenn nicht Architektur.

Wenn Sie beispielsweise ein Klassendiagramm oder ein Sequenzdiagramm sehen, können Sie eine Klasse und ihre Beziehungen mithilfe der syntaktischen Konstruktion der Klasse einer objektorientierten Programmiersprache zuordnen. Das ist eindeutig Design. Darüber hinaus könnte dies dazu führen, dass diese Diskussion eine Beziehung zu der Programmiersprache hat, mit der Sie ein Softwaresystem implementieren. Wenn Sie Java verwenden, gilt das vorherige Beispiel, da Java eine objektorientierte Programmiersprache ist. Wenn Sie ein Diagramm erstellen, das Pakete und ihre Abhängigkeiten anzeigt, ist das auch Design. Sie können das Element (in diesem Fall ein Paket) einer syntaktischen Java-Konstruktion zuordnen.

Nehmen wir nun an, Ihre Java-Anwendung ist in Module unterteilt, und jedes Modul besteht aus einer Gruppe von Paketen (dargestellt als JAR-Datei-Deployment-Unit), und Ihnen wird ein Diagramm mit Modulen und seinen Abhängigkeiten angezeigt, also Architektur. Es gibt in Java (zumindest bis Java 7) keine Möglichkeit, ein Modul (einen Satz von Paketen) einer syntaktischen Konstruktion zuzuordnen. Möglicherweise stellen Sie auch fest, dass dieses Diagramm eine höhere Stufe der Abstraktion Ihres Softwaremodells darstellt. Jedes Diagramm oberhalb (grobkörniger als) eines Paketdiagramms repräsentiert eine Architekturansicht bei der Entwicklung in der Java-Programmiersprache. Auf der anderen Seite, wenn Sie in Modula-2 entwickeln, dann repräsentiert ein Moduldiagramm ein Design.

(Ein Fragment von http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )


Die Softwarearchitektur eines Programms oder Computersystems ist die Struktur oder Strukturen des Systems, die Softwarekomponenten, die extern sichtbaren Eigenschaften dieser Komponenten und die Beziehungen zwischen ihnen umfassen.

(aus Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )

Softwaredesign ist ein Prozess der Problemlösung und Planung für eine Softwarelösung. Nachdem der Zweck und die Spezifikationen der Software festgelegt sind, werden Softwareentwickler Designer entwerfen oder beschäftigen, um einen Plan für eine Lösung zu entwickeln. Es beinhaltet Low-Level-Komponenten und Algorithmenimplementierungsprobleme sowie die Architekturansicht.

(aus Wikipedia, http://en.wikipedia.org/wiki/Software_design )

Ich hätte es nicht besser sagen können :)


Architektur ist Design, aber nicht alles Design ist architektonisch. Streng genommen wäre es daher sinnvoller, zwischen architektonischem Design und nicht-architektonischem Design zu unterscheiden . Und was ist der Unterschied? Es kommt darauf an! Jeder Softwarearchitekt kann eine andere Antwort haben (ymmv!). Wir entwickeln unsere Heuristiken, um eine Antwort zu finden, wie zum Beispiel "Klassendiagramme sind Architektur und Sequenzdiagramme sind Design". Siehe DSA-Buch für mehr.

Es ist üblich zu sagen, dass Architektur auf einer höheren Abstraktionsebene als Design ist, oder Architektur ist logisch und Design ist physikalisch. Aber diese Vorstellung, obwohl sie allgemein akzeptiert wird, ist in der Praxis nutzlos. Wo zeichnen Sie die Grenze zwischen hoher oder niedriger Abstraktion, zwischen logisch und physisch? Es kommt darauf an!

Also, mein Vorschlag ist:

  • Erstellen Sie ein einzelnes Design-Dokument.
  • Benennen Sie dieses Designdokument so, wie Sie es möchten, oder besser, wie es die Leser gewohnt sind. Beispiele: "Software Architecture", "Software Design Specification".
  • brechen Sie dieses Dokument in Ansichten und beachten Sie, dass Sie eine Ansicht als Verfeinerung einer anderen Ansicht erstellen können.
  • Machen Sie die Ansichten im Dokument navigierbar, indem Sie Querverweise oder Hyperlinks hinzufügen
  • dann haben Sie Ansichten auf höherer Ebene, die einen breiten, aber flachen Überblick über das Design und engere Implementierungsansichten mit engen, aber tieferen Designdetails bieten.
  • Vielleicht möchten Sie sich ein Beispiel für ein Multi-View-Architekturdokument ansehen ( here ).

Nachdem wir all das gesagt haben, ist eine relevantere Frage, die wir stellen müssen: Wie viel Design ist genug? Das heißt, wann sollte ich aufhören, das Design zu beschreiben (in Diagrammen oder Prosa) und mit der Codierung fortfahren?


Ziemlich subjektiv, aber meine Meinung:

Architektur Das Gesamtdesign des Systems einschließlich der Interaktionen mit anderen Systemen, Hardwareanforderungen, Gesamtkomponentenentwurf und Datenfluss.

Design Die Organisation und der Ablauf einer Komponente im Gesamtsystem. Dies würde auch die API der Komponente für die Interaktion mit anderen Komponenten einschließen.


Meine Erinnerung:

  • Wir können das Design ändern, ohne jemanden zu fragen
  • Wenn wir die Architektur ändern, müssen wir sie jemandem mitteilen (Team, Kunde, Stakeholder, ...)

Die Softwarearchitektur wird am besten auf Systemebene verwendet, wenn Sie Geschäftsprozesse und Funktionen durch höhere Architekturebenen in Anwendungen projizieren müssen.

In Ihrem Geschäft geht es zum Beispiel um "Gewinn und Verlust" für Händler, und Ihre Hauptfunktionen umfassten "Portfolio-Bewertung" und "Risiko-Berechnung".

Aber wenn ein Software-Architekt seine Lösung detailliert beschreibt, wird er feststellen, dass:

"Portfolio-Evaluierung" kann nicht nur eine Anwendung sein. Es muss in überschaubaren Projekten wie:

  • GUI
  • Startprogramm
  • Dispatcher
  • ...

(Da die beteiligten Operationen so groß sind, müssen sie auf mehrere Computer verteilt werden, während sie immer noch über eine gemeinsame GUI überwacht werden)

Ein Softwaredesign wird die verschiedenen Anwendungen, ihre technischen Beziehungen und ihre internen Teilkomponenten untersuchen.
Es werden die Spezifikationen erstellt, die für die letzte Architekturschicht (die "Technische Architektur") erforderlich sind, um daran zu arbeiten (im Sinne eines technischen Rahmens oder transversaler Komponenten) und für die Projektteams (mehr an der Implementierung der Geschäftsfunktionen orientiert ) zu beginnen ihre jeweiligen Projekte.


Architektur sind "die Design-Entscheidungen, die schwer zu ändern sind."

Nachdem ich mit TDD gearbeitet habe, was praktisch bedeutet, dass sich dein Design ständig ändert, habe ich mich oft mit dieser Frage herumgeschlagen. Die obige Definition wird von Patterns of Enterprise Application Architecture von Martin Fowler extrahiert

Das bedeutet, dass die Architektur von der Sprache, dem Framework und der Domäne Ihres Systems abhängt. Wenn Sie in nur 5 Minuten eine Schnittstelle aus Ihrer Java-Klasse extrahieren können, ist dies nicht mehr die Architekturentscheidung.


Darauf gibt es keine definitive Antwort, denn "Software-Architektur" und "Software-Design" haben eine ganze Reihe von Definitionen, und für beide gibt es keine kanonische Definition.

Eine gute Denkweise ist die Aussage von Len Bass, Paul Clements und Rick Kazman, dass "alle Architektur ist Design, aber nicht alles Design ist Architektur" [Software Architecture in Practice]. Ich bin mir nicht sicher, ob ich damit einverstanden bin (weil Architektur andere Aktivitäten beinhalten kann), aber es erfasst die Essenz, dass Architektur eine Designaktivität ist, die sich mit der kritischen Teilmenge des Designs befasst.

Meine leicht frivole Definition (auf der SEI-Definitionsseite zu finden ) ist, dass es sich um eine Reihe von Entscheidungen handelt, die, wenn sie falsch gemacht werden, dazu führen, dass Ihr Projekt abgebrochen wird.

Ein nützlicher Versuch, Architektur, Design und Implementierung als Konzepte zu trennen, hat Amnon Eden und Rick Kazman vor einigen Jahren in einer Forschungsarbeit mit dem Titel "Architecture, Design, Implementation" gemacht, die hier zu finden ist: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf . Ihre Sprache ist ziemlich abstrakt, aber vereinfachend sagen sie, dass Architektur ein Design ist, das in vielen Kontexten verwendet werden kann und systemübergreifend angewendet werden soll. Design ist (Err) Design, das in vielen Kontexten verwendet werden kann, aber in einem bestimmten Teil angewendet wird des Systems, und die Implementierung ist kontextspezifisch und wird in diesem Kontext angewendet.

Eine architektonische Entscheidung könnte also eine Entscheidung sein, das System über Messaging anstatt über RPC zu integrieren (es ist also ein allgemeines Prinzip, das an vielen Stellen angewendet werden könnte und das auf das gesamte System angewendet werden soll). Eine Designentscheidung könnte die Verwendung eines Masters sein / Slave-Thread-Struktur im Eingabeantragsabwicklungsmodul des Systems (ein allgemeines Prinzip, das überall verwendet werden könnte, aber in diesem Fall nur in einem Modul verwendet wird) und schließlich eine Implementierungsentscheidung könnte sein, Verantwortlichkeiten für die Sicherheit vom Anforderungs-Router zu verschieben an den Request-Handler im Request-Manager-Modul (eine Entscheidung, die nur für diesen Kontext relevant ist und in diesem Kontext verwendet wird).

Ich hoffe das hilft!


Ja, das klingt richtig für mich. Das Design ist, was Sie tun werden, und Architektur ist die Art und Weise, in der die Teile des Designs zusammengefügt werden. Es könnte sprachunabhängig sein, würde aber normalerweise die zu verwendenden Technologien spezifizieren, dh LAMP v Windows, Web Service v RPC.


wenn jemand ein Schiff baut, dann werden Motor, Rumpf, Stromkreise usw. seine "architektonischen Elemente" sein. Der Motorenbau wird für ihn "Design-Arbeit" sein.

Wenn er dann den Aufbau des Motors an ein anderes Team delegiert, wird er eine "Motorarchitektur" kreieren ...

Also - es hängt von der Ebene der Abstraktion oder Detail ab. Die Architektur einer Person könnte ein Design anderer sein!


Vor langer Zeit an einem weit entfernten Ort sorgten sich Philosophen um die Unterscheidung zwischen dem Einen und dem Vielen. In der Architektur geht es um Beziehungen, die viele erfordern. Architektur hat Komponenten. Design ist über Inhalt, der den einen erfordert. Design hat Eigenschaften, Qualitäten, Eigenschaften. Wir denken typischerweise, dass Design innerhalb der Architektur liegt. Dualistisches Denken gibt den Vielen das Ursprüngliche. Aber Architektur ist auch im Design. Es ist alles, was wir wählen, um zu sehen, was vor uns ist - das Eine oder das Viele.


Gute Frage ... Obwohl die Linie zwischen ihnen kaum eine helle scharfe Linie ist, imho, wenn Sie beide Begriffe verwenden, dann umfasst Architektur mehr technische oder strukturelle Entscheidungen darüber, wie man etwas baut oder konstruiert, besonders solche Entscheidungen, die schwer sein werden ( oder schwerer) zu ändern, sobald implementiert, während Design die Entscheidungen umfasst, die später leicht geändert werden können (wie Methodennamen, Klasse <-> Dateiorganisationsstruktur, Entwurfsmuster, ob ein Singleton oder eine statische Klasse verwendet werden soll, um ein bestimmtes Problem zu lösen) usw.) und / oder solche, die das Erscheinungsbild oder die ästhetischen Aspekte eines Systems oder einer Anwendung beeinflussen (Benutzerschnittstelle, Benutzerfreundlichkeit, Aussehen und Verhalten usw.)


Ich fand das, weil ich selbst nach einer einfachen Unterscheidung zwischen Architektur und Design suchte;
Was halten Sie von dieser Art, sie anzusehen?

  • Architektur ist "was" wir bauen;
  • Design ist "wie" wir bauen;

Die Softwarearchitektur "beschäftigt sich mit Fragen ... jenseits der Algorithmen und Datenstrukturen der Berechnung.

Bei der Architektur geht es insbesondere nicht um ... Details von Implementierungen (z. B. Algorithmen und Datenstrukturen). Architektonisches Design beinhaltet eine umfassendere Sammlung von Abstraktionen, als sie normalerweise von OOD bereitgestellt wird ("objektorientiertes Design").

Design befasst sich mit der Modularisierung und den detaillierten Schnittstellen der Entwurfselemente, ihren Algorithmen und Verfahren sowie den Datentypen, die zur Unterstützung der Architektur und zur Erfüllung der Anforderungen benötigt werden.

"Architektur" wird oft als bloße Synonym für "Design" verwendet (manchmal mit dem Adjektiv "High-Level" vorangestellt). Und viele Menschen verwenden den Begriff "Architekturmuster" als Synonym für "Designmuster".

Überprüfen Sie diesen Link.

Definieren der Begriffe Architektur, Design und Implementierung


In einigen Beschreibungen des SDLC (Software Development Life Cycle) sind sie austauschbar, aber der Unterschied liegt darin, dass sie verschieden sind. Sie sind gleichzeitig: verschiedene (1) Stufen , (2) Verantwortungsbereiche und (3) Ebenen der Entscheidungsfindung .

Diese beiden Phasen scheinen sich aus verschiedenen Gründen zu vermischen.

  1. Kleinere Projekte haben oft nicht genug Spielraum, um Planung in Etappen zu trennen.
  2. Ein Projekt könnte Teil eines größeren Projekts sein, und daher sind Teile beider Phasen bereits beschlossen. (Es existieren bereits Datenbanken, Konventionen, Standards, Protokolle, Frameworks, wiederverwendbarer Code usw.)
  3. Neuere Denkweisen über den SDLC (siehe agile ) ordnen diesen traditionellen Ansatz etwas um. Design (Architektur in geringerem Maße) findet absichtlich im gesamten SDLC statt. Es gibt oft mehrere iterations denen der ganze Prozess immer wieder passiert.
  4. Die Softwareentwicklung ist kompliziert und schwierig zu planen, aber Kunden / Manager / Vertriebsmitarbeiter erschweren es normalerweise, Ziele und Anforderungen in der Mitte zu ändern. Entwerfen und sogar architektonische Entscheidungen müssen später im Projekt getroffen werden, ob das der Plan ist oder nicht.

Auch wenn die Phasen oder Verantwortungsbereiche sich überlagern und überall stattfinden, ist es immer gut zu wissen, auf welchem ​​Niveau Entscheidungen getroffen werden. (Wir könnten damit für immer fortfahren. Ich versuche es kurz zu halten.) Ich werde damit enden: Auch wenn es scheint, dass Ihr Projekt keine formale Architektur- oder Designphase / AOR / Dokumentation hat, geschieht es, ob jemand es ist bewusst es tun oder nicht. Wenn sich niemand dafür entscheidet, Architektur zu machen, dann passiert ein Fehler, der wahrscheinlich schlecht ist. Dito für Design. Diese Konzepte sind fast wichtiger, wenn es keine formalen Stufen gibt, die sie repräsentieren.


Persönlich mag ich diesen:

"Der Designer ist damit beschäftigt, was passiert, wenn ein Benutzer eine Taste drückt, und der Architekt ist besorgt, was passiert, wenn zehntausend Benutzer eine Taste drücken."

SCEA für Java ™ EE Study Guide von Mark Cade und Humphrey Sheil


Die Architektur:
Tragwerksplanung auf höheren Abstraktionsebenen, die technisch signifikante Anforderungen in das System umsetzen. Die Architektur legt die Grundlage für weiteres Design.

Design:
Die Kunst, die Architektur durch einen iterativen Prozess auf jeder Abstraktionsebene zu füllen.


Architektur ist ein hochrangiges, abstraktes und logisches Design, während Softwaredesign ein tiefes, detailliertes und physikalisches Design ist.


Architektur ist strategisch, Design ist taktisch.

Architektur umfasst die Frameworks, Tools, Programmierparadigmen, komponentenbasierte Softwareentwicklungsstandards, High-Level-Prinzipien.

Während Design eine Aktivität ist, die sich mit lokalen Einschränkungen beschäftigt, wie Design-Muster, Programmier-Idiome und Refactorings.


Ich spreche ein wenig darüber in Engineering Large Projects in Haskell und im Design und der Implementierung von XMonad. Beim Engineering im Großen geht es um das Management von Komplexität. Die primären Mechanismen zur Strukturierung des Codes in Haskell zur Verwaltung der Komplexität sind:

Das Typensystem

  • Verwenden Sie das Typsystem, um Abstraktionen zu erzwingen und Interaktionen zu vereinfachen.
  • Erzwinge Schlüsselinvarianten über Typen
    • (z. B. dass bestimmte Werte einem gewissen Umfang nicht entgehen können)
    • Dieser bestimmte Code tut keine IO, berührt die Festplatte nicht
  • Sicherheit erzwingen: Ausnahmen überprüft (Maybe / Entweder), Vermischungskonzepte vermeiden (Word, Int, Address)
  • Gute Datenstrukturen (wie z. B. Reißverschlüsse) können einige Testklassen unnötig machen, da sie z. B. Fehler außerhalb der Grenzen statisch ausschließen.

Der Profiler

  • Stellen Sie objektive Beweise für die Heap- und Zeitprofile Ihres Programms bereit.
  • Insbesondere Heap-Profiling ist der beste Weg, um unnötigen Speicherverbrauch zu vermeiden.

Reinheit

  • Reduzieren Sie die Komplexität drastisch, indem Sie den Status entfernen. Rein funktionaler Code skaliert, weil er kompositorisch ist. Alles, was Sie brauchen, ist der Typ, um zu bestimmen, wie Sie Code verwenden - er wird nicht auf mysteriöse Weise brechen, wenn Sie einen anderen Teil des Programms ändern.
  • Verwenden Sie eine Menge "Model / View / Controller" -Stil-Programmierung: Parsen Sie externe Daten so schnell wie möglich in rein funktionale Datenstrukturen, arbeiten Sie mit diesen Strukturen, dann, wenn alle Arbeiten erledigt sind, render / flush / serialisieren. Hält den größten Teil Ihres Codes rein

Testen

  • QuickCheck + Haskell Code Coverage, um sicherzustellen, dass Sie die Dinge testen, die Sie nicht mit Typen überprüfen können.
  • GHC + RTS eignet sich hervorragend, um zu sehen, ob Sie zu viel Zeit mit GC verbringen.
  • QuickCheck kann Ihnen auch dabei helfen, saubere, orthogonale APIs für Ihre Module zu identifizieren. Wenn die Eigenschaften Ihres Codes schwer zu bestimmen sind, sind sie wahrscheinlich zu komplex. Refactoring beibehalten, bis Sie eine saubere Reihe von Eigenschaften haben, die Ihren Code testen können, der gut zusammenstellt. Dann ist der Code wahrscheinlich auch gut gestaltet.

Monaden für die Strukturierung

  • Monaden erfassen wichtige Architekturentwürfe in Typen (dieser Code greift auf Hardware zu, dieser Code ist eine Sitzung für einen einzelnen Benutzer usw.)
  • ZB die X-Monade in xmonad, erfasst genau das Design für welchen Status für welche Komponenten des Systems sichtbar ist.

Geben Sie Klassen und existenzielle Typen ein

  • Verwenden Sie Typklassen, um Abstraktionen bereitzustellen: Blenden Sie Implementierungen hinter polymorphen Schnittstellen aus.

Parallelität und Parallelität

  • Schleichen Sie sich in Ihr Programm ein, um die Konkurrenz mit einfacher, kompostierbarer Parallelität zu schlagen.

Refaktor

  • Sie können in Haskell sehr oft umgestalten. Die Typen stellen sicher, dass Ihre großen Änderungen sicher sind, wenn Sie Arten mit Bedacht verwenden. Dies wird Ihrer Codebasis helfen zu skalieren. Stellen Sie sicher, dass Ihre Refactorings Typfehler bis zur Beendigung verursachen.

Verwenden Sie das FFI mit Bedacht

  • Das FFI macht es einfacher, mit fremden Code zu spielen, aber dieser fremde Code kann gefährlich sein.
  • Seien Sie bei Annahmen über die Form der zurückgegebenen Daten sehr vorsichtig.

Meta-Programmierung

  • Ein wenig Template Haskell oder Generics kann das Standard-Template entfernen.

Verpackung und Vertrieb

  • Benutze Kabale. Rollen Sie nicht Ihr eigenes Build-System. (BEARBEITEN: Eigentlich möchten Sie wahrscheinlich Stack jetzt für den Einstieg verwenden.).
  • Verwenden Sie Haddock für gute API-Dokumente
  • Werkzeuge wie graphmod können Ihre Modulstrukturen graphmod .
  • Verlassen Sie sich bei Bedarf auf die Haskell Platform-Versionen von Bibliotheken und Tools. Es ist eine stabile Basis. (EDIT: Auch in diesen Tagen möchten Sie wahrscheinlich Stack verwenden , um eine stabile Basis zu erhalten.)

Warnungen

  • Verwenden Sie -Wall , um Ihren Code vor Gerüchen zu -Wall . Sie können sich auch Agda, Isabelle oder Catch für mehr Sicherheit ansehen. Für hlint Überprüfen, siehe den großen hlint , der Verbesserungen vorschlagen wird.

Mit all diesen Tools können Sie die Komplexität im Griff behalten und so viele Interaktionen zwischen Komponenten wie möglich entfernen. Idealerweise haben Sie eine sehr große Basis an reinem Code, der wirklich leicht zu pflegen ist, da er kompositorisch ist. Das ist nicht immer möglich, aber es lohnt sich, darauf zu zielen.

Allgemein: zerlegen Sie die logischen Einheiten Ihres Systems in die kleinsten referenztransparenten Komponenten und implementieren Sie diese dann in Modulen. Globale oder lokale Umgebungen für Gruppen von Komponenten (oder in Komponenten) können Monaden zugeordnet werden. Verwenden Sie algebraische Datentypen, um Kerndatenstrukturen zu beschreiben. Teile diese Definitionen weit.





design architecture definition