Problem analysieren / passende Architektur finden

Saheeda

Mitglied
Hallo,

ich bin im 1. Lehrjahr zum AE und es fällt mir momentan noch ziemlich schwer, ein Problem zu zerlegen und mir eine sinnvolle Architektur zu überlegen, _bevor_ ich mit Programmieren anfange.
Mit UML-Diagrammen arbeite ich auch, wobei ich speziell bei Klassendiagrammen nicht weiß, wie/wo ich anfangen soll und dann doch wieder einfach drauf los schreibe...
Momentan beschäftige ich mich mit design patterns (ich suche mir ein pattern, programmiere 1-2 Beispiele nach und bau mir dann eigene) und habe vor einer Weile "Clean Code" gelesen.

Habt ihr vielleicht noch weitere Tipps für mich?
 
Die Frage scheint mir doch etwas Allgemein zu sein, "Wie werde ich ein guter Programmierer?".

Die Antwort ist deutlich schwieriger als die Frage konkreter zu formulieren. Da ich nicht genügend über dein Vorwissen weiß, oder erraten könnte, muss ich natürlich auch auf eine sehr abstrakte Ebene zurück fallen.

So sind folgende Punkte wohl die "großen" wichtigen Punkte, bzw. gehen auf deine Post oben ein:
- Clean Code, bereits erwähnt, wird aber von 10 Personen auf 12 Arten interpretiert. Ich würde hier subjektiv vorallem auf gute Lesbarkeit und Selbsterklärung achten. Stell dir die Frage "würde ich das verstehen, wenn ich es in 1 Jahr anschauen würde"
- Kommentare sind das A und O, natürlich nicht übertreiben und einzelne Code-Zeilen beschreiben ;)
- Die großen Pattern, wie MVC, Observer, Proxy, Composite und was es da alles so gibt, sind sehr interessant als Lernhilfe zum erkennen von abstrakten Lösungsmöglichkeiten. Nicht alles sollte streng nach deren Regeln programmiert werden, so wie sie auch erst entstanden sind, weil viele Leute die gleichen Probleme auf ähnliche Weise gelöst haben. Die wurden aber ja schon erwähnt.
- Sowohl UML als auch Klassendiagramme sind schöne Dinge, aber nur in sehr spezifischen Umgebungen. Große Gruppen (Firmen o.ä.) können so zum Beispiel für alle ersichtlich die Grundlagen und Verhaltensweise eines Programms darlegen und schaffen sich so ein gemeinsames Ziel und Funktionsumfang. Für eine einzelne Person sind solche Diagramme häufig nur unübersichtlich und insbesondere zusätzliche Arbeit mit sehr geringem zusätzlichem Nutzen (meiner Meinung nach). Aber auch für Einzelpersonen sehe ich einen Vorteil, den des gedanklichen strukturierens einer Idee, das Verständnis eines großen Ganzen. Müsste ich etwas empfehlen, würde ich diese Diagramme für den Anfang empfehlen, um sich an die Strukturierung von Programmen zu gewöhnen, aber sie so bald wie möglich wieder ablegen. (Ausgenommen sehr große Programme)
- Rekursives Programmieren ist in der Praxis meist untauglich, da z.B. die Wartbarkeit stark leidet, aber zeigt sehr schön einige Sonderheiten und Stile auf. Scheme eignet sich dafür wunderbar, um sich etwas damit vertraut zu machen.

Die Überlegungen zu einer Architektur oder auch Aufbau eines Programms sind allgemein die schwierigsten. Möglichkeiten um spezifisch diese Fähigkeit zu trainieren, würden mir nicht einfallen, abgesehen von stumpfem Habe-ein-programm-und-überlege-Stuktur-bevor-du-dir-die-Lösung-anschaust. Ich würde behaupten, dass das Beste Training in viel Programmieren besteht. Bei mir ist es so, dass sich einige Architekturen in meinem Kopf bereits gebildet haben, welche ich als Themeplate auf Problemstellungen anwenden kann, aber die haben sich auch erste daraus ergeben, dass ich auf eine ähnliche Problemstellung schonmal gestoßen bin und die auch selbst gelöst habe.


Falls das nicht hilfreich war: Das Thema ist wirklich komplex und wir haben fast zwei Uhr in der früh, ich entschuldige mich für verloren Zeit °3°
 
