it-swarm.dev

Sollte man vor der eigentlichen Codierung Pseudocode verwenden?

Pseudocode hilft uns, Aufgaben sprachunabhängig zu verstehen. Ist es eine bewährte Methode oder ein vorgeschlagener Ansatz, Pseudocode als Teil des Entwicklungslebenszyklus zu erstellen? Zum Beispiel:

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

Ist dies ein vorgeschlagener Ansatz? Wird es in der Industrie praktiziert?

23
Vimal Raj

Das Schreiben von Pseudocode vor dem Codieren ist sicherlich besser als nur das Codieren ohne Planung, aber es ist alles andere als eine bewährte Methode. Testgetriebene Entwicklung ist eine Verbesserung.

Noch besser ist es, die Problemdomäne zu analysieren und Lösungen mithilfe von Techniken wie User Stories, Anwendungsfällen, CRC-Karten und Diagrammen zu entwerfen, die von Methoden wie Cleanroom, RUP, Lean, Kanban, Agile usw. unterstützt werden.

Das Prinzip der Best Practices besteht darin, die Art des Problems und die Komponenten, die Sie zur Implementierung der Lösung verwenden, genau zu verstehen.

17
Huperniketes

Ich verwende Kommentare als eine Art Pseudocode auf sehr hoher Ebene, indem ich die Kommentare schreibe, bevor ich den Code schreibe. Ich finde, dass das Durchdenken des gesamten Problems, selbst auf hoher Ebene, meinen Code erheblich verbessert.

19
Hal Helms

Nein, nicht zuerst Pseudocode

Das ist zu viel Aufwand. Sie schreiben die Logik ohne die Vorteile. Ich würde stattdessen Folgendes vorschlagen:

  1. Prototyp in der Sprache, mit der Sie versenden werden (AKA Schreiben Sie einen zum Wegwerfen )
  2. Architekturdiagramme mit Codefragmenten zum Testen von Annahmen/Schlüsselentwürfen
  3. Testgesteuerte Entwicklung, bei der Sie zuerst Ihre Schnittstellen/Codestruktur schreiben, gefolgt von Tests und der Implementierung des Codes.

Alle drei bewegen Sie im Gegensatz zu Pseudocode direkt zu Ihrer Lösung. Persönlich tendiere ich dazu, die Techniken 1 oder 2 zu verwenden, abhängig von der Teamgröße. Für kleinere Teams (z. B. 5 Personen oder weniger) funktioniert das Prototyping sehr gut. Für größere Teams, in denen mehrere Entwicklergruppen parallel arbeiten, hat sich herausgestellt, dass die mit Technik 2 früh erstellte Dokumentation gut funktioniert, da Sie frühzeitig darüber diskutieren und Komponentengrenzen besser definieren können. Ich bin mir sicher, dass TDD auch sehr gut funktionieren würde, aber ich muss noch in einem Team arbeiten, das sich diesem Prozess verschrieben hat.

8
Jay Beavers

Meiner Meinung nach hat Pseudocode nur zwei gültige Zwecke:

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

(2) Einer nicht-technischen Person oder nur aus Gründen der Zweckmäßigkeit in einer Whiteboard-Sitzung mitzuteilen, wie etwas funktionieren wird.

7
JohnFx

Ist Pseudocode 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 um die genaue Syntax der Sprache zu kümmern. Dies prägt den Denkprozess und kann helfen, nützliche Gewohnheiten zu verankern (und ich nehme auch schlechte Gewohnheiten an). Deshalb wird es in Schulen so oft verwendet.

Wird es in der Industrie praktiziert? Nach meiner Erfahrung nein. Niemand hat die Zeit, das Projekt zwischen der Dokumentation (Anforderungen, Spezifikationen, Storyboards, Anwendungsfälle oder was auch immer sie sonst verwenden) und dem tatsächlichen Code aufzuräumen. Es wird allgemein angenommen, dass bereits vor dem grünen Licht für die Codierung ausreichend über das Problem nachgedacht wurde. An diesem Punkt ist das Codieren des Projekts wichtiger als das Hinzufügen einer weiteren Ebene der Entwurfsvorbereitung.

5
Corin

Pseudocode kann nützlich sein, wenn Sie mit der Sprache nicht vertraut sind oder wenn Sie mentale Kontexte ändern müssen. In den seltenen Fällen, in denen ich Pseudocode schreibe, ist er auf Papier. Manchmal kann es hilfreich sein, nur die Hände von der Tastatur zu nehmen und auf Papier zu kritzeln, um eine mentale Blockade 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 (vor/nach/invariante Bedingungen) der Methode, bevor Sie beginnen
  2. TDD
  3. 1 und 2 kombiniert (schriftliche Tests zur Ausführung des Vertrags)

