Informatiklehrer
-
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?
-
volkard schrieb:
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++?
Weil die dann sofort ständig anfangen zu compilieren. Bevor man sich umsieht, stehen die ersten Variablen bereits im private-Teil. Damit kann man aber nicht anfangen, wenn man noch Zerlegungen diskutiert.
Das UML dient nur zur Verhinderung dessen, daß mit einem Detail losgehackt wird, weil der Compiler zu früh aktiviert wird.
Weiterhin hatte ich oft die Situation, daß 3 Leute vor einer Tafel stehen und mit einem Edding bewaffnet eine Sache diskutieren. Wenn man nun die Notation "C++" verwendet findet sich immer ein Brettlesbohrer, der plötzlich einwendet "da fehlt noch ein Strichpunkt". S***** doch auf den Strichpunkt zu diesem Zeitpunkt. Trotzdem hängen sich die Leute daran auf. Sobald man eine Sprache als Beispiel verwendet, macht es *klick* und die Masse der Entwickler denkt nur noch in Implementationsdetails. Oder wenn man eine Klasse skizziert und es kommt die Frage "der Copycon wird aber private gemacht, oder?". Ja, brav, hast Du gut Scott Meyers gelesen und auswendig gelernt. Aber das interessiert doch zu dem Zeitpunkt gar nicht.
Daher die Wahl einer Notation, die nicht so leicht in Implementationen abrutschen kann.
Und weiterhin hat's noch einen Effekt - Kostenplanung. Wenn ich ein Diagramm mit 40 Klassen habe und lauter Linien dazwischen, drucke ich das auf A3-Blättern aus und gehe damit zu einem Betriebswirt. Dann sage ich, daß jedes Kästchen auf dem Bild ca. 25 Stunden Arbeit sind und verlange dafür ein Budget. Man stelle sich die gleiche Situation vor, wo ich mit 40 Headern mit C++-Pseudocode zu dem Mann gegangen wäre - niemals wäre das so einfach durchgekommen. [Ich nenne das auch "fuck the fakers"-Methode]
In meinen Augen hilft UML (wobei ich auch was anderes nehmen würde, vor 8 Jahren habe ich Booch genommen) dabei, real auftretende Probleme der Softwarewelt mit real exisitierenden Entwicklern zu lösen. Daher fällt es bei mir in die Schublade "brauchbares Hilfsmittel".
-
volkard schrieb:
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.
Falsch. Ich persönlich mache es privat so wie du. Ich hab ne Idee ein paar Vorstellungen im Kopf und programmier munter drauf los. Später werf ich dann sowieso alles wieder um.
Allerdings kann man sich sowas im Job nicht so einfach leisten, besonders nicht in größeren Projekten. Eine grobe Planung ist ohne Grobkonzept unmöglich (wie Marc++us auch schon angedeutet hat mit seinem Beispiel). Allerdings ist nicht jeder Kunde so naiv, wartet bis das Projekt endlich mal fertig programmiert ist und zahlt dann horense Summen für die Entwicklung.Vielleicht reden wir auch etwas aneinander vorbei. Es ist sicherlich sinnlos die Software vorher komplett (Feinkonzept) auf dem Papier zu entwickeln, aber zumindest die Richtlinien (Grobkonzept) sollten vor der Implementation vorhanden sein.
Schreibst du eigentlich Pflichtenhefte oder Spezifikationen, wenn du einen neuen Auftrag erhältst? (Klingt nämlich bisher nicht so)
@volkard
Ich hoffe du wirst niemals ein Haus bauen.Ich hoffe, du wirst niemals Software bauen.
Zu spät! :p
-
AJ schrieb:
Schreibst du eigentlich Pflichtenhefte oder Spezifikationen, wenn du einen neuen Auftrag erhältst? (Klingt nämlich bisher nicht so)
nö, ich darf machen, was ich will. ich gebe nen auftrag gut ab, um den nächsten auftrag zu kriegen. und der chef zahlt gut, um mich für den nächsten auftrag zu bekommen. manchmal ist vorher nichtmal kalr, um was es überhaupt geht.
-
volkard schrieb:
nö, ich darf machen, was ich will. ich gebe nen auftrag gut ab, um den nächsten auftrag zu kriegen. und der chef zahlt gut, um mich für den nächsten auftrag zu bekommen. manchmal ist vorher nichtmal kalr, um was es überhaupt geht.
Wenn es nur immer so einfach wäre *schwelg*
-
@AJ:
Hm, da hast Du was falsch verstanden - sein Weg ist der schwere Weg.
-
Hallo,
spätestens wenn ich in einem Team arbeite und ich nicht in einer perfekten Welt lebe, in der sich jedes Team rund um die Uhr an einem gemeinsamen Ort befindet, benötige ich imo auf jeden Fall eine gewisse Form der Planung.
Erstmal müssen die Teammitglieder in Sachen Ziel übereinstimmen.
Ansonsten löst jeder lustig ein anderes Problem.
Das heißt natürlich nicht, dass meine Use Cases oder Szenarios in Stein gemeißelt sind. Natürlich können die sich im Laufe der Zeit ändern. Eine Änderung kann man imo aber nur feststellen und diskutieren, wenn man sie gegen etwas anderes vergleichen kann. Allein deshalb brauche ich imo eine Menge von Basis Use-Cases. Das macht sich auch im Zuge eine evolutionären Entwicklung ganz gut. Ich kann mir eine Menge von Use Cases raussuchen, und so Schritt für Schritt von Release zu Release wandern. Ohne Festlegung von Funktionalität habe ich keinen möglichkeit meinen Fortschritt zu messen.Will ich dazu Aufgaben verteilen, dann setzt das voraus, dass ich zuvor eine Zerlegung meines Problems erstelle. Die kann ja von mir aus sehr grob und informell sein, sie muss aber dennoch existieren. Will ich allerdings ein Problem zerlegen, so muss ich vorher zumindest wissen, was mein Problem überhaupt ist.
Und es geht ja auch nicht immer nur um Softwareneuentwicklung. Manchmal muss vorhandene Software ja auch gewartet werden (habe ich mir sagen lassen). Oder neue Teammitglieder müssen integriert werden und müssen sich deshalb in vorhandene Software einarbeiten. Oder man möchte ein neues Framework einsetzen. Oder unterschiedliche Teammitglieder haben ein unterschiedliches Verständnis bzw. einen unterschiedlichen Wissensstand.
Hier hat UML (oder eine alternative Methode) clever eingesetzt imo große Kommunikationsvorteile. Natürlich kommt man nicht drum rum sich zu einem gegebenen Zeitpunkt mit dem Quellcode auseinanderzusetzen, aber wenn man vorher auf einer abstrakteren Ebene schon mal die Grobzusammenhänger verstanden hat, fällt das Codelesen deutlich leichter (guter Code sollte natürlich eigentlich alle notwendigen Informationen enthalten. Allerdings ist Code häufig viel zu genau - er muss ja schließlich auch von so einem Hirni wie dem Compiler verarbeitet werden können). Warum soll ich mich z.B. durch tausende Zeilen Code wühlen um die Verarbeitung eines CORBA-RPCs zu verstehen, wenn ich das mit einem Diagramm und ein paar Worten viel schneller erklären kann?Ich denke also alles in Allem sehe ich das wohl so ähnlich wie Marcus.
-
wir haben an unserer schule ein projekt gestartet, bei dem 3 programmierer mitgearbeitet haben. wir haben uns morgens immer getroffen und haben eine kurze team/tages besprechung abgehalten und dann hat jeder für sich drauf los programmiert. das hat am ende dazu geführt, das jeder für seine schnittstelle eine wrapper klasse schreiben musste, damit alles zusammen gepasst hat. das hat uns nochmal einen halben tag gekostet... wir haben daraus gelernt, dass wir am anfang eine einhaitliche schnittstelle definieren, auf die jeder aufbauen kann. wenn etwas an der schnittstelle geändert werden muss, dann wurde das bei der besprechung besprochen
das hat beim zweiten sehr gut geklappt und unser lehrer hat die schnittstellen deffinition bei anderen klassen benutzt.am wichtigsten ist jedoch der ständige austausch zwischen den programmierern. da an sonsten missverständnisse programmiert werden, die schwer zu beseitigen sind.
-
Marc++us schrieb:
@AJ:
Hm, da hast Du was falsch verstanden - sein Weg ist der schwere Weg.
Nein denke ich nicht (das mit dem falsch verstehen). Im Job möchte ich nicht ohne Grobkonzept auskommen müssen. Dass volkards Weg der schwerere ist, weiß ich. Ich mach es ja daheim privat so wie er und hab schon öffter was umprogrammiert, weil mir mittendrin noch eine Verbesserung eingefallen ist, die mir allerdings sicher auch schon vorher einfallen hätte können, wenn ich genauer darüber nachgedacht hätte und ein Konzept erstellt hätte. Allerdings sehe ich es privat nicht so schlimm, da ich ja trotzdem meine Übung hab. In der Geschäftswelt (wie schon gesagt) kann man sich sowas eigentlich nicht leisten. Da ist es notwendig Konzepte zu erstellen.
-
AJ schrieb:
Ich mach es ja daheim privat so wie er und hab schon öffter was umprogrammiert, weil mir mittendrin noch eine Verbesserung eingefallen ist,
das mache ich immer. der "wirklich gute weg" ist vom start aus nicht sichtbar. aber was soll's? man baut ja die ersteb beiden versionen zum wegschmeißen.
die mir allerdings sicher auch schon vorher einfallen hätte können, wenn ich genauer darüber nachgedacht hätte und ein Konzept erstellt hätte.
und hier zweifle ich, daß das immer geht.
Allerdings sehe ich es privat nicht so schlimm, da ich ja trotzdem meine Übung hab. In der Geschäftswelt (wie schon gesagt) kann man sich sowas eigentlich nicht leisten. Da ist es notwendig Konzepte zu erstellen.
in der geschäftswelt wird viel zu wenig weggeschmissen. es ist doch dauernd so, daß man an nem falschen ansatz hängt und viele mannjahre hereingewurstelt hat. und jedes weitere feature wird teuer erkämpft, weil es sich nur widerwillig in diesen codeverhau reinpuzzlen läßt. und ne reimplementierung würde recht flott gehen und danach würde jedes weitere feature in einem zehntel der zeit reinkommen können.
-
volkard schrieb:
die mir allerdings sicher auch schon vorher einfallen hätte können, wenn ich genauer darüber nachgedacht hätte und ein Konzept erstellt hätte.
und hier zweifle ich, daß das immer geht.
Und da bin ich 100%tig deiner Meinung. Aber nur weil ein Plan nie 100% aufgeht, heißt das imo nicht, dass man gleich ganz ohne Plan loslegen sollte.
in der geschäftswelt wird viel zu wenig weggeschmissen. es ist doch dauernd so, daß man an nem falschen ansatz hängt und viele mannjahre hereingewurstelt hat. und jedes weitere feature wird teuer erkämpft, weil es sich nur widerwillig in diesen codeverhau reinpuzzlen läßt. und ne reimplementierung würde recht flott gehen und danach würde jedes weitere feature in einem zehntel der zeit reinkommen können.
Dazu fällt mir spontan folgender Text ein:
http://www.joelonsoftware.com/articles/fog0000000069.html
-
@HumeSikkins
ACK@volkard
Leider geht das nicht immer, dass man den Code einfach so wieder verwirft. Wenn bestimmte Dinge mal implementiert sind und auch ausgeliefert(!), dann kann man das nicht so ohne weiteres ändern. Auf jeden Fall nicht ohne sich den Zorn von Kunden zuzuziehen und das ist immer schlecht.Ich vermute mal, dass du in Individual-Software-Entwicklung tätig bist. Da mag es ja noch ohne größere Probleme möglich sein, aber in der Standard-Software-Entwicklung hat man mit dem Vorgehen riesige Probleme.
-
AJ schrieb:
Leider geht das nicht immer, dass man den Code einfach so wieder verwirft. Wenn bestimmte Dinge mal implementiert sind und auch ausgeliefert(!), dann kann man das nicht so ohne weiteres ändern. Auf jeden Fall nicht ohne sich den Zorn von Kunden zuzuziehen und das ist immer schlecht.
was kümmern mich die randbedingungen? ich sage, daß durch wegschmeißen der code oft besser wird und die weitere entwicklung stark beschleunigt, wenn nicht gar erst ermöglicht.
daß man sich trotzdem überlegen sollte, was man tut, ist klar.und wenn ich sagte, "wasser ist gesund", kommt ihr mit dem argument, daß schonmal einer im wasser ersoffen ist. viel mehr leute ersaufen im wasser als im bier. na, und?
auf jeden fall hat euer "think once, debug ever"-stil nix in der lehre bei programmieranfängern zu suchen. die kids sollen explorativ proggen. fesseln kriegen sie früh genug.
-
HumeSikkins schrieb:
Dazu fällt mir spontan folgender Text ein:
http://www.joelonsoftware.com/articles/fog0000000069.htmlYes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
und er propagiert solchen code? naja, er verkauft ja auch ein bugfix-verfolgungs-programm.
-
volkard schrieb:
daß man sich trotzdem überlegen sollte, was man tut, ist klar.
Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
-
volkard schrieb:
und wenn ich sagte, "wasser ist gesund", kommt ihr mit dem argument, daß schonmal einer im wasser ersoffen ist. viel mehr leute ersaufen im wasser als im bier. na, und?
auf jeden fall hat euer "think once, debug ever"-stil nix in der lehre bei programmieranfängern zu suchen. die kids sollen explorativ proggen. fesseln kriegen sie früh genug.Findest du nicht, dass du jetzt etwas zu sehr verallgemeinerst? Ich kann mich gar nicht erinnern, dass ich irgendeinen "think once, debug ever"-Stil propagiert habe oder irgendeinen anderen Stil. Ich habe nicht mal behauptet, dass mein Stil der Richtige und deiner der Falsche ist. Ich habe lediglich gesagt, dass ich deinen Stil nicht verstehe und zusätzlich meine Erfahrungen wiedergegeben (deshalb auch die vielen imos).
Die Wasser-Aussage kapiere ich btw. schon mal garnicht.und er propagiert solchen code?
Nö. Er weißt auf die Existenz hin. Und er sagt, dass die Existenz solchen Codes häufig auch einen Grund hat, der von Inkompetenz der anderen Programmierer verschieden ist.
naja, er verkauft ja auch ein bugfix-verfolgungs-programm.
Klar. Damit verliert sein Wort natürlich gleich an Gewicht. Verstehe. Was muss man für Software verkaufen, damit man sich mit dir auf einer Ebene unterhalten darf?
Irgendwie kommt es mir so vor, als hättest du jetzt gerade in den Dampfwalzenmodus geschaltet.
-
HumeSikkins schrieb:
Irgendwie kommt es mir so vor, als hättest du jetzt gerade in den Dampfwalzenmodus geschaltet.
sorry. kann sein, daß zu viel ignoranz mich umgab. ich hab mir so viel mühe gegeben, darzulegen, daß frühe festlegungen den code verschlechtern und daß exploratives programmieren den code verbessert. ich lass mich ja auch von euch überzeugen, daß es oft im team randbedingungen gibt, die vorheriges planen (wenigstens ein wenig) nötig machen.
und dann krieg ich so nen hammer:Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
sie sollen doch gar nicht vorher drüber nachdenken.
"think once, debug ever" ist nur das, wo man landen muß, wenn man das vorher-planen und nicht-wegschmeißen ernst nimmt.
die wasser-aussage spielt auf nen bestimmten diskssionsverlauf an, der sich leicht einstellt, wenn einer ne ungewöhnliche these hat.
es ist fast so, als sagte ich "wasser ist gesund" und jemand antwortete "aber im wasser ersoff mal einer". jedes verhamlosen von mir wie "aber da ersaufen doch nur selten leute" wird sicher sofort erwidert mit "aber mein schwager seine frau auch!" oder so. bis irgendwann jeder von seiner tante was beigetragen hat und ich für viele wie ein idiot dastehe.aber nach ajs letztem posting vergeht mir eh die lust an diesem thread. am wochendende werd ich noch den verlauf vom wpc112 posten.
-
AJ schrieb:
Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
kannst du dich überhaupt daran erinnern, wie es damals als anfänger war?
-
aber nach ajs letztem posting vergeht mir eh die lust an diesem thread
Die hatte ich für meinen Teil sowieso ignoriert
(keine Böswilligkeit. Erklärung steht weiter unten.)
Ich wollte dir erst noch meinen Standpunkt klar machen um dann besser mit dir diskutieren zu können. Wie du ja weißt, habe ich immer Schwierigkeiten damit mich auf mehrere Dinge gleichzeitig zu konzentrieren.Naja, vielleicht sollten wir das Thema auf das nächste Forumtreffen verschieben. Das Instabilität des Forums zur Zeit macht ein ernstes Gespräch imo sowieso viel zu anstrengend.
-
@volkard
Ja kann ich, da es ja noch nicht all zu lange her ist (ca. 5 1/2 Jahren hats angefangen). Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.@volkard & humesikkins
Was war denn bitte so schlimm an meinem letzten Posting??