Konzeption und Design vor dem Codieren: Wie viel ist das wahr? [geschlossen]

Ich habe in der Schule gelernt und überall gelesen, dass eine gute Entwicklungsmethode Konzeption und Design erfordert, bevor sie richtig codiert werden kann.

Das ist keine neue Information, auch für einen Programmieranfänger. Ich frage mich jedoch, ob dies ein guter Rat ist, da es mir seit Beginn meiner Entwicklung in mehreren Programmiersprachen nie gelungen ist, alles von Anfang an zu entwerfen und zu konzipieren.

Ich meine, ich habe Design, Konzeption und Programmierung immer miteinander verschmolzen. Bin ich der schlechteste Entwickler der Welt oder ist die Idee, die wir in der Schule lernen, nur ein altes bedeutungsloses religiöses Dogma?

Wie können wir überhaupt etwas konzipieren und gestalten, was wir noch nie zuvor erlebt und programmiert haben? Ist das nicht lächerlich? Führt die Programmierung nicht stattdessen die Konzeption und das Design?

Ich denke, die Antwort muss lauten: Planen Sie so viel wie möglich, aber nicht mehr.

Wenige Leute würden gegen die Tugenden der Planung sprechen, aber die Debatte übersieht meistens einen wichtigen Aspekt. Planen funktioniert nur, wenn Sie die Fähigkeit haben, einen guten Plan zu erstellen. Diese Fähigkeit ist in der Regel mit Erfahrung verbunden. Wenn Sie nicht viel Erfahrung mit einem von Ihnen erstellten Plan haben, wird dies wahrscheinlich zu erheblichen Problemen führen. Dies bedeutet, dass der Plan während der Entwicklung stark überarbeitet werden muss, um ein Produkt herzustellen, das keine totale Katastrophe darstellt. Wenn der Plan detailliert ist, werden dadurch wahrscheinlich viele Details ungültig. Schlimmer noch, Sie werden versuchen, die Anpassungen auf ein Minimum zu beschränken, um dem Plan folgen zu können.

Einige Dinge erfordern definitiv Planung, und wenn Sie nicht die Fähigkeit haben, das erforderliche Planungsniveau zu erreichen, kann ich mir nur vorstellen, Prototypen zu erstellen und Code zu schreiben, um nur die Erfahrung mit der Aufgabe zu sammeln, die für die Erstellung eines angemessenen Plans erforderlich ist .

Unabhängig davon, ob Sie zum Schreiben von Produktionscode bereit sind oder nicht: Sobald Sie Ihr maximales Planungsniveau erreicht haben, müssen Sie nur noch codieren. Vielleicht wird es eine Katastrophe, aber das sind gute Lernerfahrungen, und Sie sind viel besser gerüstet, um einen überarbeiteten Plan zu erstellen.

Es ist absolut wahr. Je größer und komplexer die Anforderung ist, desto wahrer ist dies.

Damit eine kleine Konsolen-App die Fibonacci-Sequenz berechnen kann, müssen Sie möglicherweise nicht länger als ein paar Minuten darüber nachdenken, wie der Algorithmus und die Benutzeroberfläche zu strukturieren sind (was ja einfach stdin und stdout sein kann).

Aber wie wäre es mit einer Echtzeit-Handelsplattform, die Millionen von Transaktionen pro Sekunde ausführen soll, global verteilt ist und 99,9999 Uptime und 100% Korrektheit erfordert? Würdest du einfach anfangen, das zu programmieren?

Es gibt viele andere Möglichkeiten zwischen diesen beiden Extremen.

Schauen Sie sich das Projekt Euler an . Lösen Sie einige Probleme in der angegebenen Reihenfolge. Sie werden feststellen, dass Sie überlegen müssen, bevor Sie in den Code springen, um einige der Probleme in angemessener Zeit zu lösen.

Wenn Sie sich keine Zeit nehmen müssen, um Ihr Programm zu überlegen und zu entwerfen, bevor Sie mit dem Code beginnen, arbeiten Sie entweder an trivialen Dingen oder es fehlt etwas Größeres.

