"Schmutziges Programmieren" vermeiden

[Arbon]

Hallo

Ich habe das Problem, dass ich bei größeren Projekten immer sozusagen im Chaos versinke. Der Code funktioniert zwar, ist allerdings schwer zu durchblicken, ziemlich ungeordnet sowie schwer erweiterbar. Ich habe schon oft probiert, das zu vermeiden, aber am Ende stellte sich immer das selbe heraus.

Ich würde jetzt gerne wissen, wie man lernen kann so etwas zu vermeiden. Spontan werdet ihr euch sicher denken, plane erstmal ordendlich und leg dann erst los. Das Problem dabei ist, dass ich mir am Anfang ziemlich schwer vorstellen kann, welche Klassen ich alle benötige, was ich am besten wie mache und wie die Klassen miteinander kommunizieren (mein größtes übel :S). Auch beim Einsatz von Design-Pattern fällt es mir schwer zu entscheiden was jetzt für ein bestimmtes Programm / Situation am besten geeignet wäre und wie ich es sauber implementiere.

Wäre auch nett, wenn ihr ein paar Beispiele hättet wie eine gute Struktur aussieht.

mfg

 

[maki]

Wirst lachen, kenne keinen der es beim ersten Mal schafft sauberen Code zu erstellen, funktionsfähigen ja, aber das reicht bei weitem nicht wenn man weiss, dass die meisten Kosten während des Supports/Erweiterungen anfallen.

Die Lösung?
"Make it work, make it clean"

Unittests & Refactoring, dazu noch ein paar Grundregeln, und schon sieht der Code viel besser aus.

Jedenfalls ist man nicht fertig wenn der Code nur richtig funktioniert.

Kann dir da ein paar Bücher empfehlen:
Amazon.com: Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series): Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: Books

Amazon.com: Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series): Robert C. Martin: Books

Amazon.com: Test Driven Development: By Example (Addison-Wesley Signature Series): Kent Beck: Books

Jedenfalls brauchst du (gute) Unittests, sonst wirst du nie wirklich refactoren.

 

[Verjigorm]

Es gibt hilfreiche Plugins für Eclipse, wie z.B. Findbugs, Enerjy etc. die dir schonmal die gröbsten Schnitzer aufzeigen

 

[byte]

Kann mich Maki nur anschließen. Refactoring heisst das Zauberwort. Selten macht man gleich am Anfang alles perfekt. Das geht meistens auch gar nicht, weil sich die Anforderungen häufig während der Entwicklung ändern. Oder es fällt einem dann doch noch was ein, was man anfangs nicht bedacht hat.

Was macht man dann also? Refactoring! Wenn man Unittests geschrieben hat, kann man das auch ruhigen gewissens tun, ohne allzu große Risiken einzugehen, dass danach etwas nicht funktioniert.

Darüber hinaus machts einfach die Erfahrung. Wenn man immer bemüht ist, sich zu verbessern, dann wird man von Projekt zu Projekt besseren Code schreiben. Man kann auch sehr gut von anderen APIs lernen. Wenn die gut sind, sieht man wie man gewisse Dinge realisieren kann. Sind sie hingegen schlecht, dann weiss man, was man vermeiden sollte.

Ein Paradebeispiel für gutes Design ist das Spring Framework.


Aber Achtung: Man sollte es mit dem tollen Design auch nicht übertreiben. Solange man keine allgemeingültige API schreibt sondern eine Anwendung, muss man imo immer Kompromisse zw. gutem Design und Entwicklungsaufwand eingehen. Das perfekte Design ist nämlich in den meisten Fällen einfach zu aufwändig und rentiert sich häufig auch nicht (mal ganz davon abgesehen, dass es das perfekte Design wohl gar nicht gibt *g*).

 

[Arbon]

Refactoring und Testing sind schon einmal sehr interessante Methoden um ein bestehendes Programm zu verändern und "aufzuräumen".

Allerdings würde ich jetzt gerne wissen, wie man ein Projekt gut und sinnvoll planen kann. Ich nehme jetzt zum Beispiel mein aktuelles Projekt, einen kleinen Dateimanager her. Hier stellen sich mir dann immer Fragen wie
Wie speichere ich die aktuell ausgewählten Dateien ab? Frage ich sie immer aus der Oberfläche ab? Aktualisiere ich ein File Array mit den ausgewählten Daten wenn der User andere auswählt?
Wie realisiere ich die Kommunikation zwischen der Oberfläche und den Dateioperationen am besten?
Wie übergebe ich am besten den aktuellen Kopierfortschritt an eine ProgressBar? Mache ich eine Klasse Kopieren, die bereits die Oberfläche beinhaltet und dann direkt aktualisiert wird? Versuche ich irgendwie über Listener die Kommunkation zu ermöglichen? Wie rufe ich in der Klasse Dateioperationen eine solche Kopie auf?

Fragen über Fragen, über die ich mir immer den Kopf zerbreche und am Ende meistens nichts ordendliches herauskommt, wodurch dann wieder das halbe Programm umgekrempelt gehört, obwohl ich es am liebsten ordendlich strukturiert hätte.
Mit dem Refactoring habt ihr mir ja jetzt eine gute Möglichkeit genannt wie man so ein Chaos einigermaßen behebt, allerdings würde ich ja jetzt gerne wissen wie man sich zuvor bereits ein solches Problem sinnvoll überlegt, damit so etwas wenn möglich gar nicht in dem Aufmaß auftritt.

mfg

 

[Wildcard]

Allerdings würde ich jetzt gerne wissen, wie man ein Projekt gut und sinnvoll planen kann.

