Planung Programm

[andie39]

Ich habe nach der Suche nichts gefunden.
Aber je mehr ich mir das anschaue, desto mehr komme ich zum Schluss, dass neben einem Grundwissen ein solider Plan für ein Programm das A&O ist.

Das Schreiben selber ist eine Sache und ich denke mir, dass auch gute Programmierer immer mal wieder nachschlagen müssen.

Aber ohne einen Programmplan wird das nicht funktionieren.
Sprich: Was will ich erreichen?
Wie sind die Schritte dahin?
Wie verpacke ich das etc.

Mich würde daher mal interessieren, wie ihr eure Programme plant.

[ulipy]

Hallo @andie39
Das interessiert auch mich sehr!
Unabhängig davon, dass auf praktischer Ebene immer Abwägungen und Mischungen zwischen "top down" und "bottom up" Ansätzen existieren, ist - wie auch du sagst - die Aufteilung der unterschiedlichen Script-Bereiche bereits ein wichtiger - wenn nicht wesentlicher - Bestandteil der Planung, wenn man Python zu Grunde legt.

Beitragen kann ich dazu nicht viel, ich hoffe im Gegenteil, Informationen dazu zu erhalten.

Was ich bisher in der Basis-Aufteilung habe:

### shebang
...
### imports
...
### constants
...
### functions
...
### classes
...
### main


Was hier z. B. nicht reinpasst wären listenartige Objekte variablen Inhalts, die nicht nur innerhalb anderer Objekte "wohnen".
Faslls solche überhaupt in Python angelegt / verwendet werden, wären sie m. E. innerhalb der obigen Abschnitte eines Scripts "freischwebend" - kann ich mir eigentlich nicht vorstellen.

Bin gespannt, was hier noch gesagt wird!

[__deets__]

Solche Variablen Listen wären auf ja auf Modulebene globaler Zustand. Und der ist ja, wie nun schon mehrfach ausgeführt, zu vermeiden.

Weshalb sowas eben in Funktionen und Objekten lebt, und als Parameter an andere übergeben wird.

Was die eigentliche Frage angeht: persönlich habe ich die Architektur auch komplexer Programme im Kopf. Andere mögen das anders handhaben, wobei aber zumindest meine lieben Kollegen aus meiner Perspektive da auch wenig anders vorgehen. Jedenfalls sind mir keine Artefakte solcher Planungsprozesse bekannt.

Gelegentlich greift man mal zu einer Zeichnung, um sich selbst, oder auch in einer Diskussion, Zusammenhänge zu verdeutlichen.

Eine andere Sache ist eine Planung auf einer Ebene darüber. Also nicht die Frage WIE man etwas macht (die ich denke hier im Vordergrund steht), sondern WAS man macht. Konzepte wie minimal viable product, agile Entwicklung etc, werden natürlich alles bei uns auch genutzt.

[ulipy]

@__deets__
Da auch ich denke, dass es hier nicht um die oberste Ebene der Planung geht, möchte ich im Thema noch zurückfragen:
Nun habe ich also (für die mittlere Architekturebene) wesentliche variable Listenelemente nur innerhalb von Funktionen - gut (außer den Übergabeparametern).

Um sich und anderen nun die "Sucherei" etc. im Script zu ersparen:
Geht dann bereits aus dem angenommen ausführlich, "extensiv" gewählten Namen für die Funktion die Bedeutung als "wesentlich" hervor oder wird erwartet, dass zuerst mal das __doc__ gelesen wird?

[__deets__]

Das ist ja nun eine komplett orthogonale Frage - die nach Lesbarkeit oder Verständlichkeit von Code. Und da ist ein docstring kein Kommentar des Funktionskörpers, der die Bedeutung einer darin genutzten Variable erklärt. Sondern dazu gedacht, einem Betrachter, eben genau ohne tieferen Blick in den Code, die Argumente, Ergebnisse und zu erwartende Verhaltensweisen zu erklären, damit der die dann benutzen kann. Weshalb sie auch nahezu ausschließlich an Schnittstellen zum Einsatz kommen. Also zb Bibliotheksfunktionen.