Es ist mir von Anfang an nie gelungen, alles zu entwerfen und zu konzipieren

Niemand tut für irgendetwas anderes als die trivialsten Probleme. Je größer und komplexer das Projekt ist, desto wahrer ist dies - Entwürfe werden Fehler aufweisen, Dinge, die übersehen werden usw.

Die Kunst besteht darin, zuerst auf hohem Niveau zu entwerfen und zu prüfen, ob die großen Teile passen. Holen Sie sich dann eine Prioritätenliste - beginnen Sie zuerst mit der Arbeit an der wichtigsten Infrastruktur. Dann zerlegen wir die größeren Teile in kleinere Teile und stellen sicher, dass jedes größere Teil aus sinnvollen Teilen besteht.

Dies kostet Zeit und Mühe - und ist möglicherweise zu Beginn nicht vollständig oder vollständig korrekt.

Aber das ist , warum heißt es weich -ware und nicht hart -ware. Es ist formbar und kann geändert werden.

Ich habe in der Schule gelernt und überall gelesen, dass eine gute Entwicklungsmethode Konzeption und Design erfordert, bevor sie richtig codiert werden kann.

Das ist wahr.

Ich frage mich jedoch, ob dies ein guter Rat ist, da es mir seit Beginn meiner Entwicklung in mehreren Programmiersprachen nie gelungen ist, alles von Anfang an zu entwerfen und zu konzipieren .

Und da ist dein Problem.

Bei den meisten nicht trivialen Problemen müssen Sie überlegen, wie die Dinge funktionieren und wie sie zusammenpassen. Paradoxerweise können Sie bei den meisten nicht trivialen Problemen nicht alles planen . Es gibt einfach zu viel Unbekanntes, um es zu erklären, zu viel Veränderung, die während der Entwicklung auftreten wird. Agile hat die Traktion gewonnen, die es hat, weil es diese zweite Hälfte des Geschäfts akzeptiert: Die Menschen sind nicht allwissend und der Wandel ist konstant.

Es ist also sicher richtig, dass Sie Design im Voraus machen müssen, aber es ist auch wahr, dass es unmöglich ist, nur im Voraus zu entwerfen.

Sie müssen unbedingt ein Design haben, bevor Sie codieren können.

Der Grund ist ziemlich einfach - wenn Sie kein Design haben, wissen Sie nicht, was Sie machen .

Sie müssen unbedingt Code haben, bevor das Design endgültig ist.

Der Grund ist ziemlich einfach: Das Design wird sich ändern und die Entwicklung von Teilen des Designs wird Fragen, Chancen und Herausforderungen aufzeigen, die nur schwer vorhersehbar sind, ohne an der Lösung zu arbeiten.

Entwicklung ist iterativ.

Ob nach Plan oder nicht, ob das Team es realisiert oder nicht, jedes Softwareprojekt wird iterativ durchgeführt - ein Teil der Arbeit wird abgeschlossen und dann ausgewertet, und die Auswertung führt zu Änderungen in der Art und Weise, wie der Rest der Arbeit erledigt wird.

Versuchen Sie mehr als einen Ansatz.

Es erfordert Übung und Erfahrung, um den besten Weg zu finden, um das Design im Voraus mit dem Erstellen von Code in Einklang zu bringen. Es ist eine Fähigkeit, die so gut wie niemand beherrscht, und jedes Projekt wird andere Ideale haben (überlegen Sie sich, ein kleines Tool für den eigenen Gebrauch zu entwerfen, statt ein großes Einzelprodukt wie ein großes Videospiel zu entwickeln).

Ich habe in der Vergangenheit mehrere Systeme entworfen und beaufsichtigt, und ich habe gesehen, wie sich der Prozess auf viele verschiedene Arten abspielt , aber ich finde, dass die anfängliche Architektur zumindest das Vorhandensein der meisten Hauptfunktionen einplanen sollte .

Ich habe zum Beispiel ein HLK-Regelsystem gesehen, bei dem Gebäude, Fußböden, Räume usw. nicht nachgerüstet wurden, und das Ergebnis war so hässlich wie es nur geht. Oder ein mobiles Musikgerät, das aus Komponenten besteht, die besser für Ihre (nicht intelligente) Taschenuhr geeignet sind. Natürlich waren die Endprodukte in beiden Fällen nicht die Favoriten der Kunden.

