Sollte man Pseudocode vor dem eigentlichen Codieren verwenden?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/12683

  •  16-10-2019
  •  | 
  •  

Frage

Pseudocode hilft uns, Aufgaben sprachunabhängig zu verstehen.Ist es eine bewährte Vorgehensweise oder ein empfohlener Ansatz, die Erstellung von Pseudocode als Teil des Entwicklungslebenszyklus durchzuführen?Zum Beispiel:

  • Identifizieren und teilen Sie die Codierungsaufgaben auf
  • Pseudocode schreiben
  • Lassen Sie es genehmigen [von PL oder TL]
  • Beginnen Sie mit der Codierung basierend auf Pseudocode

Ist dies ein empfohlener Ansatz?Wird es in der Branche praktiziert?

War es hilfreich?

Lösung

Das Schreiben von Pseudocode vor dem Codieren ist sicherlich besser als nur das Codieren ohne Planung, aber es ist weit davon entfernt, eine beste Praxis zu sein. Die testgetriebene Entwicklung ist eine Verbesserung.

Noch besser ist es, die Problemdomänen- und Designlösungen mithilfe von Techniken wie Benutzergeschichten, Anwendungsfällen, CRC -Karten, Diagramme, wie durch Methoden wie Reinraum, Rup, Lean, Kanban, Agile usw., analysieren, wie sie eingesetzt werden.

Die Art des Problems und die Komponenten, die Sie zur Implementierung der Lösung verwenden, gründlich zu verstehen, ist das Prinzip für Best Practices.

Andere Tipps

Ich verwende Kommentare als eine Art Pseudocode mit sehr hoher Ebene, da ich die Kommentare schreibe, bevor ich den Code schreibe. Ich finde, dass das Denken durch das gesamte Problem, auch auf hoher Ebene, meinen Code erheblich verbessert.

Nein, nicht zuerst Pseudo-Code

