Pc Software richtig erstellen

Hi Sven,

O'Reilly: Entwurfsmuster von Kopf bis Fuß:
http://www.oreilly.de/catalog/hfdesignpatger/

O'Reilly: Objektorientierte Analyse und Design von Kopf bis Fuß:
http://www.oreilly.de/catalog/hfobjectsger/

Teuer, unkonventionell und sehr gut!
Bin auch gerade dabei mich in gute Softwarearchitektur/-design 
einzulesen und beide Bücher sind dabei sehr hilfreich. Sehr ausführliche 
Herangehensweise an die Beispiele. Die Bücher bestehen aus vielen 
Beispielen und Merkregeln, das alles aufeinander aufbaut/ineinander 
greift.

Der Aufbau ist eigentlich folgender: Es wird ein Problem beschrieben, 
dann eine Lösung präsentiert. Hatte oft den Effekt, dass ich eigentlich 
auf genau die gleiche Lösung gekommen bin (freu), dann aber im nächsten 
Abschnitt die Erklärung stand, dass und WEIL das zuvor geschriebene noch 
verbessert werden kann. :-) Dann sofort gedacht, ja klar, das 
Neue/Erweiterte ist ganz klar viel besser. So hätte ichs jetzt auch 
gemacht. Dann nächstes Kapitel, und jetzt kann man noch dies und das 
verbessern... Wirklich gute Methodik.

Also nicht nur Hingeklatsche von Beispielen, sondern ERARBEITEN von 
Lösungen.

Ich hatte mit dem oberen Buch angefangen und würde das wieder so tun.

Tipp: Programmieren um des Programmierens Willen bringt nix, ebensowenig 
künstliche und herbeigezogene Beispiele.

Programmier dein Projekt -- du wirst von ganz alleine an Punkte kommen, 
wo du dir denkst, 'Mensch, das wird immer 
konfuser|komplexer|chaotischer|länger', und wenn du da stehst, erarbeite 
dir ne Lösung an deinem Problem, nich an irgendwelchen Entchen und 
Gequake, sondern an deinem konkreten Problem.

Es ist überdies m.M.n. auch völlig normal, dass man zu Beginn ein 
Projekt mal umwirft und neu aufstellt. Du wirst immer wieder Aspekte 
entdecken, die ein neues Konzept erfordern, auch wenn du dir vorher 
monatelang den Kopf zerplant hast.

Sieht vielversprechend aus!
Ich hoffe das Buch ist das Geld wert.
Kennt sonst noch jemand etwas in der Art.

Danke für den Tip

Gruß
Seven

Gruß Sven

Natürlich

> wenn du da stehst, erarbeite dir ne Lösung an deinem Problem, nich an
> irgendwelchen Entchen und Gequake, sondern an deinem konkreten Problem.
Wenn du eine Schraube reindrehen willst, aber nicht weisst, dass es 
einen Schraubendreher gibt, dann kommst du alleine nicht weiter. Wenn 
der "Schraubendreher" dann halt in Form von quakenden Enten kommt (die 
Transferleistung kriegt man dann hin) - warum nicht?

> Du wirst immer wieder Aspekte entdecken, die ein neues Konzept erfordern,
> auch wenn du dir vorher monatelang den Kopf zerplant hast.
Ja, deshalb ist z.B. eine Aussage des zweiten Buchs: Mach erst dasses 
läuft, machs dann erst flexibel, schön und wartbar. Danach dann in die 
nächste Runde... alles ein iterativer Prozess. Nicht zu viel auf einmal.


Ach übrigens, fürs Verständnis von .net (Gui-Zeugs usw.) hat mir auch 
Charles Petzold sehr weitergeholfen: 
http://www.amazon.de/Windows-Programmierung-mit-Visual-C/dp/3860636529 
und das Update auf .net 2.0: 
http://www.amazon.de/Windows-Forms-Programmierung-Visual-sharp-2005/dp/3860639854

Rainer schrieb:
>> wenn du da stehst, erarbeite dir ne Lösung an deinem Problem, nich an
>> irgendwelchen Entchen und Gequake, sondern an deinem konkreten Problem.
> Wenn du eine Schraube reindrehen willst, aber nicht weisst, dass es
> einen Schraubendreher gibt, dann kommst du alleine nicht weiter. Wenn
> der "Schraubendreher" dann halt in Form von quakenden Enten kommt (die
> Transferleistung kriegt man dann hin) - warum nicht?
Nich alles, was hinkt, .. :-)

