Laden...

Wie designed ihr?

Erstellt von dr4g0n76 vor 18 Jahren Letzter Beitrag vor 18 Jahren 6.315 Views
dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren
Wie designed ihr?

Ich möchte mal hier eine kleine Umfrage starten.

Wie designed ihr?

Seid ihr eher die klassischen Code-Hacker (Idee im Kopf und los, auch bei größeren Sachen) oder nehmt ihr immer erst Papier und Stift zur Hand, bevor etwas passiert?

Was für Regeln beachtet ihr dabei? Sagt ihr grundsätzlich NEIN zu GOTO oder wenn's passt, warum nicht?

Versucht ihr immer alles in Design-Patterns zu packen, oder wägt ihr ab (z.B. design-kritisches Verhalten)

Ich finde der richtige Mix macht es, je nach Anwendung kommen ja sowieso ganz unterschiedliche Design-Strategien zum Einsatz.

Nach der Lektüre von Head First (Java) und Dissecting a c# application, bin ich aber der Meinung, es ist immer richtig zu versuchen sein Programm, soweit wie benötigt, so flexibel zu machen, das es zur Laufzeit geändert werden könnte. Das habe ich versucht bei meiner Skin-Componente einzuhalten und ist mir eigentlich auch überall wo ich es wollte gelungen. Neue Properties und Eigenschaften, müssen eigentlich "nur" noch aufgelistet und nicht neu programmiert werden.

Gilt für mich inzwischen auf jeden Fall bei größéren Anwendungen zu einem gewissen Grad.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

4.506 Beiträge seit 2004
vor 18 Jahren

Hallo dr4g0n76!

Dann kommt noch ein wichtiger Aspekt dazu:

Gibt es bei der Terminplanung Vorgaben? Wenn schnell ein Produkt entwickelt werden soll, weil praktisch schon verkauft, dann kann man es sich nicht mehr erlauben großartig zu designen.

Ich bin jemand der wohl zu viel Design-Gedanken in die Arbeit packt, komm daher nur schwer zu Potte, und bin dadurch nicht mehr so produktiv.

ABER: Bei großen Projekten, bei denen auch schon mehr als 2 Mann dran sitzen, da geht es gar nicht mehr ohne, denn sonst ziehen nicht alle an demselben Strang.

Daher versuche ich mich an folgende "Regel" zu halten:

So viel Design wie Möglich, aber so schnell anfangen zu programmieren wie möglich 😉

Zum Thema Goto kann ich nur sagen, ich hab mit C64-Basic angefangen, da kann man nur mit goto arbeiten, aber dann irgendwann Pascal weitergemacht, und gesehen, man kann auch andere Wege gehen, muss aber nicht, und bin über C,C++ jetzt bei C# angelangt, und möchte es nie wieder sehen 😉

Gab nur letztens einen Fall, dass ich innerhalb einer Switch Anweisung ein anderes case-segment mit ausführen wollte, da hab ichs der Bequemlichkeit halber gemacht, aber ich schämemich dafür 😉)

Ciao
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

_
416 Beiträge seit 2005
vor 18 Jahren

Hallo,

Original von norman_timo
Gibt es bei der Terminplanung Vorgaben? Wenn schnell ein Produkt entwickelt werden soll, weil praktisch schon verkauft, dann kann man es sich nicht mehr erlauben großartig zu designen.

Ich bin jemand der wohl zu viel Design-Gedanken in die Arbeit packt, komm daher nur schwer zu Potte, und bin dadurch nicht mehr so produktiv.

Dem muss ich teilweise zustimmen und gleichzeitig wiedersprechen. Leider ist es ja wirklich meistens so, das ein 6Monate Projekt am besten in 2 Monaten fertig sein soll. Und wer hat den Zeitplan auf dem Gewissen? Ein Nicht-Entwickler der sich denkt: "Ach so ein paar Knöpfchen da und dort, was soll daran schon lange dauern?" Natürlich will dieser dann auch schnell erste Ergebnisse sehen und nicht nach 14 Tagen hören: "Wir haben unsre Designphase schon fast abgeschlossen. Programmiert? Nee, da haben wir noch nix."
Nur was ist dann das Fazit? Man setzt sich ran an das Problem, meistens hat man den ersten Entwurf ja schnell im Kopf gebildet. Und man programmiert los. Nach einem Monat bemerkt man dann: nee, so geht das doch nicht, mal hier und da noch ein paar Änderungen machen. Am Ende ist das Design total komplex und die Applikation wenns geht noch buggy, weil man halt beim umschreiben noch irgendwo ne Stelle vergessen hat. Außerdem fällt dem Manager so 3 Tage vor Schluss noch eine Funktion ein die er noch unbedingt braucht. Tja, nur leider lässt das Design keine großen Erweiterungen zu, denn daran zu denken hatte man ja nicht auch noch Zeit ...
Im Endeffekt dauert das Projekt dann doppelt so lang als ursprünglich geplant und alle sind unglücklich. Meine Meinung: eine ordentliche Designphase macht die Implementierung letztendlich flexibler und fehlerresistenter.
Außerdem ist meine (bescheidene) Erfahrung, dass wenn ich mich mal gründlich hinsetze und ein Problem von vorn bis hinten durchdenke, am Ende das PRoblem nur noch halb so schwierig erscheint und außerdem ein wohldefinierter Realisierungsplan steht, durch den man hintereinanderweg implementieren kann und damit auch noch einige Zeit spart.