Das ist zu viel Overhead. Sie machen die Arbeit, die Logik mit keinen der Vorteile zu schreiben. Ich würde stattdessen eine der folgenden folgenden vorschlagen:

  1. Prototyp in der Sprache, mit der Sie versenden werden (auch bekannt als (auch bekannt als Schreiben Sie einen, um wegzuwerfen)
  2. Architekturdiagramme mit Code -Ausschnitten zum Testen von Annahmen / Schlüsseldesigns
  3. Testgetriebene Entwicklung, bei der Sie zuerst Ihre Schnittstellen/Codestruktur schreiben, gefolgt von Tests, gefolgt von der Implementierung des Codes.

Alle drei bewegen Sie im Gegensatz zu Pseudo-Code direkt in Ihre Lösung. Persönlich neige ich dazu, Techniken 1 oder 2 je nach Teamgröße zu verwenden. Für kleinere (z. B. 5 Personen oder weniger) Teams funktioniert das Prototyping sehr gut. Für größere Teams, in denen mehrere Gruppen von Entwicklern parallel arbeiten, habe ich festgestellt, dass die frühzeitige Dokumentation, die von Technik 2 erstellt wurde, gut funktioniert, da Sie etwas zu Beginn zu diskutieren und Ihnen dabei helfen, Komponentengrenzen besser zu definieren. Ich bin mir sicher, dass TDD auch sehr gut funktionieren würde, aber ich muss noch in einem Team arbeiten, das sich für diesen Prozess verpflichtet hatte.

Meiner Meinung nach hat Pseudo-Code nur zwei gültige Zwecke:

(1) Für Programmierstudenten, die die Konzepte von Modularität und Algorithmen lernen müssen, aber eine Programmiersprache noch fließend fließen.

(2) zu kommunizieren, wie etwas einer nicht-technischen Person wirkt, oder nur aus Gründen der Zweckmäßigkeit in einem Treffen mit White-Board-Typ.

Ist Pseudo-Code ein vorgeschlagener Ansatz? Für Anfänger sage ich ja. Es hilft dem neuen Programmierer zu lernen, wie man ein Problem in Code übersetzt, ohne sich über die genaue Syntax der Sprache zu sorgen. Dies prägt den Denkprozess und kann dazu beitragen, nützliche Gewohnheiten einzubeziehen (und ich nehme an, auch schlechte Gewohnheiten). Deshalb wird es in Schulen so sehr verwendet.

Ist es in der Industrie praktiziert? Nach meiner Erfahrung nein. Niemand hat die Zeit, das Projekt zwischen den Dokumentation (Anforderungen, Spezifikationen, Story -Boards, Anwendungsfällen oder was auch immer sie zu verwenden) und dem tatsächlichen Code zu überzeugen. Es wird allgemein angenommen, dass bereits ausreichend Denken in das Problem vor dem Code-Grünen in das Problem geraten wurde. Zu diesem Zeitpunkt ist das Codieren des Projekts wichtiger als eine weitere Schicht für die Konstruktionsvorbereitung.

Ich würde auf jeden Fall Pseudocode empfehlen. Es hilft Ihnen, zu klären, was Sie tun werden, und Elemente zu identifizieren, die Sie möglicherweise vergessen haben oder potenzielle Probleme. Es ist viel einfacher/schneller, Ihren Code zu beheben, wenn er sich noch in der Planungsphase befindet, anstatt zu warten, bis Sie bereits einen großen Teil davon codiert haben.

Pseudocode kann nützlich sein, wenn Sie mit der Sprache nicht vertraut sind oder wenn Sie mentale Kontexte ändern müssen. In der seltenen Gelegenheit, dass ich Pseudocode schreibe, ist es auf Papier. Manchmal können Sie einfach Ihre Hände von der Tastatur nehmen und auf Papier kritzeln, um einen mentalen Block zu umgehen.

Aber als formalisierter Teil des Entwicklungsprozesses? Auf keinen Fall. Es ist ein sporadisch hilfreiches Werkzeug für Einzelpersonen. Es gibt bessere Möglichkeiten, "zu wissen, was Sie schreiben, bevor Sie es schreiben", wie:

  1. Definieren Sie den Vertrag (Pre/Post/Invariante -Bedingungen) der Methode, bevor Sie beginnen
  2. Tdd
  3. 1 und 2 kombiniert (Schreiben von Tests zur Ausführung des Vertrags)

Ich würde auch vorschlagen, dass eine Genehmigung, bevor Sie mit dem Schreiben von Code beginnen, viel mehr Ärger verursachen, als es wert ist. Entwurfsbewertungen (Vor-Implementierung) können nützlich sein, müssen jedoch auf einer höheren Ebene als einzelne Algorithmen sein.

Ich werde mit den vorherigen Antworten nicht einverstanden und nein sagen, aber mit einer Einschränkung: Sie können Psuedocode nur dann loswerden, wenn Sie sich fieberhaft mit der Umgestaltung Ihres Codes widmen, um mit Problemen zu befassen, die sich aufnehmen. PSUDOCODE ist nach seiner Essenz eine Möglichkeit, Ihren Code zu definieren, bevor Sie Ihren Code definieren. Es ist in vielen Umständen eine unnötige Abstraktion, und da Ihr Code beim ersten Mal niemals perfekt sein wird (und wahrscheinlich nicht dem Design des Nsuedocode bis zur Fertigstellung folgen wird), scheint es mir fremd.

Wenn Sie COBOL oder C schreiben, kann Pseudocode hilfreich sein, da das Schreiben des tatsächlichen Codes viel länger dauert. Wenn Sie Ihren Algorithmus/Ihre Anforderungen über den Pseudocode überprüfen können, können Sie einige Zeit sparen.

In moderneren Sprachen macht Pseudocode nicht so viel Sinn. Was besser funktionieren würde, ist das Schreiben von Methodenstubs und das Ausfüllen der obersten Logik und so detailliert wie erforderlich, um den Algorithmus und die Anforderungen zu überprüfen, all dies im tatsächlichen Code. Sie können dann diesen Code für die Genehmigung des Teams zeigen und Ihren echten Code bereits beginnen lassen.

Die einzigen Male, in denen ich in den letzten 10 Jahren Pseudocode verwendet habe, sind im Interview, wenn wir an einem Whiteboard arbeiten und die jeweilige Sprache keine Rolle spielt.

Es ist sicherlich hilfreich, um einen Prozess/Algorithmus in lockerer Begriffe zu unterhalten, ohne sich mit Syntax festzuhalten. ZB zum Schreiben einer C ++ - Klasse, die C# Eigenschaften hat, nur um den Punkt zu veranschaulichen.

Es hat seinen Platz, sollte aber nur bei Bedarf verwendet werden (es ist Arbeit, die Sie wegwerfen werden) und sicherlich nicht Teil eines formellen Prozesses, es sei denn, Sie haben ISO-Typ-Standards, die darauf bestehen.

Für mich und die Menschen, mit denen ich in den letzten Jahren zusammengearbeitet habe, hat sich Pseudocode ziemlich in nicht ganz perfekten echten Code verwandelt. Wenn Sie nicht gleichzeitig mit vielen Sprachen zusammenarbeiten, scheinen die meisten Menschen im allgemeinen Muster ihrer Hauptsprache zu denken. Ich habe eine Weile in .NET -Läden gearbeitet, sodass die meisten Leute von den meisten Menschen im Büro in der Regel wie VB oder C# aussehen, wobei einige der Interpunktion fehlen.

Die Übung ist immer noch wertvoll, wenn Sie Optionen und dergleichen diskutieren, aber die agnostische Sprache tendiert dazu, sich zu entfernen, wenn Sie mehr Zeit mit ein paar Sprachen verbringen.

Pseudocode wird immer mehr grafisch mit Tools wie UML geschrieben. Probieren Sie zum Beispiel aus yuml.

Ein Online -Tool zum Erstellen und Veröffentlichen einfacher UML -Diagramme. Es macht es Ihnen sehr einfach:

  • Einbetten Sie UML -Diagramme in Blogs, E -Mails und Wikis ein.
  • Post UML -Diagramme in Foren und Blog -Kommentaren.
  • Verwenden Sie direkt in Ihrem webbasierten Fehler -Tracking -Tool.
  • Kopieren und fügen Sie UML -Diagramme in MS -Wortdokumente und PowerPoint -Präsentationen ein ...

... Yuml spart dir Zeit. Es ist für diejenigen konzipiert, die kleine UML -Diagramme und Skizzen erstellen.

Ohne yuml kann das Erstellen eines UML -Diagramms das Laden eines UML -Tools, das Erstellen eines Diagramms, das Verleih eines Namens, das Fummeln mit Layout, das Exportieren in Bitmap und das höhere Online -Hochladen irgendwo. Yuml lässt dich nichts davon tun ...

Gute Arbeit. Sie haben eine gute Diskussion begonnen. Nach mir schrieb ich Pseudocodes, als ich Programmierung lernte, um die verschiedenen Loops und Algorithmen zu verstehen. Dies war vor eineinhalb Jahrzehnten mehr. Sogar Programmiersprachen waren nicht viel leistungsfähig ... und eine ereignisgesteuerte Programmierung war die Zukunft. Jetzt mit 4GLS und 5GLS denken wir in der Sprache selbst und nicht in einfachem Englisch. Wenn wir an ein Problem denken, denken wir an Objekte und Operationen. Und bis es sich um ein komplexes Algo handelt, macht das Schreiben von Pseudocodes (oder Pseu-Do-Codes, nur ein Scherz) keinen Sinn. Besser, die Lösung grafisch darstellen.

Hängt von der verwendeten Sprache und Ihrer Vertrautheit damit ab.

Viele moderne Sprachen wie Python oder Java sind bereits so nahe an Pseudocode, dass das Schreiben eines Ad -hoc -Pseudocode zuerst verschwenderisch ist, IMHO. Mach es besser einfach mit dem Tracer -Kugel sich nähern.

Es ist ein anderer Deal, wenn Sie etwas niedrigem Niveau, nahe Metal-Dinge herstellen oder mit der Sprache, die Sie verwenden, noch nicht vertraut sind. Dann kann Pseudocode definitiv nützlich sein.

Es gibt ein paar Umstände, unter denen in meiner Arbeit Pseudocode zum Vorschein kommt, und zwar im akademischen Bereich, wo die Programmierung eher als Werkzeug oder als „Und jetzt lösen wir es“-Einsatz mitten in einem Projekt verwendet wird:

  1. Wenn der Code für ein tatsächliches Verständnis dessen, was passieren wird, kontraproduktiver ist als Pseudocode.SAS zum Beispiel wird die Hälfte des Whiteboards einnehmen und einige ziemlich einfache Programmieraufgaben erledigen.Siehe auch C, das einige andere Poster besprochen haben.
  2. Da viele Datenanalysen und Statistikcodierungen durchgeführt werden, wird bei der Generierung der Ergebnisse oft viel am Code herumgebastelt.Pseudocode ist etwas einfacher zu verwenden für „Hier liegt ein Hin- und Her-Prozess, wenn die Diagnosedarstellung nicht richtig aussieht, versuchen Sie es mit X“.
  3. Die Studierenden lernen viele verschiedene Programmiersprachen.Bei Leuten, die ich kenne, könnte beispielsweise ein Statistikproblem in SAS, R oder Stata analysiert werden.Etwas, das etwas erfordert, das näher an der traditionellen Programmierung liegt, könnte in R, Matlab, C, C++, Java, Python usw. erfolgen.Es hängt wirklich davon ab, welcher einzelne Student das Programm umsetzt und zu welchem ​​Zweck.Aber es ist immer noch nützlich für die Java-Leute, die Python-Leute und die Matlab-Leute, eine gemeinsame Vorstellung davon zu haben, was die anderen tun und wie Ansatz, und nicht der Code selbst, funktioniert.

Dies ist keine Ja/Nein -Frage. Vielmehr sollte man sich wundern Wenn Pseudo-Code verwenden. Es ist wichtig, das Problem vor dem Entwerfen einer Lösung zu verstehen, und es ist wichtig, die Lösung klar zu sehen, bevor Sie sie implementieren. Pseudo-Code kann in einem dieser Schritte verwendet werden:

  1. Bei der Definition des Problems ist es üblich, Anwendungsfälle aufzuschreiben, manchmal auch Sequenzen von Aktionen zu verwenden.
  2. Beim Entwerfen einer Lösung. Klassendiagramme sind nett, aber sie beschreiben nur den "statischen" Teil, dh die Daten. Für den dynamischen Teil finde ich, sobald Sie sich mit einer Schleife und nicht trivialen Daten befassen, Pseudo-Code als die beste verfügbare Methode. Grafische Alternativen umfassen Zustandsmaschinen (gut für den komplexen Steuerfluss mit kleinen Daten) und Datenflussdiagramme (gut für einfache Strömungen mit komplexen Daten).
  3. Beim Implementieren der Lösung (oder kurz vor). Einige Programmiersprachen sind schwer zu lesen (denken Sie an, Montage). Eine alternative Darstellung kann in diesem Fall wertvoll sein. Wenn Sie mit den Sprachen nicht vertraut sind, lohnt es sich auch.

Pseudo-Code, das tatsächlich in einer hochrangigen Sprache richtiger Code ist, wird auch verwendet, es wird normalerweise als Prototyping bezeichnet.

Pseudo-Code ist nicht nur ein Verständnis, sondern auch gut für die Kommunikation.

Wenn Sie sich fragen, ob Sie regelmäßig Pseudo-Code verwenden sollten, bin ich persönlich gegen alle Arten von starren Regeln. Dies kann leicht zu einer langweiligen Zeitverschwendung werden, wenn sie für triviale Probleme verwendet wird, die jeder im Team versteht. Die Verwendung von Pseudo-Code für Spezifikationen, die Sie während des gesamten Lebens des Projekts beibehalten, kann ebenfalls kostspielig sein und einen geringen Wert bieten.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top