Design & Codierung – von oben nach unten oder von unten nach oben?[geschlossen]

StackOverflow https://stackoverflow.com/questions/130933

  •  02-07-2019
  •  | 
  •  

Frage

Was ist Ihrer Erfahrung nach beim Codieren ein besserer Ansatz?

  1. Teilen Sie das Problem in ausreichend kleine Teile auf und implementieren Sie dann jeden Teil.
  2. Brechen Sie das Problem herunter, setzen Sie es dann jedoch von oben nach unten um.
  3. Irgendwelche anderen?
War es hilfreich?

Lösung

Folgendes mache ich:

Verstehen Sie zuerst die Domäne.Verstehen Sie das zu lösende Problem.Stellen Sie sicher, dass Sie und der Kunde (auch wenn dieser Kunde Sie sind!) sich darüber einig sind, welches Problem gelöst werden soll.

Dann wird eine allgemeine Lösung für das Problem vorgeschlagen und daraus wird sich das Design in Blasen oder Aufzählungszeichen auf einer Seite oder was auch immer verwandeln, aber der Punkt ist, dass es in Komponenten zerfällt, die entworfen werden können.

An diesem Punkt schreibe ich Tests für die noch zu schreibenden Klassen und konkretisiere dann die Klassen, um diese Tests zu bestehen.

Ich verwende einen Test-First-Ansatz und baue funktionierende, getestete Komponenten.Das ist es, was für mich funktioniert.Wenn die Komponentenschnittstellen bekannt sind und die „Regeln“ dafür bekannt sind, wie sie miteinander kommunizieren und einander Dienste bereitstellen, wird es im Allgemeinen zu einer einfachen Übung, „alles zusammenzufügen“.

So mache ich es und es hat bei mir gut funktioniert.

Andere Tipps

Ich neige dazu, Top-down- und Bottom-up-Umsetzung zu entwerfen.

Für die Umsetzung, den Bau der kleinsten funktionalen Stücke und sie in die übergeordneten Strukturen zusammenbauen scheint zu sein, was für mich am besten funktioniert. Aber für Design, muß ich aus dem Gesamtbild starten und es zu brechen, um zu bestimmen, was diese Stücke werden.

Sie können das über Agile Manifest zu suchen. Von oben nach unten und von unten nach oben sind ausgesagt auf Built It All At Once Design und Konstruktion.

Die „Arbeits Software über eine umfassende Dokumentation“ bedeutet, dass das erste, was Sie die kleinste nützliche Sache bauen Sie laufen lassen können. Oben? Unterseite? Weder.

Als ich jünger war, arbeitete ich Projekte, die waren - vertraglich - strikt von oben nach unten. Das funktioniert nicht. Tatsächlich kann es nicht funktionieren. Sie erhalten Berge von redundantem Design und Code als Ergebnis. Es war kein vernünftiger Ansatz, wenn gedankenlos angewendet wird.

Was habe ich bemerkt, dass die Agile Ansatz - kleine Stücke, die funktionieren - neigt dazu, das Problem auf Teile zu brechen, die auf einmal erfasst werden kann. Das Top-down- / Bottom-up nicht mehr wichtig, wie viel. Tatsächlich kann es keine Rolle.

Das führt tun: „Wie kann man für Agile Entwicklung zersetzen“ Der Trick ist, zu vermeiden, die Schaffung eine große Sache , die Sie müssen dann zersetzen. Wenn Sie ein Problem analysieren, finden Sie Akteure versuchen, Anwendungsfälle zu erreichen und scheitern, weil sie nicht alle Informationen haben, oder sie es nicht rechtzeitig, oder sie können ihre Entscheidungen nicht ausführen, oder so ähnlich.

Oft sind diese nicht große Sachen, die Zersetzung benötigen. Rückwärts Richtung, wenn sie sind, müssen Sie in den Ziele durch das Problem umgehen. Von Toren, um die Dinge, die Sie ermöglichen, um dieses Ziel, um die Dinge, die die Enabler ermöglichen usw. Da Ziele oft große Dinge sind, geht die Tendenz Top Down zu sein - von den allgemeinen Geschäftsziel zu detailliertem Geschäftsprozess und Schritt

.