Ich würde auch vorschlagen, dass das Erhalten einer Genehmigung, bevor Sie mit dem Schreiben von Code beginnen, wahrscheinlich viel mehr Aufwand verursacht, als es wert ist. Entwurfsüberprüfungen (Vorimplementierung) können nützlich sein, müssen jedoch auf einem höheren Niveau als einzelne Algorithmen sein.

3
Ben Hughes

Ich würde Pseudocode auf jeden Fall 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 reparieren, wenn er sich noch in der Planungsphase befindet, anstatt zu warten, bis Sie bereits einen großen Teil davon codiert haben.

3
Rachel

Das einzige Mal, dass ich in den letzten 10 Jahren Pseudocode verwendet habe, sind Interviews, wenn wir an einem Whiteboard arbeiten und die jeweilige Sprache keine Rolle spielt.

Es ist sicherlich hilfreich, um einen Prozess/Algorithmus lose zu durchsprechen, ohne sich mit der Syntax zu beschäftigen. Z.B. Schreiben einer C++ - Klasse mit C # -Eigenschaften, um den Punkt zu veranschaulichen.

Es hat seinen Platz, sollte aber nur dort verwendet werden, wo es benötigt wird (es ist Arbeit, die Sie wegwerfen werden) und sicherlich nicht Teil eines formalen Prozesses, es sei denn, Sie haben ISO-Standards, die darauf bestehen.

2
JBRWilkinson

Für mich und die Leute, mit denen ich in den letzten Jahren zusammengearbeitet habe, hat sich Pseudocode zu nicht ganz perfektem echtem Code entwickelt. Wenn Sie nicht gleichzeitig mit vielen Sprachen arbeiten, scheinen die meisten Menschen im allgemeinen Muster ihrer Hauptsprache zu denken. Ich habe eine Weile in .net-Läden gearbeitet, daher sehen die Whiteboard-Kritzeleien der meisten Leute im Büro eher wie vb oder c # aus, wobei ein Teil der Interpunktion fehlt.

Die Übung ist immer noch wertvoll, wenn Sie über Optionen und dergleichen diskutieren, aber das sprachunabhängige Bit tendiert dazu, sich zu entfernen, wenn Sie mehr Zeit mit einigen Sprachen verbringen.

2
Bill

Pseudocode wird immer häufiger mit Tools wie UML grafisch geschrieben. Probieren Sie zum Beispiel yUML aus.

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

  • Betten Sie UML-Diagramme in Blogs, E-Mails und Wikis ein.
  • Veröffentlichen Sie UML-Diagramme in Foren und Blog-Kommentaren.
  • Verwenden Sie es direkt in Ihrem webbasierten Tool zur Fehlerverfolgung.
  • Kopieren Sie UML-Diagramme und fügen Sie sie in MS Word-Dokumente und PowerPoint-Präsentationen ein ...

... yUML spart Ihnen Zeit. Es ist für diejenigen gedacht, die kleine UML-Diagramme und Skizzen erstellen möchten.

Ohne yUML kann das Erstellen eines UML-Diagramms das Laden eines UML-Tools, das Erstellen eines Diagramms, das Zuweisen eines Namens, das Herumspielen mit dem Layout, das Exportieren in eine Bitmap und das anschließende Hochladen online irgendwo umfassen. yUML bringt dich nicht dazu, irgendetwas davon zu tun ...

2
mouviciel

Ich werde den vorherigen Antworten nicht zustimmen und nein sagen, aber mit einer Einschränkung: Sie können den Pseudocode nur loswerden, wenn Sie sich fieberhaft der Umgestaltung Ihres Codes widmen, um auftretende Probleme zu lösen. Pseudocode ist im Wesentlichen eine Möglichkeit, Ihren Code zu definieren, bevor Sie Ihren Code definieren. Es ist unter vielen Umständen eine unnötige Abstraktion, und da Ihr Code beim ersten Mal nie perfekt sein wird (und wahrscheinlich nicht vollständig dem Design des Pseudocodes folgt), scheint es mir irrelevant.

2
EricBoersma

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

In moderneren Sprachen macht Pseudocode nicht so viel Sinn. Was besser funktionieren würde, wäre das Schreiben von Methodenstubs und das Ausfüllen der Logik der obersten Ebene sowie so viele Details wie nötig, um den Algorithmus und die Anforderungen zu überprüfen - all dies im tatsächlichen Code. Sie können diesen Code dann dem Teamleiter zur Genehmigung anzeigen und Ihren echten Code bereits starten lassen.

2
Larry Coleman

