Informatiklehrer
-
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??
-
Hi Volkard,
ich verdiene mein Geld mit der Entwicklung/Design von Software, wohl genau wie du.
Ich habe in diesem Formu schon viele gute Beiträge von dir gelesen und habe mir
gedacht der hat ordenlich was auf dem Kasten.
Wenn ich jedoch so lese was du in diesem Beitrag alles zum Besten gibst, hoffe ich
nur das du dich überwiegend ironisch oder zumindestens überspitzt ausgedrückt hast.
Ansonsten hätte sich meine Meinung über dich erheblich geändert.
Du gibst Sachen von dir, die ich von einem Entwickler der im Team Projekte mittlerer
bis grosser Grösse entwickelt nicht erwartet habe.z.B.
"DER PLAN" muss beim coden entstehen.
Da ich als Teamleiter auch für die Einbeziehung von Freelancern zuständig bin, muss
ich dir sagen das ich jemanden mit dieser Vorstellung von einer professionellen Projektwicklung,
weder als freien und noch viel weniger als ständigen Mitarbeiter gebrauchen kann. Da du
offentsichlich sowohl von C++ als vom Design wirklich Ahnung hast finde ich das wirklich
ziemlich schade.
Für mich bist du damit der Prototyp eines "genialen" Hackers bzw. Einzelkämpfers mit
ausserordenlich viel Sachverstand, jedoch ungeeignet zur planvollen und kontinuierlichen
Entwicklung grosser Software-Projekte. Einsetzbar überall dort wo plötzlich Probleme und
Fehler auftreten, die mit keiner noch so guten Planung verhindert werden können, richtig !!Das mit dem wegschmeissen sehe ich übrigens genauso
mfg JJ
-
AJ schrieb:
Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.
Ich habe den Sinn von Struktogrammen nie gesehen.
Mein Vater steht zwar auch drauf, aber er mag ja auch Pascal am liebsten - insofern kann ich ihn nicht immer ernst nehmen.