Ich meins eher so: Du gehst ja auch nicht zuerst hin und übst den Umgang 
mit dem Akkuschrauber und -bohrer, informierst dich über allerhand 
erhältliche Schrauben- und Dübeltypen und so weiter, für den Fall, dass 
du irgendwann mal ein Bild aufhängen möchtest.
Wenn du ein Bild hast, guckste nach der Wand, findest nen passenden 
Dübel, bohrst und gut is.

Lern es, wenn du es brauchst, und dann ordentlich und konkret. Bringt 
mehr, als nachher immer wieder an abstruse bis abstrakte Beispiele zu 
denken und zu grübel, welches denn nun am besten passt. Es gibt nunmal 
nicht den goldenen Weg, an den man sich hält -- kreative Probleme 
erfordern kreative Lösungen.

> Nich alles, was hinkt, .. :-)
Ich gebs zu, aber die Idee dahinter ist ja rübergekommen.

> Ich meins eher so: Du gehst ja auch nicht zuerst hin und übst den Umgang
> mit dem Akkuschrauber[...]
Da sind wir uns absolut einig.

> kreative Probleme erfordern kreative Lösungen.
Ich hätte gerne eine "handwerkliche" Lösung, die mich definiert (und 
nicht zufällig) ans Ziel bringt. Für jeden Mist gibts anerkannte 
"Schritt-für-Schritt-Verfahren", nur für den "kreativen" Teil der 
SW-Entwicklung soll das nicht gelten. Das will ich nicht glauben. :-)
 Der E-Ing. plant seinen Schaltplan aus AppNotes und Datenblätter, 
zeichnet alles "standardisiert" auf, macht das Layout und erhalt ein 
Produkt das er mit Methoden entwickelt hat, die zu messbaren 
Qualitätsergebnissen führen. Jeden einzelnen Punkt kann er nachlesen. 
90% aller Projekte kommen so zum Ziel.

Nur in der Softwareentwicklung soll alles hauptsächlich Bauchsache sein?
Genau diese Bauchsache muss doch irgendwann in Erfahrung münden. Diese 
muss sich formulieren (und in ein Buch bringen) lassen. Aber scheinbar 
gibts nicht so viele (oder zuviele?) allgemeingültige Verfahren oder 
keiner will das aufschreiben?!?

(Mit Softwareentwicklung meine ich hier Design/Konzept erstellen und den 
Schritt zur Implementierung; den Rest vom ganzen Entwicklungsprozess hat 
man ja inzwischen schon besser im Griff).

Das gibts in der SW auch: Statt Bauteilen und Datenblättern hast du 
Bibliotheken, APIs und deren Dokumentation mit Beispielen. Statt 
etablierten Geräten spickst du halt in anderen Programmen.

Für viele Dinge gibts ja handwerkliche Methoden, quasi 'Idiome': Der 
Aufruf von select() auf Unix folgt beispielsweise i.d.R. einem gängigen 
Schema, das sich auch im Quelltext wiederfindet. Genauso der Aufbau von 
QT-Programmen oder von Programmen überhaupt (main(), getopt(), ...).
In der Elektrik haste dafür halt etablierte Schaltungen (Royer-Wandler, 
Sinusoszillator...) und Methoden (Knotenspannungsanalyse, ...).

Aber du wirst jetzt keine Checkliste finden, mit der du ein Projekt 
erledigst, so von wegen 'ich brauche einen Fluxkompensator' -- Schritt 
1, Schritt 2, Schritt 3, fertig ist der Fluxkompensator.

QS gibts in der SW genauso wie in der HW. Und seien es simple Dinge wie 
'keine 90°-Knicke in Leiterbahnen' und 'vermeide gets()'. Aber damit 
strickt sich noch lange kein Projekt von selbst :-)

Entwicklung ist Kunst, sonst bräuchte man keine Entwickler.

> Für viele Dinge gibts ja handwerkliche Methoden, quasi 'Idiome': Der
> Aufruf von select() auf Unix folgt beispielsweise i.d.R. einem gängigen
> Schema, das sich auch im Quelltext wiederfindet. Genauso der Aufbau von
> QT-Programmen oder von Programmen überhaupt (main(), getopt(), ...).
Und jetzt sind wir genau beim Thema: Wie eigne ich mir dieses Wissen an? 
Wie baue ich eine gute SW (Rezepte, Vorgehen, Verfahren).
Und sage jetzt nicht, dass man dafür jahrelang probieren muss oder 
tausend verstreute Sourcen durchstöbern muss, um von selbst drauf zu 
kommen... ;-)

