Informatiklehrer
-
volkard schrieb:
kann es sein, daß ich den befähigten coder unterstelle und du davon ausgehst, mit luschen zu arbeiten?
Ich unterstelle den real verfügbaren Entwickler.
Mein Problem ist: die Leute hören die Problemstellung, schalten den PC an, starten die IDE, und beginnen zu tippen. Wenn's gut läuft, gleich mit der GUI anfangen. "Gerechnet wird noch nix, aber die Dialoge habe ich schon fertig"
Ich versuche hier irgendwie den Zwischenschritt "Nachdenken" einzubauen. Bisher gelang das nur, wenn man die Leute zwingt den PC mal 4 Stunden aus zu lassen und auf Papier ihre Idee zu skizzieren. Sobald der PC an ist, entwickeln sich die meisten Leute zu brachialen Trial&Error-Codern, die bereits eine Schleife auf Assemblerebene optimieren, aber noch keine Bereichsprüfung im Algorithmus drin haben.
Nur wenige sind in der Lage, aus dem Problem ein Gebilde zu entwerfen und das im Kopf zu haben, und dieses in Code umzusetzen. Also erzwinge ich die Visualisierung des Gebildes.
Den Unterschied Struktogramm - UML sehe ich darin, daß man Struktogramme auf einer Ebene einsetzt, die sich auch schwache Entwickler noch vorstellen können, daher redundant sind. Aber nur wenige können sich auch noch die gesamte Applikation im Zusammenspiel vorstellen.
-
Marc++us schrieb:
Mein Problem ist: die Leute hören die Problemstellung, schalten den PC an, starten die IDE, und beginnen zu tippen.
das ist gut.
Wenn's gut läuft, gleich mit der GUI anfangen. "Gerechnet wird noch nix, aber die Dialoge habe ich schon fertig"
das ist schlecht.
Ich versuche hier irgendwie den Zwischenschritt "Nachdenken" einzubauen.
das ist schlecht.
nachdenken muß nicht *ein* zwischenschritt mal sein, sondern immer dabei sein. sofort nach dem starten der ide bis ans späte ende, wenn die gui gestrickt wird.Bisher gelang das nur, wenn man die Leute zwingt den PC mal 4 Stunden aus zu lassen und auf Papier ihre Idee zu skizzieren.
und danach plattes einhacken.
Sobald der PC an ist, entwickeln sich die meisten Leute zu brachialen Trial&Error-Codern, die bereits eine Schleife auf Assemblerebene optimieren, aber noch keine Bereichsprüfung im Algorithmus drin haben.
evtl solltest du den leuten beibringen, daß jede funktion und jede klasse in der ersten version schrott ist und eh reimlementiert weden soll? daß es ausnahmen gibt, und manch eine funktion auch mal auf anhieb kein designfehler ist, werden sie selber bemerken.
Nur wenige sind in der Lage, aus dem Problem ein Gebilde zu entwerfen und das im Kopf zu haben, und dieses in Code umzusetzen. Also erzwinge ich die Visualisierung des Gebildes.
ich habe eigentlch immer sehr früh das gebilde im kopf. so nen roten faden, an dem sich entlangzuhangeln lohnt. aber nie so, daß man es bereits verwerten könnte. und ich mische stats top-down mit bottom-up. vorher malen wäre echte zeitverschwendung. aber ich würde eh kündigen, wenn mein chef solchen blödsinn von mir verlangte.
Aber nur wenige können sich auch noch die gesamte Applikation im Zusammenspiel vorstellen.
die klasse lebt aus sich heraus, nicht aus dem kontext. wie drüben der FileExplorer http://forum.c-plusplus.net/viewtopic.php?t=73335&highlight= , der lebt einfach so, es ist brauchbar. egal, wer ihn warum benutzt.
es ist unfug, sich die ganze applikation im zusammenspiel vorzustellen. es war in der rein prozeduralen zeit auch schon unfug, diese aufruf-diagramme zu malen, wo man entnehmen kann, welche funktionen welche funktionen aufrufen. hat die funktion *einen* zweck und einen guten namen, lebt sie allein gut.
-
Ich pers. hasse Struktogramme wir müssen sie immer in der Schule machen, die Aufgaben
dort sind leider nur so billig, dass es in meinen Augen Zeitverschwendung ist,
denn in Java prozedural zu coden, ist ja jetzt nicht _so_ schwer, dass ich mir
über das Design Sorgen machen muss.
Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer,
als direkt das ganze einzutippen, unser Lehrer meint zwar, dass man sich nen
Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht, aber hier
ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso
hilfreich.Edit:
Volkard, wie machst du das bei komplexeren Vererbungsbeziehungen, hast du das dann
irgendwie im Kopf, oder machst du dir vorher auf nem Blatt ne grobe Skizze, bzw.
schreibst auf wie die zusammenhängen? Denn immerhin sind die Kinder, ja abhängig
von den Parents und die Basisklasse, muss ja so designed werden, dass die Kinder
sie optimal einsetzen können.
-
SirLant schrieb:
Ich pers. hasse Struktogramme wir müssen sie immer in der Schule machen, die Aufgaben
dort sind leider nur so billig, dass es in meinen Augen Zeitverschwendung ist,
denn in Java prozedural zu coden, ist ja jetzt nicht _so_ schwer, dass ich mir
über das Design Sorgen machen muss.Struktogramme sind überflüssig. Ganz einfach, weil man die meisten Fehler eh erst beim Ausführen des Programmes (im Einzelschritt-Modus eines Debuggers) erkennt und nicht beim Aufhängen des Struktogramms an der Wand. Und lesbarer als ein gut formatierter (!) und kommentierter (!) Java-Quelltext sind sie sicher auch nicht. Struktogramme stellen ja gegenüber Hochsprachen keine Vereinfachung dar, da die Hochsprachen im Prinzip die gleichen Kontrollstrukturen haben wie Struktogramme, mit dem Vorteil, gleich richtigen Code zu haben.
SirLant schrieb:
Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer,
als direkt das ganze einzutippen, unser Lehrer meint zwar, dass man sich nen
Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht, aber hier
ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso
hilfreich.Klar, man kann so etwas tun, was für das Problem angemessen erscheint. Baumstrukturen entwirft man z.B. besser, wenn man den Baum kurz skizziert und nicht, wenn man gleich versucht, den Algorithmus als Struktogramm zu malen. In dem Moment, wo man ein Struktogramm malen kann, kann man doch gleich den Code in den Rechner eintippen.
-
SirLant schrieb:
Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer, als direkt das ganze einzutippen,
und man fragt sich, warum sie nicht dürfen.
unser Lehrer meint zwar, dass man sich nen Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht,
wenn man zu ahnunslos ist, muß man es ausprobieren. und das geht nirgends so gut, wie am rechner.
wenn man in sachen klassendesign zu ahnungslos ist, muß man auch erstmal ein gefühl für das genre kriegen. durch ausprobieren am rechner.aber hier ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso hilfreich.
auch du bist schon verloren. es ist eben schlecht, vorher "DEN PLAN" hinzuschreiben und dann den zu coden. "DER PLAN" muss beim coden entstehen.
Volkard, wie machst du das bei komplexeren Vererbungsbeziehungen,
es gibt keine komplexen vererbungsbeziehungen. klar muß man dazu private erblichkeit meiden und noch zwei oder drei regeln einhalten, die aber klar in "effektiv c++ programmieren" stehen.
hast du das dann irgendwie im Kopf, oder machst du dir vorher auf nem Blatt ne grobe Skizze, bzw. schreibst auf wie die zusammenhängen?
normalerweise keine skizze. manchmal ein baum, in dem aber nur klassennamen vorkommen und sonst nix. und nicht als planung, sondern als test, ob sich ne idee gut anfühlt. nach angucken des baumes kann das blatt verbrannt werden.
Denn immerhin sind die Kinder, ja abhängig von den Parents und die Basisklasse, muss ja so designed werden, dass die Kinder sie optimal einsetzen können.
NEIN! die Basisklasse muss nicht und darf nicht so designed werden, daß die kinder sie optimal einsetzen können. der mensch denkt in begriffen. deswegen soll er auch in begriffen programmieren. das ist ne frage der wartungsfreundlichkeit. die basisklasse muss ein kapierbarer begriff sein. sie muss *einen* zweck erfüllen und einen sie exakt beschreibenden namen haben. außerdem soll sie performant sein. wen sie einen zweck hat und einen guten namen, lebt sie eigenständig und es ist irrelevant, wer sie verwendet.
trotzdem passieren regelmäßig sachen, wie daß man gleichbedeutende members in childs findet. schwups, hoch damit in die basisklasse. uml-heinis würden sagen, das sei auf den bildern frher zu sehen gewesen. aber nein, noch häufiger als das, passiert es ja, daß man nachträglich members einfügt.
ich lasse sogar attribute (manchmal) und methoden (immer) weg, solange keine andere klasse sie braucht und baue erst bei bedarf nach.
es ist meinen klassen aber fast immer egal, wer von ihnen mal erben möchte, und was der tun will. außer mal, sie heißt "...Base", veröffentlich eine pur virtuelle methode und hat ein attribut.also nix plan vorher. es wächst schon in die richtige richtung. normalerweise ist der plan im kopf gleich da und ich könnte alle klassen und attribute und vererbungsbeziehunen sofort hinschreiben. öffentliche methoden dauern etwas länger. und wenn nicht, dann hilft auch kein überlegen. dann hilft nur ausprobieren, welche der alternativen sich "hübscher" anfühlt. dabei denkt man aber über fallen nach, die sich erst in 6 monaten auftun würden. sehr spekulatives eschäft. gegebenenfalls muss ich mehrere entwürfe ein paar tage lang vorantreiben und dann den enstandenen code bewerten.
es bleibt mir gar keine andere wahl, wenn ich nur den besten code haben mag. manches läßt sich trocken einfach nicht abschätzen.edit: schaut mal, welch schweren stand ich habe, wenn ich euch hier erzählen will, daß der explorative programmierstil wirklich wirkungsvoll ist, aber auf der anderen seite das böse solches "c++" lehrt: http://forum.c-plusplus.net/viewtopic.php?t=73371&highlight=
-
volkard schrieb:
aber hier ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso hilfreich.
auch du bist schon verloren. es ist eben schlecht, vorher "DEN PLAN" hinzuschreiben und dann den zu coden. "DER PLAN" muss beim coden entstehen.
Hm, d.h. du machst dir nie Notizen um deine Gedanken zu ordnen? Finde sowas, manche
machen sowas auch als Mindmap, ziemlich effektiv, da man sich sonst zu leicht in
den Gedanken verstrickt, geht mir jedenfalls so.
-
Hallo,
bei dem Gedanken daran einen komplizierten Automaten zu implementieren ohne mir vorher ein Zustandsübergangsdiagramm zu skizzieren wird mir schwindelig. Ich versuche das zwar immer wieder, jedesmal kommt aber totaler Müll dabei raus. Tausche ich hingegen einfach mal Tastatur gegen Stift und Papier und mal ein zwei Stunden vor mich hin, dann kommt in der Regel ein brauchbarer Grobentwurf bei raus. Während des Programmierens stolpere ich dann über bis dato nicht berücksichtigte Spezialfälle, die sich dann aber einfacher integrieren lassen, da der Grobentwurf steht.
Ähnliche Erfahrungen habe ich auch mit Klassen, deren Aufgaben und Schnittstellen gemacht. Ohne Grobentwurf wird es ein großer Haufen ohne Struktur. Aber egal wie lange man vorher plant und malt und denkt, sobald man programmiert stolpert man über Probleme, die man vorher nicht gesehen hat.Wie machst du das?
Und zum Thema Klassen:
Du benutzt nicht mal sowas wie CRCs? Nichts? Natürlich sollen Klassen genau eine wohldefinierte Aufgabe erfüllen, aber mir kommt es so vor, als würdest du sagen, dass Klassen immer im Vakuum existieren können müssen (sprich: Jede Klasse macht sinn auch wenn sie in Isolation betrachtet wird).
Das scheint mir aber nur in absoluten Ausnahmefällen der Fall zu sein (für so Dinge wie Containerklassen). Ansonsten hat man imo viel häufiger Verbände von Klassen, deren Objekte irgendwie kollaborieren um gemeinsam eine Aufgabe zu erfüllen (nicht umsonst hat besteht jedes DP aus mehr als einer Klasse).
Hier helfen mir CRCs oder auch Diagramme die die Kommunikation zwischen Objekten verdeutlichen ungemein. Code ist dazu imo viel zu Detailbeladen. Da mache ich lieber einen Schritt zurück und schaue mir das ganze im Überblick an.Ich gehöre zwar keinesfalls zu den UML-Fans und ich bin auch keinesfalls der Meinung, dass der Richtige Weg(tm) über Use-Case, Use-Case-Digramm, Aktivitätsdiagramm, Aspekt-Modelle und zugehörige Integrations-Modelle usw. geht (so wie man es mir in Softwarekonstruktion beigebracht hat), aber so ein bischen Planen (ohne Code und Computer) scheint mir nicht verkehrt.
Am Besten hat bei mir bisher eine Kombination aus Use-Cases bzw. Szenarios (damit ich weiß *was* ich überhaupt für ein Problem lösen will), CRCs (Grobentwurf der Klassen) und Test-Driven-Development (Schnittstellen, Kommunikation, erkennen von widerlichen Abhängigkeiten) funktioniert. Wobei ich letzteres noch nicht so perfekt hinbekomme (insbesondere nicht, wenn ich mir vorher nicht wenigstens ein paar Gedanken über die Grundstruktur mache).
Und wenn ich für mich komplizierte Algorithmen (also komplizierter als eine Zählschleife von 1 bis 10) implementieren muss, dann brauche ich immer eine Menge Papier und einen Stift. Ohne Kreise, Kugeln, Pfeile, Wertelisten, kritzelige Berechnungen über Randfälle usw. wird das bei mir sonst nichts
-
der algo für wpc112 http://www.geocities.com/acmesofties/wpcq.htm ist sicherlich als kompliziert anzusehen. und mit genuss warf ich die ide an und tippte drauf los. erstmal den funktionsrumpf und dann
while(dort am ende der zeile darf der cursor dann ein paar phasen lang blinken und ich überlege mir, wie es weiter geht.
wenn ich fertig bin, werden zwei a5-zettel mit test-daten draufgegangen sein.klassen sind aber ganz anders kompliziert. da muß man nicht sowas verknotetes wie komplizierte schleifen machen, sondern arbeitet mit inhalten und bedeutungen. und gemeinerweise erschließt sich die genaue bedeutung manchmal erst genau, wenn die klasse schon seit drei wochen lebt. zum glück hat diese eigenschaft mir noch kein projekt gekippt. nee, kann ja nicht. ich sehe ja gleich, welche klassen projektentscheidend sind und die treibe ich voran. ok, ich würde niemals sachen machen, wie private zu erben, um ne konstruktorreihenfolge zu erzwingen. mag sein, daß ich deswegen normalerweise keine klassen malen muß.
daß du sagst, du machst klassen, die nur im zusammenspiel mit anderen sinn ergeben (mal von iteratoren und zum model passenden views abgesehen), erstaunt mich. ich hab den eindruck, das kommt nicht vor. muss mal dahingehend die augen offen halten.
-
Sehr schön volkard. Bei der Seite springt mein Virenscanner an, dass in das temporär Verzeichnis des IE ein Virus runtergelanden wurde beim Aufruf der Seite.
-
Luckie schrieb:
Sehr schön volkard. Bei der Seite springt mein Virenscanner an, dass in das temporär Verzeichnis des IE ein Virus runtergelanden wurde beim Aufruf der Seite.
omisch. bei mir wird da nix gemeldet. ob das daran liegt, daß ich keinen virenscanner mitlaufen lasse?
welcher virus isses denn? würde den gerne auf meiner platte sehen und gegebenenfall sogar entfernen.
-
omisch. bei mir wird da nix gemeldet. ob das daran liegt, daß ich keinen virenscanner mitlaufen lasse?
Was soll dir denn in diesem Fall bitte den Virus melden?
VBS-Scriptvirus VBS/Redlof.A.
-
SirLant schrieb:
Hm, d.h. du machst dir nie Notizen um deine Gedanken zu ordnen? Finde sowas, manche
machen sowas auch als Mindmap, ziemlich effektiv, da man sich sonst zu leicht in
den Gedanken verstrickt, geht mir jedenfalls so.Ist wohl gewöhnungssache. Hab sowas auch nie gemacht und gehe stattdessen immer über die Prozedur:
a) Zigarette rauchen und das Problem analysieren
b) drauflos-hacken ohne Gnade
c) Zigarette rauchen und den Code analysieren
Ich glaube die wenigsten (vor allem professionelle Programmierer mit dem Release-Plan im Nacken) haben die Zeit, sich vorher alles in PAP's, Struktogrammen oder Mindmaps auszudenken.
-
Cpp_Junky schrieb:
Ich glaube die wenigsten (vor allem professionelle Programmierer mit dem Release-Plan im Nacken) haben die Zeit, sich vorher alles in PAP's, Struktogrammen oder Mindmaps auszudenken.
Dazu fällt mir ein, daß 98% aller Softwareprojekte unpünktlich sind. Ob da ein Zusammenhang besteht?
Eine Person mag noch im Loshacken ein Projekt beginnen können, mir ist aber schleierhaft wie man mit 3 oder 4 Personen ein Softwareprojekt beginnen kann, ohne vorher mal über Entwürfe, Ideen und Zerlegungen diskutiert zu haben. Und diese auch festzuhalten. Nicht als Wegplanung zur konkreten Ausprogrammierung, aber einfach als ungefähre Richtlinie, als roter Faden. Es verlangt doch keiner eine 1:1 Umsetzung, natürlich wird's Abweichungen geben im Verlauf der Programmierung. Aber wer wo startet, das muß man doch festlegen.
Ich weiß, daß viele Firmen das nicht tun, selbst bei Projekten mit 6-7 Personen gibt's keinerlei Grobpläne für die Software. Hinterher werden dann noch Schnittstellen in "fertige" Teile reingehackt, damit alles überhaupt miteinander kommunizieren kann.
-
Ja is schon klar, das man irgendwo festhält wie in etwa man die Sache angeht. Vor allem bei grossen Projekten mit mehreren Programmierern. Aber glaubst du im Ernst die pinseln sich ihre Ideen erst mit PAP's o.ä. zusammen ? Kann ich mir beim besten Willen nicht vorstellen.
-
Ich weiß nicht, warum Ihr Euch an den PAPs aufhängt - diese Analogie PAPs/Struktogramm vs. UML hinkt gewaltig. PAPs sind was im Kleinklein, aber davon sprechen wir hier nicht. UML umfasst auch PAPs und Struktogramme, wenn man will - aber eigentlich geht's hier mehr um Use-Cases oder Klassendiagramme.
Dieser Analogieschluß will mir nicht in den Kopf - weil ein Mittel für das Kleinklein veraltet ist und wenig bringt, ist auch ein Mittel für das Großgroß wenig sinnvoll? Das ist doch nicht linear extrapolierbar.
Ich habe noch nie jemanden in der Praxis gesehen, der PAPs verwendet.
Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
Und dafür ist UML als einheitliche Sprache doch ganz nett - solange man nicht in die Tiefen von UML 2.0 absteigt UND die Freiheit lässt, diese ersten Ideen im Laufe der Entwicklung auch zu variieren.
-
Marc++us schrieb:
Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
Und dafür ist UML als einheitliche Sprache doch ganz nettwarum nicht c++?
-
Marc++us schrieb:
Dieser Analogieschluß will mir nicht in den Kopf - weil ein Mittel für das Kleinklein veraltet ist und wenig bringt, ist auch ein Mittel für das Großgroß wenig sinnvoll? Das ist doch nicht linear extrapolierbar.
vorhin haste noch gesagt: ich zwinge meine leute mit uml, sich VORHER nen plan zu machen, damit sie nicht so unüberlegt rangehen. das ist genau der struktogramme-fehler!
und von anderen höre ich, daß sie auch algos vorher planen. die wissen evtl nicht, was sie sich damit antun. ich hab bei wpc112 mal mitgeschrieben, wie es gelaufen ist und man sieht krass, daß vorherige planung unfug gewesen wäre. (kann es leider schlecht hier posten vor dem einsendeschluss.)
und genauso ist es bei klassen auch. an der herangeensweise ist zwischen dem entwerfen von algos und dem von klassenverbänden kein riesiger unterschied. der unterschied ist nur, daß man bei algos von der test-suite bei fehlern sofort abgestraft wird, bei klassen erst nach monaten vom terminplan und den magengeschwüren.
Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
das ist ne andere schiene. dafür ist c++ mit auslassungen ganz nebenbei ne hochgeeignete sprache. hab da aber auch gute erfahrungen damit, daß man einfach inhaltlich trennt und mindestnes die erste woche im selben büro arbeitet. schnittstellenverhandlungen geschehen unter profis so:
"ich muss bei dir gucken können, welche dateien du verändert hast"
"magste nen vector?"
"jo"
"kriegste"
und sofort ne mail dahinter (ja, per mail über die usa kommuniziert man mit seinbem tischnachbarn . mit der neuen header-datei.)
nervig wirds nur, wenn sender oder empfänger nix können, und das hab ich auch erlebt. da musste die dame bildunterschriften kriegen und man sagt ihr: such dir irgendein format aus, kriegst. sie konnte sich nix aussuchen. man sagt "kannste vector<pair<int,string> > (x-kordinate der textmitte, text) gebrauchen?". sie sagte, das könne sie nicht verarbeiten, aber machte keinen besseren vorschlag. die software hing und sate, der sender sei nicht kooperativ.
-
Ich bin ja auch nicht gerade ein Fan von UML, PAPs, Struktogrammen, Netzplänen usw. und trotzdem finde ich es wichtig, dass man zumindest eine Grobplanung auf Papier in einem größeren Projekt hat. Es geht da einfach nicht ohne, ansonsten endet alles in einem großen Chaos. Schließlich ist dieses vorherige Skizzieren eine Art Dokumentation.
@volkard
Ich hoffe du wirst niemals ein Haus bauen.@thema lehrer
Warum hackt ihr eigentlich immer auf diese Informatiklehrer rum? Seid ihr vielleicht schon mal auf die Idee gekommen, dass die das vielleicht gar nicht studiert haben?So in etwa läuft es nämlich tatsächlich ab:
Herr Müller ist ca. 40 Jahre alt und Lehrer an einer Schule. Sein Hauptfach ist Mathematik. Eines Morgens zitiert ihn sein Direktor in dessen Büro.
Direktor: "Hallo Herr Müller. Sie sind ja unser Spezialist in mathematischen Angelegenheiten."
Müller: "Naja ich habe hald Mathematik als Lehrfach studiert."
Direktor: "Ich habe in Ihrer Akte gelesen, dass Sie als Wahlfach auch etwas Informatik hatten."
Müller: "Ja, das war ein Semester lang."
Direkter: "Sie kennen sich doch auch mit Computern aus."
Müller: "Naja, ich mache privat ein wenig was mit dem Computer."
Direkter: "Gut, dann sind Sie ja genau der richtige Mann für unser neues Fach Informatik. Sie haben jetzt eh die ganzen Sommerferien Zeit sich etwas einzuarbeiten. Im neuen Schuljahr haben Sie dann auch das Fach Informatik."
...Schimpft also nicht so einfach drauf rum, denn die können meistens selber nichts dafür, dass sie den Posten draufgedrückt bekommen haben.
-
AJ schrieb:
Ich bin ja auch nicht gerade ein Fan von UML, PAPs, Struktogrammen, Netzplänen usw. und trotzdem finde ich es wichtig, dass man zumindest eine Grobplanung auf Papier in einem größeren Projekt hat. Es geht da einfach nicht ohne, ansonsten endet alles in einem großen Chaos. Schließlich ist dieses vorherige Skizzieren eine Art Dokumentation.
und was bringt es, was vorher zu dokumentieren, was man nachher nicht haben will?
je früher und je exakter festlegungen sind, desto schlechter wird das ergebnis.
je bereiter man ist, festlegungen und code (auch mal dutzende von seiten) wegzuschmeißen, desto besser wird das ergebis.
dem gegenüber steht, daß es im team auch nachteilhaft sein kann, wenn die linke hand nicht weiß, was die rechte tut.
dem versucht man durch frühe festlegunen entgegenzuwirken.
aber es bleibt ein zielkonflikt. man muss kompromisse eingehen und leider teilweise früh festlegen und dabei auf die top-code-quali zum teil kacken.ihr mußt das so sehen: jede frühe festlegung schadet. man darf sie nur in kauf nehmen, um schlimmere gefahren abzuwenden. man darf auf keinen fall einfach so aus lust und laune alles mal festlegen, wie AJ es zu mögen scheint.
@volkard
Ich hoffe du wirst niemals ein Haus bauen.Ich hoffe, du wirst niemals Software bauen.
-
Heute hatten wir wieder IT und wie haben heute mit OOP angefangen und natürlich auch UML
bin mal gespannt was mich in Zukunft erwartet
Volkard ich kann mir echt nicht vorstellen, wie du in nem 20 Mann Team (oder auch weniger)
zusammen ne Software entwickelst, ohne jegliche Absprache, ihr müsst doch schon
nen Konzept haben bevor ihr anfangt, woher weiß sonst jeder was er machen soll?