Wenn Sie "Konzeption" sagen, ist dies nur ein Schritt von "Idee" entfernt, und ein Konzept kann sehr unscharf sein. Unternehmen interessieren sich normalerweise für Konzepte. Kunden interessieren sich normalerweise für UX - ein Konzept, das auf einfache und benutzerfreundliche Weise in die Realität umgesetzt wird und durch seine Verwendung einen Mehrwert bringt.

Sie müssen vor jeder Programmierung ein "Konzept" erstellen. Ich kann mir nicht vorstellen, Visual Studio (oder eine IDE Ihrer Wahl) zu öffnen und nach dem Zufallsprinzip Code zu schreiben, um zu sehen, wohin das führt.

Möglicherweise erstellen Sie vor dem Codieren kein vollständiges Design (und sollten dies auch nicht tun), aber Sie sollten eine grobe Skizze des Workflows des Benutzers haben.

UX-Design und -Coding bedingen sich oft gegenseitig, und Sie werden wahrscheinlich gezwungen sein, einen agilen Ansatz für alles andere als kleinste Projekte zu verwenden, um diese Tatsache in Ihre Herangehensweise einzubeziehen. Denken Sie also nicht, dass Sie der schlechteste Programmierer sind, wenn Sie nicht alles auf einmal sehen könnten - niemand kann es und die Leute, die glauben, sie können es, sind diejenigen, die das Problem einfach ignorieren und behaupten können, sie hätten ein vollständiges Problem Bild.

Ein Beispiel, um etwas Großem eine Größe zu geben. Konzept: "Erstellen Sie ein visuelles Cloud-basiertes Tool, mit dem Unternehmen ihre Softwareplattformen integrieren können." Das klingt großartig und man kann anfangen, Marketingmaterial zu schreiben und es zu verkaufen, bevor es überhaupt da ist. Sie müssen dies vor dem Codieren haben.

Pre-Design: "Haben Sie Formen und Pfeile wie in Visio, um die Logik zu beschreiben; haben Sie Plug-in-Fähigkeiten, um Verbindungen zu verschiedenen Plattformen (SAP, SF, Datenbanken ...) zu ermöglichen; haben Sie eine Überwachungskonsole, über die Sie Daten suchen können, die durch die haben eine Möglichkeit, Daten visuell zu beschreiben und ein Format in ein anderes umzuwandeln ". Ein weiterer großartiger Marketing-Blob. Es gibt Ihnen auch einige Ideen darüber, was wichtig ist, sollten Sie eine so grobe Skizze haben, bevor Sie auch codieren.

Design / Code: "Lassen Sie einen Browser HTML-Designer mit solchen und solchen Funktionen hosten. Codieren Sie das Backend in Java, damit es auf jedem vorhandenen Server ausgeführt werden kann. Definieren Sie Datenstrukturen und UX, um sie nach Bedarf abzufragen oder zu ändern. Planen Sie für die Notfallwiederherstellung, Fehler Berichterstellung, Audit-Protokollierung, Versionskontrolle planen, Zugriffskontrolle planen, ... "- je feiner die Liste, desto unrealistischer ist es, alles vorherzusehen.

... man sollte sich jedoch zumindest darüber im Klaren sein, wie die Dinge ungefähr aussehen könnten, oder dass Ihr Endprodukt einige wirklich nutzlose Implementierungen enthält, die das ansonsten gut klingende Konzept zunichte machen - sagen Sie, Ihr visueller Designer benötigt eine 40-Zoll-Grafikkarte. Es gibt keinen anderen Weg, die Protokolle zu durchsuchen, als eine exakte Zeichenfolgenübereinstimmung, die auf eines der 20 Felder im Protokoll usw. beschränkt ist. Es gibt keine gute Möglichkeit, dies zu verhindern, als Ihre Implementierung auszuführen - Einige werden Erfolg haben, andere werden scheitern.

