Hierarchisch oder seriell programmieren?
-
Umfrage: Wie kommt Struktur in euren Code?
Auswahl Stimmen Prozent "Hierarchische Programmierweise" 9 47.4% "Serielle Programmierweise" 0 0.0% Mal so, mal so (mit System) 5 26.3% Mal so, mal so (ohne System) 2 10.5% Ich will/kann das nicht beantworten. 3 15.8% Hallo.
Angelehnt an die andere Umfrage stellt sich mir noch eine weitere Frage. Wenn Ihr euch beim Programmieren zuerst um die Details kümmert, wie kriegt Ihr Struktur in euren Code?
Ich meine, am Schluss wird euer Code, wenn Ihr eine Algorithmus realisiert, so aussehen, dass es eine Hierarchie von Methoden gibt. Es wird Methoden geben, die auf einem höheren Level arbeiten und Methoden, die sich um die Details kümmern. Überlegt Ihr euch diese Hierarchie im Vorfeld des "Code-Schreibens" und programmiert auch entsprechend? Oder schreibt ihr den Code einfach in der zeitlichen Reihenfolge hin, in der er durchlaufen wird und überlegt euch dann im Nachhinein, wie man eine Struktur in den Code kriegt? In dem Fall würdet Ihr wohl vorerst recht lange Methoden kriegen und dann durch Refactorings einzelne Teile in eigene Methoden auslagern.
IMHO muss man sich für eine hierarchische Programmierweise im Vorfeld eine ganze Menge Gedanken machen und es wird trotzdem nicht immer klappen, gleich eine wirklich gute Code-Struktur zu bekommen. Lohnt sich dieser Aufwand?
Falls Ihr das mit System mal so und mal so macht, sagt bitte etwas dazu, nach welchen Kriterien Ihr das bestimmt.
Bei mir ist das mal wieder völlig unsystematisch und der resultierende Code scheint mir oft recht hässlich zu sein. Ich überlege, wie ich das verbessern kann.
-
Hm... ich denke eigentlich solange über meinen Algo nach, bis ich den Code förmlich vor den Augen sehe. Dann progge ich meistens schon los und lasse alles auf mich zukommen. Klappt ganz jut^^
-
Zuerst den fundamentalen Kleinkram (möglichst allgemein gehalten ,wenn geht), falls nicht schon wiederverwendbarer Code existiert, dann die äusseren Schichten. Oftmals gibt es einige grosse Module, die miteinander kommunizieren. Ich benutze gern Betriebssystem-ähnliche Strukturen, Schichten, Objekte, Protokolle, wenns passt. Um ein schlaues Klassendesign mache ich mir weniger Gedanken, sondern versuche möglichst gut das Problem zu modellieren. Code soll nicht schön sein, sondern möglichst fehlerfrei funktionieren und schnell laufen. Wartbarkeit berücksichtige ich zwar, aber nur soweit, dass die Funktionalität nicht darunter leidet. Selbstgemachte Komplexität, die nicht zur Problemlösung beiträgt, tut mir in der Seele weh.
-
Wenn sich der Algorithmus schon im Vorfeld in kleine Einheiten zerlegen lässt, dann implementiere ich erst die kleinen Methoden (inkl. Unittests) und arbeite mich dann so weiter vor. Manchmal habe ich aber auch nur eine wage Vorstellung und programmiere einfach los. Häufig refactore ich dann währenddessen direkt, um Code Duplizierung zu verhindern oder um den Code lesbarer zu machen. Wenn der Algorithmus fertig ist, muss ich meistens nicht mehr viel umstellen an der Struktur des Codes.
Manchmal weiss ich aber auch einfach noch gar nicht, wo mich die Reise überhaupt hinführt. Dann programmier ichs einfach Quick and Dirty runter. Manchmal merk ich dann, dass es so gar nicht funktioniert und schmeisse alles wieder weg. Wenn ich merke, dass es klappt, dann wird die Code Qualität irgendwie automatisch besser, denn ich hasse hässlichen unsauberen Code.
-
Baba Yaga schrieb:
Ich benutze gern Betriebssystem-ähnliche Strukturen, Schichten, Objekte, Protokolle, wenns passt. Um ein schlaues Klassendesign mache ich mir weniger Gedanken, sondern versuche möglichst gut das Problem zu modellieren.
Moment mal: Wir sprechen hier doch um die Implementierung von Algorithmen und nicht um das Design einer ganzen Software oder habe ich den Thread falsch verstanden?
-
Mal so, mal so... Ich arbeite gerne strukturiert, aber oft genug sind schnelle Ergebnisse gefragt, bei der das Code-Planen und auch der strukturierte Code auf der Strecke bleiben.
-
byto schrieb:
Baba Yaga schrieb:
Ich benutze gern Betriebssystem-ähnliche Strukturen, Schichten, Objekte, Protokolle, wenns passt. Um ein schlaues Klassendesign mache ich mir weniger Gedanken, sondern versuche möglichst gut das Problem zu modellieren.
Moment mal: Wir sprechen hier doch um die Implementierung von Algorithmen und nicht um das Design einer ganzen Software oder habe ich den Thread falsch verstanden?
Ja, meine Frage bezog sich auf die Implementierung von Algorithmen. Die Entwicklung der Klassenstruktur ist etwas anderes. Da ergibt sich die Struktur IMHO viel eher.
-
_matze schrieb:
Mal so, mal so... Ich arbeite gerne strukturiert, aber oft genug sind schnelle Ergebnisse gefragt, bei der das Code-Planen und auch der strukturierte Code auf der Strecke bleiben.
Man hat zwar nicht immer die Zeit, alles zu vergolden. Aber strukturiert sollte man auch unter Zeitdruck arbeiten. Denn morgen muss man (natürlich wieder unter Zeitdruck) alten Code erweitern oder modifizieren. Und wenn der dann unstrukturiert runtergeklatscht wurde, ist die "Zeitersparnis" von der initialen Implementierung wieder dahin.
-
byto schrieb:
_matze schrieb:
Mal so, mal so... Ich arbeite gerne strukturiert, aber oft genug sind schnelle Ergebnisse gefragt, bei der das Code-Planen und auch der strukturierte Code auf der Strecke bleiben.
Man hat zwar nicht immer die Zeit, alles zu vergolden. Aber strukturiert sollte man auch unter Zeitdruck arbeiten. Denn morgen muss man (natürlich wieder unter Zeitdruck) alten Code erweitern oder modifizieren. Und wenn der dann unstrukturiert runtergeklatscht wurde, ist die "Zeitersparnis" von der initialen Implementierung wieder dahin.
Ist richtig, aber erklär das mal dem Kunden, der seine ach so wichtige Anpassung nicht rechtzeitig bekommt.
Na ja, ist natürlich nicht immer so...
-
_matze schrieb:
Ist richtig, aber erklär das mal dem Kunden, der seine ach so wichtige Anpassung nicht rechtzeitig bekommt.
Kunden müssen manchmal einsehen, dass ihre Forderungen unrealistisch sind.
-
Baba Yaga schrieb:
_matze schrieb:
Ist richtig, aber erklär das mal dem Kunden, der seine ach so wichtige Anpassung nicht rechtzeitig bekommt.
Kunden müssen manchmal einsehen, dass ihre Forderungen unrealistisch sind.
Nein müssen sie nicht, wenn Chef ihnen das versprochen hat.
-
_matze schrieb:
Ist richtig, aber erklär das mal dem Kunden, der seine ach so wichtige Anpassung nicht rechtzeitig bekommt.
Tue ich täglich.
Es ist halt eine Frage, wie man es dem Kunden verkauft. Wenn Du einmal anfängst, dem Kunden was quick'n'dirty in kürzester Zeit hinzuklatschen, dann will er Anforderungen von da an immer so schnell haben. Deswegen gar nicht erst auf sowas einlassen und die Arbeit richtig machen. Sonst hat man in kürzester Zeit einen Wust an Spagetti-Code, den Du vielleicht noch irgendwie warten kannst, aber spätestens Dein Nachfolger im Projekt kotzen wird. Einzig bei wirklichen Job-Stoppern patche ich Code ASAP und mache ggf. bei der Code Qualität Abstriche. Aber das kann man danach dann ja noch grade ziehen.
-
_matze schrieb:
Baba Yaga schrieb:
_matze schrieb:
Ist richtig, aber erklär das mal dem Kunden, der seine ach so wichtige Anpassung nicht rechtzeitig bekommt.
Kunden müssen manchmal einsehen, dass ihre Forderungen unrealistisch sind.
Nein müssen sie nicht, wenn Chef ihnen das versprochen hat.
Zum Glück kann man sich den Chef ja aussuchen.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.