Variablen im Code hingegen sollten für sich repräsentative Namen haben. Zwei- bis drei-Wort Namen sind da bei mir durchaus gängig.

[noisefloor]

Hallo,

ich als Freizeitprogrammierer mache das ähnlich wie __deets__ : ich habe das ganze Konzept quasi fertig im Kopf und Programmieren das ganze dann aus. Ob ich einen "top down" oder "bottom up" Ansatz nehme kommt auf das an, was das Ergebnis sein soll. Wenn ich z.B. irgendwas für eine mathematische / physikalische Berechnung programmiere, dann schreibe ich mir erst die Funktionen / Klassen für die Rechnung an sich, teste das ganze auf der Kommandozeile und baue dann erst das Frontend davor.

Bei Programme, wo ich weiß, dass ich dir nur 1x und dann wahrscheinlich nie wieder brauche (z.B. Lösungen für Advent of Code oder Geocaches) neige ich stark zu Spaghetticode, d.h. das läuft 1x durch und am Ende steht das Ergebnis.

Das Schreiben selber ist eine Sache und ich denke mir, dass auch gute Programmierer immer mal wieder nachschlagen müssen.

Ja. IMHO ist das Wissen, welche nützlichen Module es so gibt und welches Modul für was gut ist wichtiger als das man die API auswendig kann. Dafür gibt es ja die (hoffentlich gute...) Doku.

Gruß, noisefloor

[__blackjack__]

@andie39: Ich denke ich muss mich __deets__ anschliessen. Planung im Sinne von expliziten ”freistehenden” Artefakten zusätzlich zum Quelltext (Programm und ggf. Dokumentation) kommt bei mir in der Regel nur vor wenn etwas anderen Personen kommuniziert werden muss. Also wenn man mit dem Auftraggeber, ob nun intern oder extern, beispielsweise abklärt was das Programm können muss, oder man das bereits vorhandene Programm einem anderen Programmierer erklären muss. Was dann ja streng genommen keine Planung mehr ist.

Ansonsten weiss ich ja wo ich hin will/muss. Das hängt natürlich auch sehr damit zusammen ob man das Programm im wesentlichen alleine umsetzt, oder ob es ein Team gibt. Im letzteren Fall braucht man natürlich mehr Kommunikation, auch schon bei der Planung, damit alle die gleiche Idee davon haben, wo es hingehen muss/soll, und auch zur Koordination wer was macht. Aber ich gehe mal davon aus, dass Du kleinere bis mittlere Projekte meintest, die Du selbst in Angriff nimmst.

Ich versuche immer möglichst schnell zu einen benutzbaren Teilzustand zu bekommen. Ulipy hat ja Top-Down vs. Bottom-Up angesprochen. Also nicht eines von beidem in Reinform, wo man dann erst sieht wenn alles fertig ist, was nicht zusammen passt. Das führt zu frustrierenden Fehlersuchen in einem Programm von dem man eigentlich das Gefühl hätte es sei ja zu 99,9% fertig. Und wenn man dann feststellt irgend etwas funktioniert nicht wie man sich das vorgestellt hat, und man muss mehr oder weniger grosse Teile neu schreiben, hebt das auch nicht gerade die Laune. Und es führt nach meiner Erfahrung dann auch gerne mal zu einem Haufen schneller, dreckiger Fixes um die gefühlten letzten 0,1% schnell hinter sich zu bringen.

