Der richtige Design-Weg
-
Sone schrieb:
Also, du hast das komplette perfekte Design deines tausende Zeilen langen Programms vor der ersten Code-Zeile im Kopf...
Nein, Wenn du deine Hand betrachtest, denkst du dann ueber das Zusammenspiel der einzelnen Muskelphasern nach oder eher ueber Daumen und Finger. Aufteilung in Daumen und Finger und Handruecken sind aber vorher klar.
Anderes Beispiel: Entwerfen und Implementieren einer Bibliothek. Da hast du wenig Spielraum im Nachhinein viel zu aendern, da es auch viele Aenderungen beim Kunden verursacht. Da muss vorher klar sein, wie die API auszusehen hat. Sie muss auch moegliche Aenderugswuensche in einem gewissen Rahmen unterstuetzen, etc. Mit einfach hingeklatscht kommt man da nicht weit. Denn nicht nur der Kunde auch man selbst muss damit lange Zeit klarkommen. Da darf man gern vorher Zeit zum Entwerfen investieren um spaeteren Aerger vorzubeugen.
Es ist nur das Werkzeug, mit dem ich einen großen Teil meines Berufes ausführe. (Antwort auf die nächste Frage: Computerphysik)
Also wissenschaftliches Rechnen? Dieser Teil Softwaere ist in meinen Anwendungen recht einfach zu designen.
-
Kommt wohl ziemlich stark darauf an, wie viel Erfahrung man in dem Bereich hat. Wenn man bereits viel Erfahrung hat, kann man auch relativ effizient einen groben Bauplan erdenken bevor man anfängt. Ist das nicht der Fall, will man eben erst mal sehen wie das alles denn zusammenhängt.
-
Damit hörst du warscheinlich auf, wenn du mal ein größeres Projekt machst und aufgrund von Reperaturen am schlechten Design erstmal ein paar Tage Fleißarbeit einschieben musst, um alles auf das neue Design umzuschreiben.
Ich sitze da generell wie ein Psychopath am Rechner, zusammengebissene Zähne und nervöses Kopfwippen. :p
-
Ich sitze da generell wie ein Psychopath am Rechner, zusammengebissene Zähne und nervöses Kopfwippen.
Ja, so auch ich.
-
Sone schrieb:
ich gehe oft den Design-Weg: Klatsch es hin, dann ordne es und mache es schön.
Das klappt bei winzigen Anwendungen vielleicht, aus meiner Projekterfahrung kann ich dir aber sagen, das du nur selten die Gelegenheit hast etwas nachträglich zu verbessern, bis hin das eine Anwendung dann irgendwann nicht mehr wartbar ist. Ich saß schon bei einem Arbeitgeber wo etwa 90% meiner Zeit aus dem Abarbeiten von Fehlern Bestand - mit entsprechend unzufriedenen Kunden.
Die Gefahr ist zudem sehr groß das ein Manager nach dem Prinzip: Es kompiliert => ausliefern! Hantiert...
-
Nochmal: Natürlich plane ich die Dinge im Voraus. Aber manchmal, wenn ich zusätzlich sehe, aha, da geht was viel schöner, dass kann man auslagern, das könnte hierhin oder dorthin kommen, dann denk ich mir:
Bring das Ding erst zum Laufen, dann mach den Code schöner.
-
Ich finde auch, das kommt sehr stark aufs Projekt an. Und es kommt darauf an, in welchem Umfang man plant.
Für viele Projekte mit einfacher Struktur und vor allem, bei denen ungewiss ist, wo es überhaupt hinlaufen soll, finde ich es ok mit einer sehr einfachen Trennung von Backend und Frontend zu arbeiten. Man kann ja während dem Entwickeln auch modular Klassen entwickeln, sodass die sich gut einzeln rausnehmen lassen. Und man kann die Abhängigkeiten versuchen gering zu halten. Das ist nicht viel, aber viele Projekte haben schon dort zu starke Kopplung, die später eine Erweiterung vereinfacht hätten - komplett ohne Planung.
Kann man von vornerein schon absehen, dass es sehr viele Abhängigkeiten geben wird, dann sollte man da genau planen, wie diese aussehen könnten und wie man die erweitern kann.
Beispielsweise sind viele Geschäftsanwendungen sehr simpel (ohne Frage kann es auch umgekehrt extrem komplizierte geben!), weil man im Endeffekt an vielen Stellen nur Transaktionen hat, die einzelne Datenbanktabellen betreffen. Dann kann man Klassen schreiben, welche 1:1 zu einer Datenbanktabelle passen und hat im besten Fall auch genau eine UI-Ansicht für diese Tabelle. Das ist sowieso total modular, hier braucht man nicht viel planen.
So eine 3D-Engine hingegen hat viele Elemente, die voneinander abhängig sind. Man muss auch in der Ablage der Struktur schon bedenken, dass das performant laufen muss, was aber nötig und daher auch nicht premature optimization ist.
Bring das Ding erst zum Laufen, dann mach den Code schöner.
Da stimme ich zu, wenn man sich in ein neues Themengebiet begiebt und merkt, dass man noch gar nicht planen kann. Bei 3D-Engines habe ich das auch immer. Das ist für mich aber eine Art des Lernens. Wenn ich im Fachgebiet bereits spitze bin, dann kann ich auch bis zu dem Grad planen, der notwendig ist, um es relativ unwahrscheinlich zu machen, dass ich später ein riesiges Refactoring machen muss. Aber so tief muss man erstmal drin sein. (<- d.h. volle Zustimmung an cooky451).
Ethon, asc:
Habt ihr Beispiele, was an den Projekten punkto Architektur so daneben war? Und was für Projekte waren das, also in welchem Gebiet? Hätte man das mit Vorausplanung lösen können bzw. hätte die Vorausplanung Fachwissen erfordert?
-
Habt ihr Beispiele, was an den Projekten punkto Architektur so daneben war?
Ja, der Quelltext meines Vorgaengers. Leider darf ich nicht mehr preisgeben.
-
Nicht Mal irgendwie den Kontext oder den Bereich? Du kannst ja sagen, das war ne Geschäftsanwendung, ne Bibliothek... damit gibt's Du doch nichts Vertrauliches preis. Aber das würde Mal etwas Substanz für ne vernünftige Diskussion schaffen.
-
Bildverarbeitung, Kommunikation mit einer Industriekammera und PCI-Treiber und Firmware.
-
Okay, da würde ich als Laie in diesem Gebiet schon Mal drei Schichten basteln. Aber das gab's da ja vermutlich auch. D.h. der hat in einem der drei Bereiche einfach irgendein Kokolores gemacht aber da darfste nicht mehr preisgeben, was der falsch gemacht hat oder ob man das mit mehr Vorausdenken hätte verbessern können?
-
Eisflamme schrieb:
Habt ihr Beispiele, was an den Projekten punkto Architektur so daneben war? Und was für Projekte waren das, also in welchem Gebiet? Hätte man das mit Vorausplanung lösen können bzw. hätte die Vorausplanung Fachwissen erfordert?
Das Projekt wurde immer nach dem Prinzip weiter gebaut: schnell, schnell, schnell. Weder wurde irgendwann einmal Zeit gegeben um Code nochmals überarbeiten zu können, noch wurde für eine Umsetzung auch wirklich realistische Zeitfenster eingeplant (Ich erinnere mich, das mein ehemaliger Chef meinte, das ich eine Projektplanung ala MS Project in 3 Wochen zusammenschreiben können muss - Noch nicht einmal eine grafische Komponente für eine Gantt-Darstellung war zu diesem Zeitpunkt vorhanden).
Das Projekt war ein umfangreiches CRM-System mit vielen Modulen und viel Kundenspezifischen Anpassungen (Nicht in der Größe eines SAP, aber zu dem Zeitpunkt hatte es schätzungsweise 5 Mio Codezeilen [Kommentare existierten in den Projekt so gut wie nicht, daher kann man die Zahl auch so nehmen]). Alles in C++ geschrieben und zu dem Zeitpunkt wo ich begonnen habe, war das Projekt schon etwa 15 Jahre in der Entwicklung.
Was das Design angeht mehrere kleine Anmerkungen: Ich hatte mir mal ein Buch über Antipattern zugelegt, und nach der Hälfte entnerft aufgegeben, weil ich doch gerne mal über eins gelesen hätte das im Projekt nicht intensiv genutzt wurde).
- Die Dateien hatten teilweise mehre 10000 Zeilen, die nur wenig miteinander zu tun hatten, aber in eine Klasse geschmissen wurden.
- Nahezu alles war public und static (C++), und diese statischen Membervariablen wurden nicht selten gänzlich unterschiedlich genutzt. Und das noch verschärft dadurch das die entsprechenden Codestellen auch durchaus gleichzeitig aktiv waren.
- Hast du schon einmal 5fach+ Zeiger gesehen? Ich in dem Projekt das erste mal. Dieses Monsterkonstrukt sollte ich nach Möglichkeit (und völlig undokumentiert) nutzen, weil die Standardbibliotheken ja im Gegensatz dazu angeblich so langsam und fehlerhaft seien.
- Schichtentrennung? Oh, es gab im wesentlichen 2 Schichten: DB (Oracle mit extrem viel STP-Logik*) und Client ;p. Wenigstens wurde noch "horizontal" getrennt. Die Module selbst waren in eigenen DLLs untergebracht.* Die ist bei den Codezeilen auch nicht mit eingerechnet, ich schätze das waren auch noch mal 1 Mio Zeilen vom Umfang her.
Es gab im gesamten Projekt keine wirklich sichtbare Struktur, es gab keinerlei Dokumentationen und auch niemanden der wirklich Fragen beantworten wollte. Zudem wurde die Situation noch dadurch erschwert das der DB-Mensch mitten im laufenden Betrieb ständig die DB geändert hatte, und wenn dann etwas nicht lief waren die C++ Entwickler schuld, obwohl sich am Programm seit 2 Wochen nichts geändert hatte usw.
Fangen wir mal mit den wichtigsten Verbesserungen an, die dem Projekt etwas genutzt hätten:
1. Bessere Kommunikation.
2. Wenigstens grundlegende Dokumentation der Geschäftslogik.
3. Wesentlich besseres Projekt- und Zeitmanagement.Von der Codeseite war nicht viel zu retten, hier hätte man wirklich massive Umbaumaßnahmen vornehmen müssen, man hätte ja mit den kleinen Modulen anfangen können.
Ich war mit knapp 4 1/4 Jahren nach meiner Recherche einer der 3 längst Angestellten Entwickler im Projekt (ein anderer war nur unwesentlich länger dort), die meisten haben von sich aus wohl in der Probezeit oder spätestens nach 1-2 Jahren gekündigt. Nur die beiden Chefs (einer gleichzeitig der C++ Chefentwickler, anderer der Datenbankmensch) haben die Zeit überdauert.
-
asc: Traurig.
-
Wow! Aber das sind ja architekturelle Anfängerfehler (erzwungen durch Management, will nicht sagen, dass der Chefentwickler Schuld ist), würde ich Mal sagen, echt krass. Aber danke fürs Ausführen, ich hätte nicht gedacht, dass jemand 5fach-Zeiger nutzt, ich bin beeindruckt.
-
ich hätte nicht gedacht, dass jemand 5fach-Zeiger nutzt, ich bin beeindruckt.
Vielleicht bei Boost?
Neh, ich auch nicht. Ich nutze nur ganz normale Rohe Zeiger, um eine nicht-besitzende, variable Referenz auf etwas zu haben. Das wars schon.
-
Ich mache die zeitaufwendige Taktik:
Drauf los programmieren.
Feststellen, dass es da ein Problem gibt.
Ewig nach einem Workaround suchen.
Aufgeben.
Komplettes Projekt in die Tonne schießen.
Neu programmieren.
Feststellen, dass der Fehler da immer noch ist.
Aufgeben.
Komplettes Projekt in die Tonne schießen.
Grobes Design überdenken.
Scheitern.
Feststellen, dass man die Klassenaufgabe falsch modelliert hat und deswegen der Fehler auftrat.
Neu programmieren.
Klappt.Das war in etwa der Werdegang meines C++ Wrappers um die WinAPI.