Zum Thema Design-Patterns. Da scheiden sich wahrscheinlich die Geister. Ich finde man sollte alle wesentlichen Kennen. Ihre Vorzüge, aber auch Nachteile. Und dann ist es so wie beim Kochen. Man hält sich nicht streng ans Rezept, sondern man ändert es so ab wie es einem am besten passt. Patterns sind also eher als Richtlinie zu verstehen, nicht als festes Regelwerk. Ich schreib mir auch nicht auf welche Patterns ich wo verwendet habe, wie es einige für sinnvoll halten.

Thema GOTO: In VB ist es manchmal schwer zu vermeiden. In SQL gar nicht. Ansonsten verwende ich es nie, und bin auch froh darüber. Es gibt immer (oder zumindest meist) bessere und klarere Wege.

cu, tb

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

Auf jeden Fall scheint es wirklich so zu sein, vor allem bei großen Projekten, dass eine lange Design-Phase auf Papier insgesamt viel Arbeit spart. Nur meist traut man sich das entweder nicht, oder wie ihr beide schon sagt, hat man einfach nicht genug Zeit dafür.

Momentan arbeite ich in einem Job, indem ich mir sogar erlauben kann, solange zu brauchen, bis ich meine dass es gut ist. Aber ohne mir eigene Vorgaben zu machen, würde ich manchmal wohl nie fertig werden.

Ich designe ungern auf Papier, obwohl es wichtig ist. Deswegen zwinge ich mich dazu...

Habt ihr "Der pragmatische Programmierer", "Dissecting a c# application", "O'Reilly design patterns" oder "Head First - Java" schon einmal gelesen?

Wie testet ihr? Benutzt ihr Unit-Tests? NUnit? oder habt ihr Berufs-Tester?
Oder testet bei euch hauptsächlich der Kunde?

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

S
709 Beiträge seit 2005
vor 18 Jahren

Ich hab so meine Probleme mit Designen. Gibts irgendwo Tipps/Tutorials wie man Anwendungen richtig designt? Ich hab z.B. Momentan z.b. ein Problem, dass ein UserControl ein event hat, eine Form dieses Usercontrol eingebaut hat und ich dann von außerhalb auf das event zugreifen möchte, wie löse ich das?
(Ich hoffe, die Frage ist jetzt nicht zu off-topic, ansonsten schreib ich sie in einen extra thread)

Gruß,
SimonKnight6600

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo SimonKnight6600,

ist schon ziemlich offtopic, deshalb in alle Kürze:

Ich würde in dem Form (Form1), dass das UserControl enhält, ein eigenes Event definieren. Form1 registriert sich auf das Event des UserControls und feuert sein eigenes Event, wenn das UserControl feuert. Form2 kann dann das Event von Form1 registrieren. Ein direkter Zugriff auf das UserControl oder auf das Event des UserControls wäre schlechtes Design.

Bei Nachfragen => neuer Thread.

herbivore

-
885 Beiträge seit 2004
vor 18 Jahren

Sehr interessantes Thema. Kurze Frage: Was sind "Design-Patterns"? Vorgaben? Vorgehensweisen?... 🤔

N
4.644 Beiträge seit 2004
vor 18 Jahren
3.728 Beiträge seit 2005
vor 18 Jahren
Design