Gute Arbeit. Sie haben eine gute Diskussion begonnen. Als ich Programmieren lernte, schrieb ich Pseudocodes, um die verschiedenen Schleifen und Algorithmen zu verstehen. Das war vor mehr als eineinhalb Jahrzehnten. Damals waren selbst Programmiersprachen nicht sehr leistungsfähig ... und ereignisgesteuertes Programmieren war Zukunft. Jetzt mit 4GLs und 5GLs denken wir eher in der Sprache selbst als in einfachem Englisch. Wenn wir an ein Problem denken, denken wir in Objekten und Operationen. Und bis es ein komplexes Algo ist, macht das Schreiben von Pseudocodes (oder P-S-E-U-DO-Codes, nur ein Scherz) keinen Sinn. Stellen Sie die Lösung besser grafisch dar.

1
devcoder

Es gibt einige Umstände, unter denen Pseudocode in meiner Arbeit häufig ausbricht, und zwar in der Wissenschaft, wo die Programmierung eher als Werkzeug oder als "und jetzt lösen wir es" in der Mitte eines Projekts verwendet wird:

  1. Wenn der Code für ein tatsächliches Verständnis dessen, was passieren wird, kontraproduktiver sein wird als Pseudocode. SAS nimmt zum Beispiel die Hälfte des Whiteboards für einige ziemlich grundlegende Programmieraufgaben ein. Siehe auch C, das einige andere Poster besprochen haben.
  2. Bei vielen Datenanalysen und Statistikkodierungen wird häufig mit dem Code herumgebastelt, wenn Ergebnisse generiert werden. Pseudocode ist etwas einfacher zu verwenden für "Hierin liegt ein Hin- und Her-Prozess, wenn das diagnostische Diagramm nicht richtig aussieht, versuchen Sie es mit X".
  3. Die Schüler lernen viele verschiedene Programmiersprachen. Beispielsweise kann unter mir bekannten Personen ein Statistikproblem in SAS, R oder Stata analysiert werden. Etwas, das etwas erfordert, das der traditionellen Programmierung näher kommt, kann in R, Matlab, C, C++, Java, Python ausgeführt werden. Es hängt wirklich davon ab, welcher bestimmte Schüler das Programm implementiert und zu welchem ​​Zweck. Aber es ist immer noch nützlich für die Java Leute und die Python Leute und die Matlab Leute), eine gemeinsame Vorstellung davon zu haben, was die anderen tun und wie die - Ansatz anstelle des Codes selbst funktioniert.
0
Fomite

Dies ist keine Ja/Nein-Frage. Vielmehr sollte man sich fragen wann, um Pseudocode zu verwenden. Es ist wichtig, das Problem zu verstehen, bevor Sie eine Lösung entwerfen, und es ist wichtig, eine klare Sicht auf die Lösung zu haben, bevor Sie sie implementieren. Pseudocode kann in jedem dieser Schritte verwendet werden:

  1. Bei der Definition des Problems werden häufig Anwendungsfälle aufgeschrieben, manchmal mithilfe von Aktionssequenzen.
  2. Beim Entwerfen einer Lösung. Klassendiagramme sind nett, aber sie beschreiben nur den "statischen" Teil, d. H. Die Daten. Für den dynamischen Teil halte ich Pseudocode für die beste verfügbare Methode, sobald Sie sich mit einer Schleife und nicht trivialen Daten befassen müssen. Zu den grafischen Alternativen gehören Zustandsautomaten (gut für komplexe Steuerungsabläufe mit wenigen Daten) und Datenflussdiagramme (gut für einfache Ablaufabläufe mit komplexen Daten).
  3. Bei der Implementierung der Lösung (oder kurz zuvor). Einige Programmiersprachen sind schwer zu lesen (denken Sie an Assembly). Eine alternative Darstellung kann in diesem Fall wertvoll sein. Wenn Sie mit den Sprachen nicht vertraut sind, lohnt es sich auch, dies zu tun.

Es wird auch Pseudocode verwendet, der eigentlich der richtige Code in einer Hochsprache ist. Er wird normalerweise als Prototyping bezeichnet.

Neben dem Verständnis ist Pseudocode auch gut für die Kommunikation.

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

0
Joh

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

Viele moderne Sprachen wie Python oder Java sind dem Pseudocode bereits so nahe, dass das Schreiben eines Ad-hoc-Pseudocodes zuerst verschwenderisch ist, IMHO. Tun Sie es besser sofort mit dem Ansatz Tracer Bullet .

Es ist ein anderes Geschäft, wenn Sie ein paar Low-Level-Dinge machen, die Metall nahe kommen oder mit der Sprache, die Sie verwenden, noch nicht vertraut sind. Dann kann Pseudocode definitiv nützlich sein.

0
Joonas Pulakka