Informatiklehrer
-
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?
-
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.