Manchmal schreibe ich in die README oder den Quelltext in einen Docstring eine TODO-Liste, um Ideen nicht zu vergessen. Oft auch in Form von TODO-Kommentaren in den Quelltext, dort wo man etwas hinzufügen könnte was Sinn macht, oder etwas umbauen müsste um den Code zu verbessern, falls das nicht so klein ist, dass man das sofort einfach machen kann, oder wenn es von Bedingungen abhängt, die erst später erfüllt sein werden. Beispielsweise wenn man eine Krücke/Teillösung hat, die um ein Problem in einer Bibliothek herum arbeitet, kommt da ein TODO dran, das man an der Stelle mal prüfen müsste ob das Problem immer noch besteht. Oder das man dieses oder jenes in Python 3.x anders/besser lösen könnte wenn die aktuelle Anforderung ist, dass ein Python kleiner als dieses x unterstützt werden muss. Also wenn man beispielsweise `more_itertools.pairwise()` benutzt, könnte man das kommentieren, dass man das in Python 3.9 (oder war's 3.10?) nicht mehr von extern braucht, sondern aus `itertools` aus der Standardbibliothek holen kann.

[andie39]

Interessant. Hätte ich anders vermutet.
Ich nehme an, dass ist der Professionalität zuzuschreiben.

Ist quasi das gelernte Handwerk

[Buchfink]

@andie39
bei uns ist das auch so wie bereits __deets__ geschrieben hat.
Die Entwickler haben die Architektur im Grunde im Kopf und man diskutiert technisch allenfalls mal auf der Metaebene verschiedene Wege:
(kostengünstige, hässliche Lösung vs. aufwändigere, saubere Lösung)

Ich vermute, es hängt einfach damit zusammen, dass etliche Dinge erst bei der konkreten Umsetzung auffallen: Z.B. wie ein Detail in einer technischen Spezifikation genau zu interpretieren ist etc.
Solche Dinge im Vorfeld bereits einzuplanen ist schwierig/unmöglich. Man kann und sollte allenfalls zeitliche Puffer für Unwägbarkeiten einplanen. Das ist dann aber eine organisatorische Form der Planung.

[__blackjack__]

@andie39: Professionell wäre ja eher mit einem Plan, Lastenheft,Pflichtenheft, UML-Diagramme, und so weiter. Also wenn man Projekte mit einem Team für externe Kunden macht, oder für andere Abteilungen in einer grösseren Firma.

Was würdest Du Dir denn von einem ”Programmplan” vor dem Programmieren erhoffen? Das was Du da beschreibst sind für mich grösstenteils Fragen die ich beim Programmieren stelle und beantworte. Und zwar immer wieder. Denn „was sind die Schritte dahin“ ist ja im Grunde *das Programm*. Würdest Du vorm Programmieren das Programm schon mal als Plan schreiben? Wie unterscheidet sich das dann vom tatsächlichen Programm?

Natürlich stellt man sich die Frage(n) was man hat, und wie man das im Programm darstellt/modelliert, und welche Schritte man ausführen muss um zum Ziel zu kommen. Das könnte man vorher irgendwie aufschreiben, aber eben auch genau so gut gleich in Code giessen. Die benötigten Datentypen/Klassen als UML zu kodieren ist nicht wirklich schneller als gleich die Klassen in Python zu schreiben. Und einen Programmablaufplan kann man auch gleich als Code schreiben statt den zu zeichnen. Früher hat man dann vielleicht noch Algorithmen oder das grobe Programm als ”Pseudocode” geschrieben. Nur unterscheidet sich das von Python-Code kaum, so dass einem dieser Schritt auch nicht wirklich einen Mehrwert über den Quelltext gibt.

[andie39]

@andie39: Professionell wäre ja eher mit einem Plan, Lastenheft,Pflichtenheft, UML-Diagramme, und so weiter. Also wenn man Projekte mit einem Team für externe Kunden macht, oder für andere Abteilungen in einer grösseren Firma.

Was würdest Du Dir denn von einem ”Programmplan” vor dem Programmieren erhoffen? Das was Du da beschreibst sind für mich grösstenteils Fragen die ich beim Programmieren stelle und beantworte. Und zwar immer wieder. Denn „was sind die Schritte dahin“ ist ja im Grunde *das Programm*. Würdest Du vorm Programmieren das Programm schon mal als Plan schreiben? Wie unterscheidet sich das dann vom tatsächlichen Programm?

Natürlich stellt man sich die Frage(n) was man hat, und wie man das im Programm darstellt/modelliert, und welche Schritte man ausführen muss um zum Ziel zu kommen. Das könnte man vorher irgendwie aufschreiben, aber eben auch genau so gut gleich in Code giessen. Die benötigten Datentypen/Klassen als UML zu kodieren ist nicht wirklich schneller als gleich die Klassen in Python zu schreiben. Und einen Programmablaufplan kann man auch gleich als Code schreiben statt den zu zeichnen. Früher hat man dann vielleicht noch Algorithmen oder das grobe Programm als ”Pseudocode” geschrieben. Nur unterscheidet sich das von Python-Code kaum, so dass einem dieser Schritt auch nicht wirklich einen Mehrwert über den Quelltext gibt.

Ja das meine ich, den Ablaufplan, was baue ich ein:
Welche Klassen, eigene Funktionen etc und wie soll der Ablauf des Programms sein.

Wie ich sagte: Ich muss mir vorher Gedanken machen, aber ich nehme an, aufgrund eurer Erfahrung, sprudelt das einfach so raus

[noisefloor]

Hallo,

Ich muss mir vorher Gedanken machen, aber ich nehme an, aufgrund eurer Erfahrung, sprudelt das einfach so raus

Ich denke eher, dass das in Teilen auch eine Veranlagungssache ist. Der eine kann wahrscheinlich besser im Kopf einen fertigen Plan entwerfen und das dann Ausprogrammieren. Wenn man X Projekte gemacht fällt das wahrscheinlich irgendwann auch einfacher.

Wie gesagt bin ich Hobbyprogrammierer, dass hat nichts mit meinem Job zu tun. Wenn ich mal was größeres Programmiere, dann denke ich in der Regel auch ein paar Tage darüber nach, bis es "rund" ist und ich loslegen.

Wenn ich was Django-basiertes mache, also mit Datenbank und Webfrontend, fallen mir oft beim Programmieren selbst noch Sachen für zusätzlich Datenbankabfragen für Auswertungen ein. Dann ergänze ich die halt im laufenden Projekt noch - auch wenn das ursprünglich nicht geplant war.

BTW: wenn man was mit einer Datenbank, dann macht es IMHO sehr viel Sinn, sich genug Gedanken über den Datenbankentwurf zu machen. Auch den kann man zwar später ändern, dass kann aber u.U. sehr viel Arbeit sein.

Gruß, noisefloor

[Sirius3]

Jeder Plan ist solange gut, bis er auf die Realität trifft. Deshalb rate ich dazu, einfach loszulegen. In Programm ist nie auf Anhieb gut designed. Man fängt einfach an, und die Komplexität wächst mit der Zeit. Sobald ein Programm eine bestimmte Komplexität erreicht hat, kommt irgendwann der Punkt, wo man genug über das Problem gelernt hat, um alles zu löschen und noch einmal von Vorne zu beginnen.
Bestes Beispiel ist Python2/3. Vieles was in Python2 nicht so gut gelöst war, wurde in Python3 anders gelöst und dann braucht es noch 6 Subversionen, bis auch alle Kinderkrankheiten eliminiert sind.
Und auch in größeren Projekten werden ständig irgendwelche Teile ausgetauscht und neu programmiert.
Man darf sich nur nicht zu schade sein, hunderte Stunden Arbeit einfach zu löschen. Das gehört dazu und bedeutet nur, dass man sehr viel gelernt hat und es im nächsten Versuch besser machen kann.

[__blackjack__]

@andie39: Die Gedanken muss man sich schon machen, aber die kann man sich halt auch in Python machen. Ich sehe das auch nicht als Frage der Erfahrung. Vielleicht sogar im Gegenteil — wenn man die Erfahrung nicht hat, macht es vielleicht sogar noch mehr Sinn, dass man die ”Planung” gleich ausführen und testen kann, statt erst alles zu planen und dann beim übertragen in ein Programm festzustellen, das etwas nicht so wie im Plan vorgesehen klappt und man einiges umsonst, weil falsch geplant hat.

Ich meine, wo ist denn der Vorteil davon sich erst irgendwo in einer Textdatei oder einer Zeichnung aufzuschreiben welche Klassen man braucht, statt das gleich als Quelltextdatei zu schreiben? Beides sind Dokumente die das beschreiben. Den Quelltext braucht man am Ende auf jeden Fall, das heisst den muss man so oder so schreiben. Aber warum das Textdokument wo im Grunde genau das gleiche steht? Was man dann im Laufe der Zeit auch noch zusätzlich synchron halten muss.

Vielleicht reden wir auch aneinander vorbei, weil ich echt nicht verstehe was das bringen soll, beziehungsweise wie das konkret aussehen soll. Also unter der Voraussetzung, dass wir hier von kleinen bis mittelgrossen Projekten reden, die jemand alleine schreibt. Wo man also nicht irgendwas planen muss an dem mehrere Leute arbeiten, sich über die Schnittstellen einigen müssen, vielleicht nicht alle die gleiche Programmiersprache sprechen (Datenbank-Programmierer, verschiedene Backend- und Frontendentwickler) oder vielleicht sogar gar nicht programmieren — die Chefs/Abteilungen die das Budget abnicken müssen und gerne Planung dafür sehen wollen. Da sehe ich Dokumente in einer Form mit der alle Beteiligten etwas anfangen können, und eine vorgeschaltete Planungsphase, die sich schärfer von der Implementierung trennt, weil Dinge geklärt werden müssen bevor programmiert wird, oder ob überhaupt programmiert wird.

Gedanken machen muss ich mir auch und auch die gleichen, egal wie ich den Plan aufschreibe, ob nun als Freitext oder einer anderen formalen Sprache als der Programmiersprache, oder gleich in der Programmiersprache oder zumindest in der Quelltextdatei als Kommentar oder Docstring.

Eventuell liegt das Missverständnis auch darin, dass Du Dir bei „sprudelt das heraus“ vorstellst, dass die Endfassung des Programms so direkt aus dem Kopf in den Editor getippt wird. Das ist nicht so. Ich habe nicht alle Klassen und Funktionen im Kopf und muss die nur noch aufschreiben. Ich denke nach was ich grob brauche, und die konkreten Details entstehen dann bei der Entwicklung. Und das auch sehr oft nicht sofort in der endgültigen Form oder zumindest nicht auf einen Schlag, sondern Schritt für Schritt, unterbrochen von Tests ob das bis da hin vorhandene überhaupt das tut was es soll. Konkrete einzelne Funktionen entstehen dann zum Beispiel weil man einen Teilschritt isoliert testen möchte, oder generell weil die Funktion an der man gerade arbeitet zu gross und unhandlich wird, oder weil man feststellt, dass man hier das gleiche, oder ein sehr ähnliches Problem löst, was man an anderer Stelle schon mal hatte, und wo es Sinn machen würde, das in eine eigene Funktion heraus zu ziehen.

Bei Klassen ist das ähnlich. Es gibt welche da ist klar, dass es die geben muss. Bei anderen stelle ich das während der Entwicklung fest. Weil Argumentlisten zu lang werden und/oder immer wieder die gleichen Argumente zusammen herum gereicht werden und man mindestens einer Teilmenge davon einen sinnvollen Namen geben könnte. Da entsteht dann erst mal ein guter altmodischer Verbunddatentyp. Wenn man das Programm dann entsprechend umgeschrieben hat, ist der nächste Schritt zu schauen, ob von der vorhandenen Funktionalität irgend etwas deutlich zu diesen Daten gehört, was man dann als Methode dort hin verschieben kann. Ähnlich dann bei Klassen selbst. Wenn die Attributanzahl wächst, macht es Sinn zu schauen was davon zusammen einen sinnvollen eigenen Datentyp ergeben würde und das dann entsprechend umzuschreiben.

[DasIch]

Bei größeren Projekten haben wir ein PR FAQ und ein Technical Solution Design (TSD), manchmal gibt es auch mehrere Design Dokumente auf unterschiedlichen Ebenen wenn der Scope sehr groß ist. Für beides gibt es Templates die vorgeben was man so erwähnen sollte.

Das TSD beantwortet Fragen wie: Welches Problem wird gelöst? Welche offenen Risiken existieren? Wie sieht es mit Sicherheit und Datenschutz aus? Welche Use Cases gibt es und welche Implikationen hat dass auf die Load? Welche Technologie Entscheidungen wurden getroffen (z.B. Programmiersprache, Datenbanken etc.)? Welche SLOs gibt es? Welche Abhängigkeiten (damit sind Teams oder andere interne Anwendung gemeint) gibt es? Wie sieht die API aus (sketch reicht und mit API ist HTTP gemeint)? Welche Kosten wird es haben?

Ein Diagram auf Ebene eines Klassendiagramms wie man es teilweise im Rahmen von UML an der Uni sieht würde man da vermissen.

Wir verfolgen auch einen API First Ansatz also wird man irgendwann auch eine konkrete API in Form von OpenAPI definieren. In mehr Details als dass wird aber nicht geplant, zumindest nicht Team übergreifend. Innerhalb eines Teams kann es dann schon sein dass man User Stories so genau plant dass definiert wird wie z.B. ein Datenbank Schema auszusehen hat.

Das ist soweit ich weiß auch bei anderen größeren Unternehmen vergleichbar, dieser Artikel gibt da einen guten Überblick.

Wie man den Code aufteilt ist aber recht uninteressant und ich hab noch nicht gesehen dass man sich da ernsthaft Gedanken darüber macht. Es gibt natürlich Konventionen die sich zum Teil aus der Wahl von Frameworks ergeben aber geplant wird sowas nicht. Die Erwartung ist allerdings auch dass man auf Senior Ebene für sowas auch ein intuitives Verständnis hat und es würde jetzt auch niemand alleine an einem Projekt arbeitet (unabhängig von der Größe).

Bei uns ist im worst case allerdings auch nur Geld in Gefahr. Wenn es jetzt um Gesundheit geht, würde man natürlich nochmal ganz anders arbeiten.

[andie39]

Hmmm.
Also ich weiss nicht ob einfach so wegschreiben bei mir klappen würde. Ggf später mit mehr Erfahrung.
Wobei ich auch nur für mich selber programmiere und lernen will.

[__blackjack__]

@andie39: Das mit dem einfach so wegschreiben ”klappt” auch nicht. Ich habe immer noch das Gefühl wir reden ein bisschen aneinander vorbei, weil ich auch immer noch nicht weiss was Du Dir eigentlich unter Planung vor dem Programmieren vorstellst. Für mich klingt das nach einer Bauzeichnung die komplett durchgerechnet ist und dann 1:1 umgesetzt werden kann ohne das man wieder zurück geht zur Planung. Programmieren ist für mich, und ich denke das ist nicht unüblich, deutlich mehr ein iterativer Prozess. Man erschafft etwas neues aus *sehr* flexiblem formbarem Material. Man hat da ein Ziel vor Augen wo es hingehen soll, und fängt dann an das zu bauen und während man das tut, ergeben sich die Details. Gewisse Strukturen sind durch die Werkzeuge und Rahmenwerke und Konventionen vorgegeben und ergeben sich auch aus Erfahrung. Erfahrung ist aber nicht im Voraus planbar, die muss man letztlich machen/sammeln.