Top-down ist eine großartige Möglichkeit, um Dinge zu beschreiben, die Sie kennen, oder um Dinge, die Sie bereits erstellt haben, neu zu erstellen.
Das größte Problem von oben nach unten ist, dass es oft einfach kein "oben" gibt. Sie werden Ihre Meinung darüber ändern, was das System tun soll, während Sie das System entwickeln und die Domäne erkunden. Wie kann Ihr Ausgangspunkt etwas sein, das Sie nicht kennen (dh was das System tun soll)?
Ein "lokales" Top-Down ist eine gute Sache ... einige Überlegungen vor dem Codieren sind eindeutig gut. Aber zu viel zu denken und zu planen ist nicht so, denn was Sie sich vorstellen, ist nicht das reale Szenario (es sei denn, Sie waren bereits vorher dort, dh wenn Sie nicht bauen, sondern umbauen). Globales Top-Down beim Bauen neuer Dinge ist einfach Unsinn.
Bottom-up sollte (global) der Ansatz sein, es sei denn, Sie kennen 100% des Problems, Sie müssen nur die bekannte Lösung codieren und es interessiert Sie nicht, nach möglichen alternativen Lösungen zu suchen.
Lisp-Ansatz ist das destillierte Bottom-up. Sie bauen nicht nur von unten nach oben, sondern können die Steine auch so formen, wie Sie es möchten. Nichts ist festgelegt, Freiheit ist total. Natürlich übernimmt Freiheit Verantwortung und Sie können schreckliche Dinge tun, indem Sie diese Macht missbrauchen.
Aber schrecklicher Code kann in jeder Sprache geschrieben werden. Selbst in Sprachen, die wie Käfige für den Verstand geformt sind, mit der Hoffnung entworfen, dass mit diesen Sprachen sogar Affen gute Programme zum Laufen bringen könnten (eine Idee, die auf so vielen Ebenen so falsch ist, dass es weh tut, wenn man nur daran denkt).
In Ihrem Beispiel geht es um einen Webserver. Nun, im Jahr 2012 ist dies ein genau definiertes Problem. Sie müssen die Spezifikationen befolgen. Ein Webserver ist nur ein Implementierungsproblem. Vor allem, wenn Sie einen Webserver schreiben möchten, der im Wesentlichen mit den meisten anderen Webservern identisch ist, ist nichts wirklich unklar, außer ein paar Details. Selbst in Ihrem Kommentar zu RSA geht es immer noch um ein klar definiertes Problem mit formalen Spezifikationen.
Bei einem genau definierten Problem, mit formalen Spezifikationen und bereits bekannten Lösungen ist die Codierung nur eine Verbindung in den Punkten. Top down ist dafür ok. Dies ist der Himmel für Projektmanager.
In vielen Fällen gibt es jedoch keinen bekannten Ansatz, um die Punkte zu verbinden. Eigentlich ist sehr oft schwer zu sagen, was die Punkte sind.
Angenommen, Sie werden aufgefordert, eine automatische Schneidemaschine anzuweisen, die zu schneidenden Teile auf ein Druckmaterial auszurichten, das nicht perfekt mit dem sich wiederholenden theoretischen Logo übereinstimmt. Sie erhalten die Teile und Bilder des Materials, wie sie von der Maschine aufgenommen wurden.
Was ist eine Ausrichtungsregel? Du entscheidest. Was ist ein Muster, wie kann es dargestellt werden? Du entscheidest. Wie werden die Teile ausgerichtet? Du entscheidest. Können Teile "gebogen" werden? Es kommt darauf an, manche nicht und manche ja, aber natürlich nicht zu viel. Was tun, wenn das Material einfach zu deformiert ist, als dass ein Teil es akzeptabel schneiden könnte? Du entscheidest. Sind alle Materialrollen identisch? Natürlich nicht, aber Sie können den Benutzer nicht daran hindern, Ausrichtungsregeln für jede Rolle anzupassen ... das wäre unpraktisch. Welche Bilder sehen die Kameras? Das Material, was auch immer das bedeuten mag ... es kann Farbe sein, es kann schwarz über schwarz sein, wo nur der Lichtreflex das Muster sichtbar macht. Was bedeutet es , ein Muster zu erkennen? Du entscheidest.
Versuchen Sie nun, die allgemeine Struktur einer Lösung für dieses Problem zu entwerfen und ein Angebot in Geld und Zeit abzugeben. Ich wette, dass sogar Ihre Systemarchitektur (ja, die Architektur) falsch sein wird. Kosten- und Zeitschätzung sind Zufallszahlen.
Wir haben es implementiert und jetzt ist es ein funktionierendes System, aber wir haben uns sehr oft über die Form des Systems Gedanken gemacht. Wir haben ganze Subsysteme hinzugefügt, die jetzt nicht einmal über die Menüs erreichbar sind. Wir haben die Master / Slave-Rollen in Protokollen mehr als einmal gewechselt. Wahrscheinlich haben wir jetzt genug Wissen, um versuchen zu können, es besser wieder aufzubauen.
Andere Unternehmen haben natürlich das gleiche Problem gelöst ... aber wenn Sie nicht zu einem dieser Unternehmen gehören, wird Ihr detailliertes Top-Down-Projekt höchstwahrscheinlich ein Witz sein. Wir können es von oben nach unten gestalten. Das kannst du nicht, weil du es noch nie getan hast.
Sie können wahrscheinlich das gleiche Problem auch lösen. Von unten nach oben arbeiten. Angefangen mit dem, was Sie wissen, über das, was Sie nicht wissen, bis hin zur Summe.
Neue komplexe Softwaresysteme werden angebaut, nicht entworfen. Von Zeit zu Zeit beginnt jemand damit, ein großes neues komplexes falsch spezifiziertes Softwaresystem von Grund auf neu zu entwerfen (beachten Sie, dass es bei einem großen komplexen Softwareprojekt nur drei Möglichkeiten gibt: a) Die Spezifikation ist unscharf, b) Die Spezifikation ist falsch und widerspricht sich von selbst oder c] beides ... und am häufigsten ist [c] der Fall).
Dies sind die typischen Großunternehmensprojekte, bei denen Tausende und Abertausende von Stunden allein in PowerPoint-Folien und UML-Diagrammen investiert werden. Sie versagen ausnahmslos vollständig, nachdem sie peinliche Mengen an Ressourcen verbrannt haben ... oder in ganz besonderen Ausnahmefällen liefern sie schließlich eine überteuerte Software, die nur einen winzigen Teil der anfänglichen Spezifikationen implementiert. Und diese Software wird von den Benutzern ausnahmslos sehr gehasst ... nicht die Art von Software, die Sie kaufen würden, sondern die Art von Software, die Sie verwenden, weil Sie dazu gezwungen werden.
Bedeutet das, dass ich denke, dass Sie nur an Code denken sollten? Natürlich nicht. Aber meiner Meinung nach sollte die Konstruktion von unten beginnen (Ziegel, Betoncode) und nach oben gehen ... und Ihre Aufmerksamkeit und Liebe zum Detail sollte in gewisser Weise "verblassen", wenn Sie weiter von dem entfernt sind, was Sie haben. Top-down wird häufig so dargestellt, als müsste das gesamte System auf einmal auf die gleiche Detailebene gebracht werden: Teilen Sie einfach jeden Knoten so lange auf, bis alles offensichtlich ist. In Realitätsmodulen werden Subsysteme aus Subroutinen "gewachsen". Wenn Sie noch keine Erfahrung mit dem spezifischen Problem haben, ist Ihr Top-Down-Design eines Subsystems, Moduls oder einer Bibliothek schrecklich. Sie können eine gute Bibliothek entwerfen, wenn Sie wissen, welche Funktionen eingefügt werden müssen, und nicht umgekehrt.
Viele der Lisp-Ideen werden immer beliebter (erstklassige Funktionen, Abschlüsse, dynamisches Tippen als Standard, Garbage Collection, Metaprogrammierung, interaktive Entwicklung), aber Lisp ist (unter den mir bekannten Sprachen) immer noch einzigartig, wie einfach es ist, Code zu formen für was du brauchst.
Schlüsselwortparameter zum Beispiel sind bereits vorhanden, aber wenn sie nicht vorhanden sind, können sie hinzugefügt werden. Ich habe es (einschließlich der Schlüsselwortüberprüfung zur Kompilierungszeit) für einen Spielzeug-Lisp-Compiler gemacht, mit dem ich experimentiere, und es erfordert nicht viel Code.
Mit C ++ erhalten Sie stattdessen nur eine Reihe von C ++ - Experten, die Ihnen mitteilen, dass Schlüsselwortparameter nicht so nützlich sind, oder eine unglaublich komplexe, fehlerhafte, halb-unterstützte Template-Implementierung, die in der Tat nicht so nützlich ist. Sind C ++ Klassen erstklassige Objekte? Nein, und Sie können nichts dagegen tun. Können Sie zur Laufzeit oder zur Kompilierungszeit eine Introspektion durchführen? Nein, und Sie können nichts dagegen tun.
Diese Sprachflexibilität von Lisp macht es großartig für das Bottom-up-Bauen. Sie können nicht nur Unterprogramme erstellen, sondern auch die Syntax und die Semantik der Sprache. Und in gewisser Hinsicht ist Lisp selbst von unten nach oben.