> QS gibts in der SW genauso wie in der HW. [...] 'vermeide gets()'
Auch wenns vielleicht abgedroschen ist: Ich will kein Faktenwissen, 
sondern Methodenwissen.

> Aber du wirst jetzt keine Checkliste finden, mit der du ein Projekt
> erledigst,
Genau das suche ich aber (auch; bin ja nicht der Threadstarter). Naja, 
vielleicht nicht gleich ein Projekt, sondern ein (Teil-)Problem und auch 
auf etwas höherer Ebene, aber nicht abstrakt.

> Entwicklung ist Kunst, sonst bräuchte man keine Entwickler.
Entwicklung sollte Handwerk sein (damit ich mich auf das wirkliche 
Problem konzentrieren kann, nicht darauf WIE ich mein Problem am besten 
organisiere) - ich wiederhole mich. Aber vielleicht sind auch die 
Grenzen fließend. :-)

Vielleicht können wir uns so einigen: Der Algorithmus ist Kunst, die 
Verwendung dessen sollte Handwerk sein.

Rainer schrieb:
>> Für viele Dinge gibts ja handwerkliche Methoden, quasi 'Idiome': Der
>> Aufruf von select() auf Unix folgt beispielsweise i.d.R. einem gängigen
>> Schema, das sich auch im Quelltext wiederfindet. Genauso der Aufbau von
>> QT-Programmen oder von Programmen überhaupt (main(), getopt(), ...).
> Und jetzt sind wir genau beim Thema: Wie eigne ich mir dieses Wissen an?
In den allermeisten Fällen hat sich irgendjemand das mal ausgedacht und 
andere fanden es akzeptabel bis gut.
Aneignen tustes dir, wie in der Elektrik auch: Bestehende Anlagen und 
Schaltungen (Programme) anschauen, Anweisungen und Beispiele der 
Hersteller (Autoren der Bibliothek) befolgen.

>> QS gibts in der SW genauso wie in der HW. [...] 'vermeide gets()'
> Auch wenns vielleicht abgedroschen ist: Ich will kein Faktenwissen,
> sondern Methodenwissen.
>
>> Aber du wirst jetzt keine Checkliste finden, mit der du ein Projekt
>> erledigst,
> Genau das suche ich aber (auch; bin ja nicht der Threadstarter). Naja,
> vielleicht nicht gleich ein Projekt, sondern ein (Teil-)Problem und auch
> auf etwas höherer Ebene, aber nicht abstrakt.
Was erwartest du? Sowas?
1. Ziel festlegen
2. Module festlegen und verteilen
3. Kapseln und Reviews machen
4. Zusammenbauen

>> Entwicklung ist Kunst, sonst bräuchte man keine Entwickler.
> Entwicklung sollte Handwerk sein (damit ich mich auf das wirkliche
> Problem konzentrieren kann, nicht darauf WIE ich mein Problem am besten
> organisiere) - ich wiederhole mich. Aber vielleicht sind auch die
> Grenzen fließend. :-)
>
> Vielleicht können wir uns so einigen: Der Algorithmus ist Kunst, die
> Verwendung dessen sollte Handwerk sein.
Joa, aber es gibt nicht den Algorithmus. Natürlich bringt man 
irgendwann man den 'stinknormalen' Aufbau eines Programms (main, 
getopt..) flux von der Hand oder beschaltet einen NE555 aus dem Kopf und 
wählt den LM2575. Da gibts etliche kleine Algorithmen, beim LM2575 
stehen die sogar im Datenblatt.

> Was erwartest du? Sowas?
> 1. Ziel festlegen
> 2. Module festlegen und verteilen
> 3. Kapseln und Reviews machen
> 4. Zusammenbauen
Nein, das ist das was man in all den "tollen" Büchern findet: viel 
Prozessbeschreibung, aber immer ist ausgespart, wie man das Design 
konkret (gerne auch mit Enten oder Hundehütten) umsetzt. Wie organisiere 
ich meine Daten (was gehört in diese Klasse, was gehört besser in eine 
eigene Klasse; wann vererben, wann komponieren...)? Welche Sprachmittel 
bieten sich an? Was hat sich in der Praxis als gut erwiesen? Warum macht 
man das nicht anders?
Aber stattdessen viele Worte um testgetriebene Entwicklung, agile 
Arbeitsweise, Stakeholder und das ganze Zeugs. (Mag auch seine 
Berechtigung haben, aber ist nicht das was wir hier suchen).