Ich würde behaupten, dass das Beste Training in viel Programmieren besteht. Bei mir ist es so, dass sich einige Architekturen in meinem Kopf bereits gebildet haben, welche ich als Themeplate auf Problemstellungen anwenden kann, aber die haben sich auch erste daraus ergeben, dass ich auf eine ähnliche Problemstellung schonmal gestoßen bin und die auch selbst gelöst habe.
Schön gesagt, kann ich so mit unterschreiben.
 
Von mir nur ein paar stichpunktartige Tips, da der Rest größtenteils schon erwähnt worden ist ;)

- Qualitativ hochwertigen Code von anderen lesen, verstehen und evtl. erweitern.
- Niemals "Hauptsache es funktioniert" sagen!* => Eigenen Code verbessern
- Ich bevorzuge ein Blatt Papier oder ein Whiteboard anstatt UML-Diagramme, bei der ist zusammenklicken muss. Natürlich hätte ich dann eine automatische Codegenerierung, aber es ist niemals so flexibel wie die eigene Hand.
- Code nicht in Design Patterns zwingen, als wären sie einem indoktriniert worden)! Siehe http://programmers.stackexchange.com/q/257885/53812


*) Bei einem Prototyp oder einem sehr kleinen Programm mag das natürlich anders sein, doch erfahrungsgemäß ist diese Haltung ohne Zusätze eine schlechte Eigenschaft.
 
Hi,

danke für die Antworten, irgendwie habe ich geahnt, dass die Frage zu schwammig ist.

@CookieBuster
Meine Idee beim Patterns-Lernen ist:
Gewisse Probleme tauchen sehr häufig auf, demzufolge ist es nur logisch, dass es bereits Lösungswege gibt und sich einige davon besser bewährt haben, als andere.
Wenn ich einige Muster/"Schablonen" habe, fällt es mir leichter, einen Ansatz für mein Problem zu finden, als wenn ich jedes Mal versuche, das Rad neu zu erfinden.

Mir ist aber auch klar, dass man nicht alles 1:1 umsetzen kann, sonders es oft eher Vorschläge als Vorschriften sind.

@ComFreek
Ich gehe meistens nach dem Schema vor "erst was Funktionierendes, danach was Schönes". Heißt: Ich schreibe mir nen Code, der das tut, was er soll. Dabei fallen mir manchmal schon Muster auf und ich merke, was ich zusammenfassen kann. Wenn ich das habe, mache ich Refactoring bis ichs "schön" finde.



Mein Problem ist aber auch beim händischen Zeichnen: Wo anfangen?

Ich brauche ja trotz allem einen Startpunkt, von dem aus ich den Rest weiterspinnen kann.
Dem Programmablauf folgen? (Programm wird gestartet, Meldung x erscheint, User soll y eingeben, mit y soll z gemacht werden...)
Von der GUI ausgehen? (Wir haben Button a, der soll Aktion b auslösen, das löst Aktion c aus ...)
Von der tiefsten Ebene ausgehen? (Der Wert x soll in den Speicher, wie kommt er da hin? Und wie kriege ich ihn wieder zurück?)
 
Ich gehe meistens nach dem Schema vor "erst was Funktionierendes, danach was Schönes". Heißt: Ich schreibe mir nen Code, der das tut, was er soll. Dabei fallen mir manchmal schon Muster auf und ich merke, was ich zusammenfassen kann. Wenn ich das habe, mache ich Refactoring bis ichs "schön" finde.
Versuche in Zukunft, gleich etwas Vernünftiges (Schönes) zu schreiben, denn das spart Zeit. Konzentriere dich aber nicht zu sehr darauf, manchmal kostet dies selbst mehr Zeit, wenn du zum Beispiel nur einen Prototypen willst.
Natürlich kann man nie von Anfang an den perfekten Code schreiben.

Willst du die GUI beschreiben? Wenn ja, dann fange dort an.
Willst du den Kern deines Programms beschreiben? Wenn ja, dann versuche herauszufinden, was für Objekte in deinem Programmablauf eine Rolle spielen und was für eine Gliederung sinnvoll erscheint. Bei Excel gibt es z. B. Workbook, Worksheets, Ranges, Cells.

Ich starte meine Überlegungen meist ohne GUI, aber das hängt immer von einer Applikation, die du entwickeln möchtest, ab.
 
Zurück