Bevor man mit dem schreiben von Code beginnt, sollte man aufzeichnen, wie man was lösen will. Das mache ich z.B. Teils mit UML teils mit einfachen Blockdigrammen (UML ist nur dann vorteilhaft, wenn es allen Mitglieder des Teams kein Fremdwort ist). Ich fange an, Code zu schreiben, wenn ich mir Antworten auf folgende Fragen geben kann:
*Welche Datenspeicher werden benötigt? *Wie sehen die Tabellen, Schemas etc. des Datenspeichers aus? *Wie veile Komponenten werden benötigt und was machen die? *Wie sehen die Schnittstellen zwischen diesen Komponenten aus? *Wie sehen IM GROBEN die Klassen aus? *Welche Komponente läuft in welchem Prozess? *Welche Komponenten kommunizieren über das LAN? *Welche Komponenten kommunizieren über das Internet (also durch die Firewall)? *Wie kommunizieren die Komponenten miteinander (SOAP, DCOM, MSMQ)? *Wird ein Rechtesystem benötigt? *Wie sieht die Benutzeroberfläche der Anwendung aus (Skizze)?

Am Ende dieser Überlegungen hat man meistens einige Seiten Handskizzen und Stichwortlisten. Diesen sollten in eine bessere Form (Visio, Word etc.) gebracht und archiviert werden.

195 Beiträge seit 2004
vor 18 Jahren

Habt ihr "Der pragmatische Programmierer", "Dissecting a c# application", "O'Reilly design patterns" oder "Head First - Java" schon einmal gelesen?

Welches davon kannst Du empfehlen? Ist das erste brauchbar? Ich möchte mir dieses Thema lieber auf Deutsch als auf Englisch antun...

Bei mir testen die Kollegen... aber die sind auch gleichzeitig meine Kunden 8)

Umwege erhöhen die Ortskenntnis.

432 Beiträge seit 2005
vor 18 Jahren

hey, bei dem thema muss ich unbedingt mitmischen,

ich bin nämlich auch ein vertreter der "papier und bleistift zuerst!" fraktion. 😁

UML kann ich jedem empfehlen, zumindest aber mal so ne art mindmapping, wenn mehrere klassen ins spiel kommen und miteinander kooperieren sollen. schließlich sagt ein bild noch immer mehr als tausend worte und wenn dieses bild dann auch noch an einem internationalen standard orientiert und von jedem verstanden werden kann umso besser!

eine datenbank wird ohne E/R-modell gar nicht erst angefasst!

die checkliste von rainbird finde ich persönlich ganz gut.

ich persönlich komme ganz gut mit gui prototyping klar und bin relativ schnell im konzept schon dabei, die zu automatisierenden geschäftsprozesse graphisch umzusetzen (oft auch mit bleistift!) und mit den späteren anwendern zu besprechen, ob das so für sie eine angemessene lösung zu sein scheint.
ausgehend von da und vom datenmodell ergibt sich die klassenarchitektur meistens schon von selbst.

als literatur kann ich code complete von steve mcconell (gibt´s inzwischen auf deutsch schon in 2. auflage, isbn 3-86063-593-X, ca. 50 €) jedem nur an´s herz legen: das hat nämlich zu jedem der hier angesprochenen themen etwas sinnvolles zu sagen (wiegt ja auch `n paar kilo).

die größe (also: dauer, finanzvolumen & komplexität) des projektes bestimmt natürlich maßgeblich jede vorgehensweise und rechtefertigt eben gegebenenfalls eine gewisse planungsdauer oder nicht!

1.271 Beiträge seit 2005
vor 18 Jahren

Hallo citizen.ron,

Für mich als Hobbyprogrammierer ist Design noch eine Art Fremdwort. Ich habe aber vor damit anzufangen, weil mir sonst meine Projekte über den Kopf steigen.

Original von citizen.ron
als literatur kann ich code complete von steve mcconell (gibt´s inzwischen auf deutsch schon in 2. auflage, isbn 3-86063-593-X, ca. 50 €) jedem nur an´s herz legen: das hat nämlich zu jedem der hier angesprochenen themen etwas sinnvolles zu sagen (wiegt ja auch `n paar kilo). Welche Vorraussetzungen braucht man, um dieses Buch nicht nur zu lesen, sondern auch zu verstehen? Sowas wäre, glaub ich, eine sehr sinnvolle Investition.

Gruß,
progger

A wise man can learn more from a foolish question than a fool can learn from a wise answer!
Bruce Lee

Populanten von Domizilen mit fragiler, transparenter Außenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.

432 Beiträge seit 2005
vor 18 Jahren

hi progger,

also code complete kann jeder lesen (und verstehen).

die kapitel, die einem anfangs noch zu hoch sind, hebt man sich dann einfach für später auf.

da aber auch so nette dinge wie "code richtig formatieren, damit er für mich (und andere) auch gut lesbar ist" darin enthalten sind, kann ich das auch anfängern oder wie du dich nennst: hobbyprogrammierern nur empfehlen, damit sich die schlechten angewohnheiten gar nicht erst allzu fest etablieren 😉