Ich bin ein großer Fan von Model Driven Development geworden, speziell mit EMF. Wenn du ein solides, erweiterbares und flexibles Datenmodell hast, fallen viele anderen Puzzleteile einer Applikation wie von selbst an den richtigen Platz (natürlich nicht alle). Am Anfang ist es ein gewisser Umstieg, hat man aber das Konzept verstanden wird MDD/EMF zu einer Art Religion und verändert dauerhaft die Sichtweise auf Probleme.

Oft wird eine Applikation auch sehr viel besser (und man lernt dabei) wenn man sich selbst in das Korsett eines Frameworks zwingt. Du profitierst von der Arbeit anderer, was die Entwicklung beschleunigt, wirst aber gleichzeitig in eine bestimmte Richtung gepushed. Du wirst damit freundlich aber bestimmt zu einem gutem Anwendungsdesign gezwungen.
Beispiele dafür wären zB OSGi, Eclipse RCP, Spring,...

 

[Civilazi]

Fragen über Fragen, über die ich mir immer den Kopf zerbreche und am Ende meistens nichts ordendliches herauskommt, wodurch dann wieder das halbe Programm umgekrempelt gehört, obwohl ich es am liebsten ordendlich strukturiert hätte.
Mit dem Refactoring habt ihr mir ja jetzt eine gute Möglichkeit genannt wie man so ein Chaos einigermaßen behebt, allerdings würde ich ja jetzt gerne wissen wie man sich zuvor bereits ein solches Problem sinnvoll überlegt, damit so etwas wenn möglich gar nicht in dem Aufmaß auftritt.

mfg

Es gibt ja durchaus solche Tricks wie: mach eine MindMap, was gibt es, wer kennt was, wer tut was etc. Alles was dir einfällt. Dann streichst du Unwichtiges / Doppeltes und versuchst das in Javacode zu übersetzen. Wenn du dann anfängst, die unverfänglichen Sachen zu implementieren, denkst du schon weiter über das Design nach. Vielleicht fällt dir dann schon irgendwas auf, das du ändern willst.
Dann ist es wichtig, dass sobald dir etwas auffällt, was sich aufgrund deines Designs blöd macht, du das Design eben änderst. Solche Frustmomente sind wichtig, dadurch merkst du es dir besser, sammelst Erfahrungen und erkennst später mögliche Probleme früher. Meiner Meinung nach sieht man dann auch mit steigender Erfahrung, wo man ein Problem hat, das sich mit einem bestimmten Pattern lösen lässt. Also: dein Problem sollte das Pattern bedingen, nicht umgekehrt
Ansonsten sind die ganzen anderen Tipps natürlich auch toll.

 

[Wildcard]

Es gibt ja durchaus solche Tricks wie: mach eine MindMap, was gibt es, wer kennt was, wer tut was etc.

Dafür ist aber UML eher geeignet zumal sich damit dank Tool Unterstützung gewisse Java Teile direkt generieren lassen.
Solange du damit die reine Datenebene (Domain Model) meinst, fährt man übrigens am besten mit MOF/EMF

 

[Civilazi]

Dafür ist aber UML eher geeignet zumal sich damit dank Tool Unterstützung gewisse Java Teile direkt generieren lassen.
Solange du damit die reine Datenebene (Domain Model) meinst, fährt man übrigens am besten mit MOF/EMF

Stimmt, allerdings fang ich eigentlich trotzdem immer mit Papier und Stift an. Diagramme mache ich als Zweites. Echtes UML ist ja schon fast Code, den man sich ja, wie du schon sagst, auch daraus generieren lassen kann.

 

[Wildcard]

Die UML ist explizit so designed das man sie zu Papier bringen kann mit nichts als einem Stift. Die Überführung ist Fleißarbeit und kann auch nach Indien ausgelagert werden

 

[sliwalker]

Hi,

interessante Aussagen. Die Anregungen nehme ich für mich auch mal mit
Kann allen nur beipflichten, dass sehr guter Code und ein sehr gutes Design nicht auf Anhieb klappen.
Da kann mir auch jeder erzählen was er will.

Aber man kann es jedesmal neu versuchen und wird auch immer besser.
Ich gehe da nach dem Prinzip der Leuchtspurmunition vor. Kleinere Teile als "prototypen" um zu gucken wie es klappt. Wenn man sich eine "komplizierte" Kommunikation ausdenkt, kann ich zumindest nicht immer in allen Bereichen vorhersagen, ob das so geht, ob mir nicht doch zwei Werte Fehlen oder sonst was.

Ich nehme auch den Ansatz vom Datenmodell auszugehen. Für mich ist das die Basis, die egal wo, immer gleich bleibt. Bei jedem Schritt überlege ich mir, ob ich das so programmieren kann, wenn ich nicht mehr eine Desktop Anwendung bedienen möchte, sondern eine Webseite. Daran erkenne ich meistens, wie stark ich Sachen fixiere. Und so kommt die Logik und die Zurgiffsschicht zustande. Danach hat man meistens keine Probleme mehr sauber die GUi davon zu trennen.

Bei Dingen wie die Kommunikation hilft halt meistens nur lesen, wenn man es nicht weiß. Ein paar Prinzipien haben sich bewährt andere nicht. Auch die Erfahrung kommt hier ins Spiel. Und ich weiß selbst manchmal nicht, ob das jeder so lösen würde und ob es da vielleicht etwas besseres gibt. Ob es gut ist oder nicht, sehe ich dann, wenn ich nach 3 Monaten nochmal ran muss Sicherlich nicht der beste Weg, aber dazu brauch ich noch ein paar Jahre mehr Berufserfahrung...für mich ist das soweit ok.

Nicht zuletzt kann man Fragen.
Mit einer ausformulierten Idee im Kopf, wird einem hier gern geholfen.
Da hilft es auch die Probleme anderer zu lesen und die Antworten der Stamm-Gurus hier.

greetz
SLi