Wie geht ihr an die Richtige Planung von einem Projekt ran? Ich mach immer schnell-schnell und programmier drauf los
Das ist letztendlich das, was bei mir auch immer noch am besten funktioniert (natürlich nicht ganz ohne System). Ich hatte mal vor vielen Jahren mal so eine Phase, wo ich versucht hatte, meine Programme zu Anfang komplett top-down durchzuplanen. Hat überhaupt nicht funktioniert. Erstens kommt man überhaupt nicht voran, zweitens stellt sich der Entwurf im Nachhinein meistens als verkorkst heraus, und dann ist es schon zu spät.
Inzwischen ist es mein Ziel, so zu entwickeln, dass ich immer möglichst schnell etwas lauffähiges habe. Wenn das Programm z.B. 10 Dinge können soll, dann schreibe ich es erst mal so, dass es nur eins davon kann. Und das wird auf dem einfachstmöglichen Wege umgesetzt (KISS). Die anderen 9 Dinge berücksichtige ich dabei noch gar nicht. Wenn das erste Ding dann läuft, schaue ich, wie ich von dort so einfach wie möglich zum zweiten Ding komme. So geht es immer weiter. Wenn ich zwischendurch das Gefühl habe, dass der Code zu hässlich wird, wird er refaktorisiert. Wann das angebracht ist, dafür muss man mit der Zeit halt ein Gefühl entwickeln.
Ein Fehler, den ich am Anfang immer gemacht habe, war, dass ich versucht habe, Code von Anfang an so allgemeingültig und flexibel wie möglich zu halten. Der Gedanke war natürlich, dass ich so später leicht Funktionen nachrüsten oder ändern könnte. Was ich dabei aber übersehen habe, ist, dass Flexibilität nicht unbedingt darin besteht, dass man durch Indirektion und Abstraktion so viele Stellschrauben wie möglich hat, sondern dass es in der Praxis oft flexibler ist, Code ohne Stellschrauben zu haben, den man bei Bedarf dafür leicht umschreiben kann.
Das ist nun der Maßstab geworden, nach dem ich meinen Code entwickle: Ich denke mir beim Schreiben schon, dass keine der Zeilen, die ich schreibe, endgültig sein wird. Ich versuche daher meinen Code so aufzubauen, dass er später möglichst leicht verändert werden kann.
Außerdem bin ich ein Freund von testgetriebener Entwicklung. Die führt eigentlich automatisch zu dieser Vorgehensweise, und ist zudem recht motivierend, weil man durch bestandene Tests recht schnell Fortschritte sieht, selbst wenn man noch kein lauffähiges Programm hat. Außerdem ist man gezwungen,
Unit-Tests zu schreiben, wozu einem sonst im Nachhinein oft die Motivation fehlt. Die
Unit-Tests helfen nicht nur dabei, Fehler überhaupt erst mal zu bemerken, sondern auch dabei, die Ursache zu finden. Beim Debugging ist es sehr hilfreich, einen immer gleichen, deterministischen Ablauf mit wenig Seiteneffekten zu haben.
Disclaimer: Mein Text bezieht sich mehr auf den Fall, dass man alleine arbeitet. Im Team sind die Bedingungen teilweise andere. Da ist es zum Beispiel nicht so gut möglich, mal eben Code komplett umzuschreiben. Habe da aber selber noch nicht so viele Erfahrungen gesammelt.