An einem gewissen Punkt Übersicht wir diese verschiedenen Schritte, die zu den Zielen führen. Wir haben die Analyse Teil (Brechen Dinge nach unten) durchgeführt. Jetzt kommt der Syntheseteil: wir wieder zusammenzusetzen, was wir in die Dinge haben wir tatsächlich bauen können. Synthese ist unten nach oben. Aber lassen Sie uns nicht mitreißen. Wir haben mehrere Gesichtspunkte, von denen jeder anders ist.

Wir haben ein Modell. Dies wird oft von Details in einem größeren konzeptionellen Modell gebaut. Dann manchmal zerlegt wieder in ein Modell für OLTP normalisiert. Oder zerlegt in einem Sternschema für OLAP normalisiert. Dann arbeiten wir wieder auf ein ORM-Mapping aus dem normalisierten Modell zu erstellen. Auf - Ab -. Nach oben

Wir haben die Verarbeitung. Dies wird oft von Zusammenfassungen der Geschäftsprozesse bis in Details von Verarbeitungsschritten aufgebaut. Dann wird Software rund um die Schritte entworfen. Dann wird die Software in Klassen und Methoden gebrochen. Down - Up -. Ab

[ Exkurs . Mit aufgeklärten Benutzer definiert diese Zersetzung neue Berufsbezeichnungen und Arbeitsweisen. Mit unaufgeklärten Benutzer, bleiben die alten Arbeitsplätze und wir schreiben Berge von Unterlagen alten Jobs auf neue Software abzubilden.]

Wir haben Komponenten. Wir sehen oft an den Stücken, schauen, was wir wissen über die verfügbaren Komponenten und machen eine Art Matching. Dies ist der Prozess randomest; es ist die Art und Weise Kristalle bildet verwandt - es gibt Zentren der Keimbildung und das Design Art Erstarren um diese Zentren. Internetdienste. Datenbank. Transaktionsmanagement. Performance. Volumen. Verschiedene Funktionen, die uns irgendwie Komponenten helfen zu holen, die einige oder alle unsere Lösung implementieren. Oft fühlt sich von unten nach oben (von Feature-Produkt), aber manchmal top-down ( „Ich habe einen Hammer bin halten, rufen Sie alles, was einen Nagel“ == das RDBMS für alles verwendet werden.)

Schließlich müssen wir codieren. Dies ist von unten nach oben. So'ne Art. Sie müssen eine Paketstruktur definieren. Sie müssen Klassen als Ganzes definieren. Dieser Teil war von oben nach unten. Sie müssen Methoden innerhalb der Klassen schreiben. Ich mache oft dieses von unten nach oben - rau aus dem Verfahren, einen Komponententest schreiben, wobei das Verfahren beenden. Raute das nächste Verfahren aus, einen Komponententest schreiben, das Verfahren beenden.

Das Antriebsprinzip ist Agile - etwas bauen, das funktioniert. Die Details sind alle over die Karte -. nach oben, unten, vorne, hinten, Daten, Verfahren, Schauspieler, Themenbereich, Business-Wert

Ja. Sind all diese Dinge.

Es kann sarkastisch scheinen (sorry, ich zurückkehren zu bilden), aber dies ist wirklich ein Fall, in dem es keine richtige Antwort ist.

Auch in der agilen Art und Weise, schreiben Sie Ihren Test (s) zuerst!

Dann werden alle Software ist ein kontinuierlicher Zyklus von

  • Red - der Code schlägt der Test fehl
  • Green - der Code übergibt den Test
  • Umgestalten - Code-Verbesserungen, die Absicht erhaltend sind
    • .

Defekte, neue Funktionen, Änderungen. Das alles folgt das gleiche Muster.

Ihre zweite Option ist ein vernünftiger Weg zu gehen. Wenn Sie das Problem in verständliche Stücke brechen, wird die Top-down-Ansatz alle wichtigen Konstruktionsfehler aufdecken, bevor Sie all die kleinen Details implementieren. Sie können Stubs für niedrigere Level-Funktionalität schreiben alles zu halten, hängen zusammen.

Ich denke, es gibt noch mehr zu berücksichtigen als Top-Vers Bottom-Down-Design. Sie müssen natürlich das Design brechen in überschaubare Einheiten der Arbeit, aber Sie müssen auch die Priorisierung usw. berücksichtigen und in einem iterativen Entwicklungsprojekt, werden Sie oft das Problem für die nächste Iteration neu zu definieren, sobald Sie die Lösung für die vorherigen geliefert haben .