Ich teile die Zeit immer wie folgt ein:

1. 1/3 Design
2. 1/3 Entwicklung
3. 1/3 Testen

Design: Nicht nur visuell, sondern auch konzeptionell. Teilen Sie es visuell und logisch in Teile. Suchen Sie nach Gemeinsamkeiten, die wiederverwendet werden und ein Designmuster für sich sind.

Entwicklung: Wenn Sie Ihre Teile kennen, codieren Sie sie. Dann integrieren Sie sie.

Testen: Es wird nicht nur getestet, ob der Code richtig integriert und geschrieben wurde, sondern es werden auch Erkenntnisse und Lehren gezogen, und es werden neue Wege zur Interaktion geschaffen, neue Fähigkeiten werden erdacht und gewünscht. Vorsicht vor Scope Creep.

Beachten Sie zusätzlich zu diesen Aspekten, dass ein Projekt zusätzlich zu diesen Phasen drei Phasen umfasst.

1. Der unterentwickelte erste Versuch
2. Der überarbeitete zweite Versuch, aus den Lehren des ersten Versuchs.
3. Der richtig konstruierte 3. Versuch.

Ich habe festgestellt, dass je besser Sie die Entwurfsphase durchführen, desto weniger zusätzliche Versuche erforderlich sind. Anstatt das Ganze noch einmal zu machen, haben Sie möglicherweise nur ein Subsystem, das überarbeitet wird.

Ich bin Softwareentwickler und Softwareentwicklungsmanager für Inhouse-, Outsourcing- und Offshore-Entwicklungsprojekte.

Hier gibt es eine grundlegend falsche Annahme. Sie werden niemals in der Lage sein, ein gutes Design zu entwickeln, ohne vorher Code zu schreiben (die Schule wird Ihnen dies niemals beibringen). Die Schule hat jedoch Recht, dass man ohne Design keinen guten Code bekommt.

Die Lösung ist:

1. Schreiben Sie Code, von dem Sie glauben, dass er das Problem löst.
2. Überlegen Sie sich ein Design, das auf dem basiert, was Sie aus dem Code gelernt haben.
3. Werfen Sie den gesamten Code weg und schreiben Sie ihn je nach Entwurf von Grund auf neu.
4. Wiederholen Sie diesen Vorgang nach Bedarf.

Das Wegwerfen des gesamten Codes ist kein optionaler Schritt in diesem Prozess, bei kleinen Projekten kann es jedoch sein, dass das Design formal geschrieben wird. Bei großen Projekten wiederholen Sie mit größerer Wahrscheinlichkeit den Schritt "Den gesamten Code wegwerfen ". Wenn Sie jedoch über eine ausreichende Modularität verfügen, gilt dies möglicherweise nur für einen Teil der Codebasis.

Viel zu viele Projekte behalten ihren alten Code bei, weil sie ihn nicht ändern wollen - oder weil er zu kompliziert ist, weil er nie zum Wegwerfen gedacht war. Die Tatsache anzuerkennen, dass Ihr erster Versuch ein Fehlschlag sein wird, wird Ihr Leben viel besser machen.

Konzeption ist der Schlüssel Design kann immer geändert werden Die Programmierung muss den Anforderungen der vollständig konzipierten App entsprechen.

1. Worauf kommt es an, 2. Wie muss darauf zugegriffen werden? 3. Wer ist der Benutzer? und wie jede Funktion, die Sie hinzufügen, funktioniert.

Bevor Sie Entscheidungen bezüglich der Architektur Ihrer Web-App treffen, sollten Sie diese vollständig planen und durchdenken.

Wählen Sie dann den besten Stapel

Ich bin ein LAMP-Entwickler

Daher neige ich dazu, die Frage auf das PHP-Framework einzugrenzen, das ich verwenden werde. und die Front-End-Skripte, die ich brauche, damit es all die Dinge tut, für die ich es brauche, auf ideale Weise

Um dies hinzuzufügen, lernen Sie die Verwendung von MVC-Frameworks. ZEND und CAKEPHP sind die besten Frameworks für schnelle Entwicklung (PHP).