1.271 Beiträge seit 2005
vor 18 Jahren

Ich werde es mir kaufen 🙂
Und ich habe nicht vor ewig Hobbyprogrammierer zu bleiben. Muss aber erst mit der Schule fertig werden 😉

A wise man can learn more from a foolish question than a fool can learn from a wise answer!
Bruce Lee

Populanten von Domizilen mit fragiler, transparenter Außenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.

3.728 Beiträge seit 2005
vor 18 Jahren

@Bini: Hier einige Buchtipps:

Das ultimative Buch für die alltäglichen Aufgaben. Das Buch ist praktisch eine Sammlung von Codeschznipseln zu verschiedenen Themen.

http://www.amazon.de/gp/reader/3446220224/ref=sib_dp_pt/028-2004737-0425335#reader-link

Das folgende Buch ist ganz interessant, wenn es um Komponenten mit .NET geht.
Es ist zwar für Visual Basic.NET geschrieben, aber das sind ja fast nur Syntax-Unterschiede. Leider geht das Buch nicht auf Enterprise Services ein.

http://www.amazon.de/gp/reader/386063643X/ref=sib_dp_pt/028-2004737-0425335#reader-page

Da Enterprise Services das Leben bei großen verteilten Anwendungen sehr erleichtern, solltest Du Dir unbedingt auch das folgende Buch ansehen:

http://www.amazon.de/exec/obidos/ASIN/3446221530/qid=1130359972/sr=1-4/ref=sr_1_11_4/028-2004737-0425335

Noch ein Buch möchte ich Dir empfehlen. Es ist zwar etwas älter, erklärt aber sehr gut die Entwicklung verteilter Business Anwendungen mit dem Windows Application Server (COM+ , Wird in Verbindung mit .NET Enterprise Services genannt).

http://www.amazon.de/exec/obidos/ASIN/3860636251/qid=1130360896/sr=1-1/ref=sr_1_8_1/028-2004737-0425335

Falls Dein Chef ein Geizkragen ist, kannst Du ja mal auf www.terrashop.de schauen. Dort gibt es IT-Bücher die kleine Fehler haben sehr günstig.

1.271 Beiträge seit 2005
vor 18 Jahren

Ich möchte an dieser Stelle edv-buchversand.de loben! Ich habe gestern um 16:15h Code Complete bestellt. Versandkostenfrei. Vor 20min hat der Postbote geklingelt und das Buch ist schon da!!! Meine Lektüre für die nächste Zeit steht also schon fest 😁

A wise man can learn more from a foolish question than a fool can learn from a wise answer!
Bruce Lee

Populanten von Domizilen mit fragiler, transparenter Außenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.

432 Beiträge seit 2005
vor 18 Jahren
code complete

hi progger,

herzlichen glückwunsch und viel spass beim lesen!

kleiner lesetipp:
da das buch für die bettlektüre zeimlich schwer ist (im sinne von kilos!!!) habe ich als erstes das inhaltsverzeichnis herausgerissen und mental implementiert 8o

danach wusste ich dann so ungefähr, welche kapitel mich in welcher reihenfolge interessieren.
ausserdem habe ich meistens mit der zusammenfassung der kapitel angefangen und es dann vertieft, wenn´s gut war.

kannst ja in diesem thread abundzu mal deine meinung zu ein paar kapiteln äußern...

1.271 Beiträge seit 2005
vor 18 Jahren

Ich habe die Angewohnheit, ein Buch, egal wie dick, von vorne bis hinten durchzulesen. Aber mal schaun, vielleicht ziehe ich einige Kapitel vor.
Ich poste gerne was zu den einzelnen Kapiteln und auch zu dem ganzen Buch.

A wise man can learn more from a foolish question than a fool can learn from a wise answer!
Bruce Lee

Populanten von Domizilen mit fragiler, transparenter Außenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.

195 Beiträge seit 2004
vor 18 Jahren

Original von Rainbird
Falls Dein Chef ein Geizkragen ist, kannst Du ja mal auf
>
schauen. Dort gibt es IT-Bücher die kleine Fehler haben sehr günstig.

Danke für den Tipp 😉

Mein Chef hat leider keine Ahnung von der Materie und vor allem von der BREITE der Wissensgebiete, die ich mal eben so abdecken soll X(

Danke auch für die Buchempfehlungen, ich hab jetzt mal zwei bestellt und noch welche auf meine Wunschliste gesetzt...

Umwege erhöhen die Ortskenntnis.