Bei der Gestaltung, wie ich Mitte-out zu tun. Ich mag die Domain modellieren, dann die Klassen-Entwurf, von dort in die Datenbank und Benutzeroberfläche bewegen. Wenn es spezifische Funktionen, die UI-basiert sind oder Datenbank-basiert, kann ich den Design vorne als auch.

Bei der Codierung, ich in der Regel von unten nach oben wie (Datenbank zuerst, dann Geschäftseinheiten, dann UI) zu tun, wenn überhaupt möglich. Ich finde es viel einfacher ist, die Dinge gerade mit dieser Methode zu halten.

Ich glaube, dass mit einem guten Software-Designern (und meiner Meinung nach all Software-Entwickler auch Software-Entwickler auf einem gewissen Ebene sein soll), die Magie ist in der Lage zu sein Top-down- und Bottom-up gleichzeitig zu tun.

Was ich „geschult“ wurde von meiner Mentoren zu tun ist durch sehr kurze top-down beginnen die Einheiten beteiligt sind, dann zu bewegen, um von unten nach oben zu verstehen, die grundlegenden Elemente I, dann erstellen möchten, um herauszufinden, zu sichern und sehen, wie ich gehen kann eine Ebene nach unten, zu wissen, was ich weiß, über die Ergebnisse meines unten nach oben, und so weiter, bis „sie treffen sich in der Mitte“.

Ich hoffe, das hilft.

Outside-in-Design.

Sie beginnen mit dem, was Sie versuchen, am oberen Ende zu erreichen, und Sie wissen, was Sie haben am unteren Ende mit zu arbeiten. Halten Sie arbeiten beide Enden, bis sie in der Mitte treffen.

Ich bin damit einverstanden Art mit all den Menschen, die sagen „weder“, aber jeder fällt irgendwo auf dem Spektrum.

Ich bin eher eine Top-down-Art von Kerl. Ich nehme ein hohes Niveau Merkmal / Punkt / was auch immer und es als ein komplettes Programm zu implementieren. Auf diese Weise können Sie mir einen grundlegenden Plan und Struktur innerhalb der Grenzen des Problemgebietes skizziere.

Dann beginne ich mit einer anderen Funktion und Refactoring aus alles aus dem Original, das von den zweiten in dem neuen, gemeinsamen Einrichtungen verwendet werden kann. Lather, spülen, wiederholen, bis Antrag vollständig ist.

Allerdings weiß ich eine Menge Leute, die von unten nach oben Jungs sind, die ein Problem hören und sich Gedanken über die alle Unterstützung Subsysteme, die sie benötigen, könnte die Anwendung auf es zu bauen.

Ich glaube nicht, dass entweder Ansatz ist falsch oder richtig. Beide können Ergebnisse erzielen. Ich selbst versuchen und Bottom-up-Leute zu finden, mit zu arbeiten, wie wir das Problem aus zwei unterschiedlichen Perspektiven angreifen kann.

Beide sind gültig Ansätze. Manchmal nur „fühlt“ ein natürlicher, als die andere. Allerdings gibt es ein großes Problem: einige Mainstream-Sprachen und vor allem ihrer Frameworks und Bibliotheken wirklich stark auf IDE-Unterstützung, wie Syntaxhervorhebung, Hintergrund Typprüfung, Hintergrund Kompilierung, Intellisense, IntelliSense und so weiter .

Allerdings das funktioniert nicht mit Top-down-Codierung! In Top-down-Codierung, Sie ständig Variablen, Felder, Konstanten, Funktionen, Verfahren, Methoden, Klassen, Module, Züge nutzen, Mixins, Aspekte, die Pakete und Typen , die Sie noch nicht umgesetzt haben! Also, die IDE wird dich ständig schreien aufgrund von Fehlern kompilieren, da überall rote Wellenlinien sein wird, werden Sie keine Code-Vervollständigung erhalten und so weiter. Also, die IDE ziemlich verbietet Sie tun Top-down-Codierung.

Ich habe eine Variante der Top-down. Ich neige dazu, zu versuchen, die Schnittstelle zuerst zu tun - ich dann, dass als meine Liste der Funktionen. Was ist gut über diese Version, es funktioniert immer noch mit IDE, die sonst beschweren würde. kommentieren Sie einfach den einen Funktionsaufruf zu dem, was noch nicht umgesetzt worden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top