> Natürlich bringt man irgendwann man den 'stinknormalen' Aufbau eines
> Programms (main, getopt..) flux von der Hand
Ich möchte das "irgendwann" vorziehen, offenbar weiss schon jemand, dass 
man das so macht... das dann gesammelt, aufbereitet und 
runtergeschrieben -> perfekt. :-)

Beispiel: In tausend C#-Büchern kriege ich erklärt was ein Button, eine 
Picturebox oder ein UserControl ist. Aber keiner (außer z.B. Petzold) 
erzählt mir, dass ich grundsätzlich im Paint-Event meine Ausgaben 
zeichnen muss, um nicht bei Fensterüberlappungen den Inhalt zu 
verlieren... Das sind die Dinge, die ich zusätzlich wissen muss(!).
Umgemünzt auf die OO-Kiste: Tausend Autoren erklären mir was eine 
Klasse, Methode und ein Event ist, aber wann und wie ich ein Event 
nutzbringend anwenden kann, das wird (wenn überhaupt) nur sehr dünn 
behandelt. Hier setzen dann z.B. Entwurfsmuterbücher (z.B. MVC + 
Observer) an. Aber wenn man das nicht irgendwann rausfindet, gelitten. 
Einen Hinweis in den Grundlagenbüchern wo/wie es tiefer geht gibts 
nicht.

Rainer schrieb:
> Beispiel: In tausend C#-Büchern kriege ich erklärt was ein Button, eine
> Picturebox oder ein UserControl ist. Aber keiner (außer z.B. Petzold)
> erzählt mir, dass ich grundsätzlich im Paint-Event meine Ausgaben
> zeichnen muss, um nicht bei Fensterüberlappungen den Inhalt zu
> verlieren... Das sind die Dinge, die ich zusätzlich wissen muss(!).
Ja, deshalb stehen solche Dinge auch mit absoluter Sicherheit in der 
Dokumentation zur API, zum Framework, zu XYZ.
Bei X11 steht das mit dem Neuzeichnen z.B. lang und breit in der Doku 
unter 'XExposeEvent' im XLib Reference Manual.

> Umgemünzt auf die OO-Kiste: Tausend Autoren erklären mir was eine
> Klasse, Methode und ein Event ist, aber wann und wie ich ein Event
> nutzbringend anwenden kann, das wird (wenn überhaupt) nur sehr dünn
> behandelt.
Weil es sich kaum behandeln lässt -- guck mal in die Extrema: Java z.B.; 
da wird alles auf Teufel-komm-raus in Objekte verpackt, das hat man halt 
als 'Entwurfsmuster' so ausgelegt. Resultat ist dann, dass man für jede 
simple Aufgabe sofort dies und jenes in irgendwelche Klassen verpacken 
muss, wobei man am besten noch Interfaces umsetzt muss und dann 9 von 10 
Prozeduren nur leere Platzhalter sind usw.

Andres Extremum: GLib und GTK+. Dort benutzt man C (struktural, 
sprachlich NICHT objektorientiert i.S.v. 'Klassen'). Dadurch muss man 
zwar nicht alles in Objekte verpacken, aber dafür gibts dann so Dinger 
wie:
* g_bookmark_file_load_from_data_dirs und
* g_main_context_find_source_by_funcs_user_data und
* g_win32_get_package_installation_directory_of_module und
* gtk_color_selection_set_change_palette_with_screen_hook
* GtkColorSelectionChangePaletteWithScreenFunc

Will sagen: Es gibt keine goldenen Regeln dafür. Bestenfalls solche wie 
'Klassenvariablen sind privat und gekapselt'. Was du wie und warum 
aufteilst, hängt in jedem Fall von deiner Anwendung ab!
Das meinte ich ja weiter oben: Es kommt durchaus vor, dass du von Zeit 
zu Zeit mal ne ganze Reihe deiner Konzepte/Klassen/... über den Haufen 
wirfst und neu anfängst.