Informatiklehrer

[SirLant]

Unsere IT-Lehrer sind so wie ich gehört habe alle nicht so die Experten, und vor
allem ist es furchtbar wie gut sich unserer mit der Sprache auskennt ständig
macht der was falsch weil ers einfach nicht kann und dabei hat er sogar nen
Buch zur Sprache

HTML-Programmierung haben wir auch, mit Frames

Dann kommen ab und an kluge Sätze, wie: "In der IT-Welt wird fast nur C++ eingesetzt,
Sprachen wie Delphi benutzt keiner wir nehmen Java auch nur weil es kostenlos ist
und man leicht auf C++ umsteigen kann."
Die Compiler von Borland und Microsoft kosten ja Geld

Könnt hier noch viel erzählen, aber das lassen wir besser, ich halt meist die klappe
und bekomm dafür ne gute Note und helf den Mitschülern

[Griffin]

Ich denke schon, dass Geld im Bezug auf Bildung inzwischen eine zu große Rolle spielt. Das macht sich halt gerade im Bereich Informatik bemerkbar, da gute Hardware und Software halt doch Geld kostet und man sich nicht immer das beste und aktuellste leisten kann. Vielleicht noch nicht einmal mit Förderungen vom Bildungministerium...Wir benutzen halt auch noch Delphi4 und für Java so einen blöden Klickbunti-Editor. Da würde mir aber eigentlich schon Notepad reichen

[Marc++us]

Griffin schrieb:

Das macht sich halt gerade im Bereich Informatik bemerkbar, da gute Hardware und Software halt doch Geld kostet und man sich nicht immer das beste und aktuellste leisten kann.

Das gilt auch für die Lehrer!

Die Guten sind vor 3-4 Jahren alle in die Industrie und haben ihre Jobs hingeschmissen.

[Steven]

Marc++us schrieb:

Steven schrieb:

vor allem, da objektorientiertes Design ohne UML eigentlich leichter ist. Die Algorithmen entscheiden ja schließlich, ob und wie gut ein Programm funktioniert.

Bitte erklären.

Natürlich mach ich mir bei größeren Projekten schon vorher Notizen, welche Klassen ich brauche und wie diese miteinander in Beziehung (Vererbung) stehen. Allerdings brauch ich dazu keine Formvorschriften a la UML. Das Design des Programmes ist am Ende sowieso ähnlich zum Entwurf mit UML, nur dass ich mir den Aufwand und die Zeit für die Zeichnerei spare.

Marc++us schrieb:

Abgesehen davon ist bei größeren Projekten das Design noch wichtiger als die Algorithmen, denn wenn das Design nicht stimmt, nützt der beste Algorithmus nix.

...andererseits nutzt mir ein Packprogramm, das nicht packt, natürlich auch nichts. :p
Im Ernst: Natürlich ist beides wichtig, aber bei uns werden die Algorithmen völlig vernachlässigt. Wenn unser IT-Lehrer eine Quicksort-Routine schreiben soll, fängt der wahrscheinlich erstmal an, ein Sequenzdiagramm dazu zu zeichnen...

[Griffin]

Marc++us schrieb:

Das gilt auch für die Lehrer!

Die Guten sind vor 3-4 Jahren alle in die Industrie und haben ihre Jobs hingeschmissen.

Hap, damit hast du natürlich ganz klar Recht! Es sollten regelmäßig Seminare oder Lehrgänge für sowas geben, da die Entwicklung auf dem Gebiet der Informatik auch sehr rasant voranschreitet. (wobei es diese Weiterbildung bestimmt gibt)

[Ruhollah]

Berichte über meinen Informatikunterricht dürfen nicht fehlen. Ich habe 2002 Abitur gemacht. 1999 hatten wir ein halbes Jahr Informatik in der Zehnten. Der Lehrer war lustig, aber Programmierung wurde nicht gemacht, sondern Textverarbeitung. Ich finde, dass Textverarbeitung wichtig ist, denn viele verwechseln eine Textverarbeitung mit einer Schreibmaschine und knallen ans Zeilenende jedesmal ein Absatz.

Im Schuljahr darauf gab es Informatik ganzjährig: Textverarbeitung, Tabellenkalkulation und Pascal. In Schuljahr 12 machten wir nur Pascal und gegen Ende spielten wir mit dBase III. Im letzten Schuljahr hat der Lehrer aber die Vogel abgeschossen: Das ganze Jahr über machten wir "Präsentation mit Powerpoint". Während ein anderer Kurs Prolog hämmerte, durften wir eine Präsentation über Onkel Pauls 80. Geburtstag machen und im anderen Semester eine Präsentation über ein selbstgewähltes Thema, in meinem Falle C++.

Die Bewertung der Präsentationen war auch total idiotisch. Es wurde gezählt, wie viele Animationen und Töne die Präsentation beinhaltete. Wer keine Animationen und keine Töne hatte, bekam null Punkte, obwohl Animationen und Töne in Präsentationen im richtigen Leben ungern gesehen/gehört werden. Animationen und Töne sind, wenn es zu viele sind, kontraproduktiv.

Die Kritik, Informatiklehrer müssten aufgrund der rasanten Entwicklung in der Informatik an Weiterbildungen teilnehmen, teile ich nicht. Der Informatikunterricht muss nicht auf der Höhe der Entwicklung sein, denn im Informatikunterricht müssen Grundkenntnisse vermittelt werden. Wichtige Sortieralgorithmen (Bubblesort, Quicksort, Mergesort usw.), Objektorientierung, Suchverfahren usw. gibt's doch schon seit geraumer Zeit. Die Grundkenntnisse gilt es zu vermitteln. Man muss auch nicht zig Programmiersprachen lernen, denn wenn man eine Programmiersprache kann, kann man auch alle ähnlichen Programmiersprachen. Der Einstieg erfolgt am besten mit Pascal; Pascal wurde von Niklaus Wirth allein wegen dem Lehraspekt so entwickelt. Will man Objektorientierung, kann man wenig Problemen auf Java oder C++ umsatteln. (Niklaus Wirth hat doch Modulo oder s. ä. entwickelt, eine Lehrsprache für die Objektorientierung; Modulo ist auch eine Möglichkeit.)

Was man überhaupt nicht im Informatikunterricht braucht, ist Delphi oder eine sonstige Entwicklungsumgebung. Ein freier Editor (Emacs!) und ein freier Übersetzer (davon gibt's reichlich) kosten nicht nur weniger, sondern man kann damit auch vernünftig lernen. Ich habe mal als Einsteiger die Erfahrung gemacht, dass Entwicklungsumgebungen wie Delphi einen geradezu erschlagen; man sieht den Wald vor lauter Bäumen nicht. Auch wenn solche Entwicklungsumgebungen aktueller Stand der Technik sind, so sind sie doch im Informatikunterricht ungeeignet.

Völlig fehlentwickelt ist ein Informatikunterricht an einer mir bekannten Privatschule; dort wird den Schülern Videoschnitt beigebracht. Es ist zum Glück nicht mein Geld.

In den Informatikunterricht gehören auch Grundkenntnisse in der Tabellenkalkulation und in der Textverarbeitung. Ich habe während eines Betriebspraktikums in einem Planungsbüro die Erfahrung gemacht, dass nicht jeder damit sinnvoll umgehen kann. Die Vize-Chefin (zugleich Tochter des Chefs) hatte in Excel eine Tabelle mit Preisen eingehämmert. Sie druckte die Tabelle aus und meine Aufgabe war es, zu überprüfen, ob die Summe am Ende auch stimmte. Die Summe wich von der tatsächlichen Summe geringfügig ab. Die Frau hatte doch tatsächlich die Zahlen eingehämmert, aber nicht die Summe über die Summenfunktion errechnet, sondern die Summe vor dem Bildschirm mit dem Taschenrechner errechnet und unter die Zahlenreihe getippt. Man muss sich mal klar werden, was das für die Produktivität und Volkswirtschaft bedeutet, wenn in vielen Büros dieser Republik eine solche Unkenntnis herrscht. Es wird zusätzlich noch Kapital verschwendet, wenn man gutes Geld für Excel ausgibt, aber sich nicht einmal der Grundfunktionen Excels bedient. Bei der Bundeswehr bat mich eine Beamtin von der StOV, ihr ein bisschen bei Excel zu helfen. Sie wusste nicht mal, was Kopf- und Fußzeilen sind. Man muss sich mal bewusst werden, wieviel Kapital auch beim Staat wegen mangelnden Grundkenntnissen in der Informationsverarbeitung verschleudert wird; beim Staat ist Verschwendung aber nichts neues. Die Beamtin hätte sich mal lieber in Excel richtig einfuchsen sollen, dann hätte sie auch mehr Zeit gehabt, mit ihrem Lieblingskasernenfeldwebel Kaffee zu trinken.

[Ranus.net]

hu

habe das jetzt zwar net durchgelesen - aber - hey !
sei doch froh ... unsere könnte das gar net *fg*....

wir machen so nen scheiss in delphi (das heißt - sie erzählt was - schreibts an die tafel - oder per beamer an die wand - wir schreiben ab - bei wem das net klappt - pech gehabt - helfen kann sie auch net - wenn jemand ne frage hat - öööhm - fragt sie einen von uns der mehr ahnung davon hat .. *omg*)

sorry - aber sowas infolehrerin ^^

bye bye

[volkard]

Marc++us schrieb:

Steven schrieb:

vor allem, da objektorientiertes Design ohne UML
eigentlich leichter ist. Die Algorithmen entscheiden ja schließlich, ob und wie gut
ein Programm funktioniert.

Bitte erklären.
Es gibt sicherlich Alternativen zu UML, dennoch würde mich konkret interessieren was
Du unter objektorientierem Design verstehst und wie Du dieses darstellst...
Abgesehen davon ist bei größeren Projekten das Design noch wichtiger als die Algorithmen,
denn wenn das Design nicht stimmt, nützt der beste Algorithmus nix.

(ausnahmsweise ein paar grossbuchstaben wegen der historischen bedeutung)

Sag mal, Marc++us, malst du die Algos, die du erfasst, vorher auf Papier?
So, wie damals vor 20 Jahren die strukto-Heinis lehrten und die IHK noch heute?
Das war schon immer und ist noch heute der falsche Weg. Man darf nicht die Algos
hinmalen, um sie zu verstehen. Man muß die Daten malen. Bäumchen, Listchen, Arrays und
so malt man und an denen probt man den im Kopf estehenden Algo und verfeinert und
beginnt ihn zu kapieren. Statt des Malens kann man oft noch besser Karten auslegen,
Münzstapel bauen usw.. Die langsam wachsenden Teile darf man gleich einhacken.
Dabei lernt man auch, wie sich der Algo auf der Maschine anfühlt, evtl ist er ja Mist
und man sollte über nen neuen nachdenken. Und wie er sich auf der Maschine anfühlt,
bestimmt, wie er im weiteren implementiert wird! Bestimmt sogar, für welche
Datenstrukturen man sich entscheidet und darüber wieder Teile des Algos oder ihn ganz.

Ohoh, der sündige Begriff kommt. "explorativ programmieren"!

Ja, so macht man es. Ich stehe dazu. Mein Prof stand dazu. Und es ist der einzige
vernünftige stil. Nicht nur, daß man in halbdokumentierten Welten wie der winapi
gar nicht anders kann, es ist auch die natürliche Herangehensweise und der erzeugte
Code ist regelmäßig erheblich besser, als bei vorhergemalten Programmen.

Ja, ich lernte damals, daß ungeplante Programme regelmäßig ganz schlecht seien. Ja, da
ist gar kein Widerspruch. Der erste Entwurf ist immer schlecht. Aber den verbessert man
ja dann. Welchen Nutzen kann es haben, zuerst ne Weile auf Papier zu verbessern, dann
willkürich auf Code zu wechseln und dann im Code weiter zu verbessern? Keinen. So
planten die Planer das ja auch nicht. Die planten, daß man auf Papier verbessert und dann
nach Code übersetzt und fertig. Und nach der Codierung die Sintflut. Das ist doch
offensichtlich Write-Only-Vorgehen.

Struktogramme sind schädlich und verschlechtern den entstehenden Code!

Es fragt sich, warum sich diese Irrlehre mit den Struktogrammen so lange gehalten hat.
Hat man auf "goto considered harmfull" von Dijkstra einfach schrecklich überreagiert?
Oder gibt es ein allinformatorisches Prinzip, das besagt, daß stets die Wirtschaftler
mit der wenigsten EDV-Ahnung die Vorgehensweisen erzwingen können? Ich kann es leider
nicht nachvollzehen, da ich nie an Struktogramme glaubte.

Das Urteil bezieht sich natürlich nicht nur auf Struktogramme, sondern auch auf Konsorten.

Um so erschreckender ist es, daß man heute mit UML den gleichen Fehler macht, wie damals.
(Und mit Konsorten.)
Jetzt sind es nicht mehr die Algos, die das Programm bestimmen, sondern die Klassen.
Es waren im übrigen nie die Algo-Verflechtungen und auch nie die Klassenverfelchtungen.
Man malt die Klassen in völlig wurstigen Diagrammen hin, die angenommen, man macht sie
vorher, das Programm blockieren. Aber die UML-Heinis von heute sind die Strukto-Heinis
von gestern. Sie lehren, man solle UML hier und UML da malen. Die IHK steigt nach UML um
und prüft jetzt UML ab aber keinen Code. So, als könne man damit ein Programm beschreiben.

[quote="Marc++us"]dennoch würde mich konkret interessieren was Du unter
objektorientierem Design verstehst und wie Du dieses darstellst[quote]
Man kann gutes OO-Design nicht darstellen. Mit UML-Klassenstrukturdiagrammen malt man
nen Vererbungsbaum und ein wenig Käse dazu.

class KFZ
{
  double x,y,z;//in millimeter
  double gewicht;//in gramm
  string halter;
  ...
};
class PKW:public KFZ
{
  int anzahlSitzplaetze;
  ...
};
//UIHUIHUIH, ist dieser Entwurf grottenschlecht!
//Aber man sieht es nicht direkt und auf dem Bildchen genausowenig direkt!

(Ich hoffe, du vertraust mir, daß ich gutes OO-Design hinkriege und normaerweise nicht
wie oben alle zwei Zeilen einen Fehler mache (sie aber in fremdem Code sehe). Gerade
deswegen darf ich das Maul aufreißen und sagen, daß Bildchen störend sind.)

Und dazu male man mal ein Bildchen. Ohoh, das Bildchen sagt nicht mehr und nicht weniger
aus. Wozu also malt man die Bildchen? Doch nur, um zu reduzieren! Ich aber kenne den
textuellen Redukator "...". Damit klappt das auch.

Ich hoffe, wir sind uns einig darüber, daß man in UML nicht planen darf. Tut man's, kriegt
man sofort suboptimalen Code. Willst Du den zweitbesten einstellen? Wohl eher den besten.
Aber er soll zweitbesten Code bauen? Da paßt doch was nicht.

Und wem gegenüber wird dokumentiert? Leuten gegenüber, die C++ flüssig lesen können?
Die arbeiten lieber mit Pseudocode.

UML hat allein die Berechtigung, damit den Chef zu belästigen! Wenn er UML haben will, dann
kriegt er's. Aber UML hat nix und überhaupt nix in der Entwicklung zu suchen. Entsprechend
soll man UML erst malen, wenn das Prog ausgeliefert wurde. Und jede
Lehre von UML in Schule und Berufsschule ist schlichte Zeitverschwendung. Zum Glück
haben die Kids dahingehend ein sicheres Gefühl und lehnen den Kram von selber ab.
Es besteht also erstmal nur geringe Gefahr, die Kids sogar zu verderben (Struktogramme
waren gefährlicher und UN war direkt infektiös).

Warum fallt ihr immer auf solche Zeitgeister herein, statt normal zu coden? Was ist das
für ein Geheimnis, das sich mir nicht erschließen mag?

Und unabhängig davon, ob jemand mir dies beantworten kann oder mag: Hört endlich mit
UML auf. Hört da mal auf mich, ihr werdet in zehn oder fünfzehn Jahren, wenn die
Mehrheit es einsieht, es mir danken.

[volkard]

Steven schrieb:

Natürlich mach ich mir bei größeren Projekten schon vorher Notizen, welche Klassen ich brauche und wie diese miteinander in Beziehung (Vererbung) stehen. Allerdings brauch ich dazu keine Formvorschriften a la UML. Das Design des Programmes ist am Ende sowieso ähnlich zum Entwurf mit UML, nur dass ich mir den Aufwand und die Zeit für die Zeichnerei spare.

Aha, sie haben dich schon gefickt!
Die Formvorschriften lehnste ab, aber willst schon den "Entwurf" vorher notieren, nur lockerer.
TU ES NICHT!

[Marc++us]

Volkard, Du bist gerade an meiner Ausfahrt vorbei gerast.

Mir ist die Notation grundsätzlich egal - UML, Pseudocode, oder C++ mit [...].

Die Idee dahinter ist aber immer gleich - eine abstraktere Ebene oberhalb des Codes. Viel zu viele Leute fangen aber gleich mit dem Code an und "spiralen" sich dann Richtung fertiges Programm.

Das mag angehen, wenn ein Entwickler für alles alleine verantwortlich ist, weil er die Abstraktionsebene im Kopf hat. Bei Teams mit mehr als zwei Personen ist aber eine Absprache von groben Entwürfen notwendig. Und dazu wird man irgendeinen Formalismus wählen, der kaum bereits auf Codeebene liegt.

Hacken alle Leute selbständig darauf los und explorieren ihren Code, passt hinterher vielleicht die Mutter nicht mehr auf das Gewinde. Bei Toll-Collect haben sie hinterher Module zusammenfügen wollen, bei denen die Datenschnittstellen nicht übereinstimmten. Da wäre irgendwann ein Bildchen vielleicht sinnvoll gewesen, bevor man an 2 getrennten Entwicklungsorten mit der Codierung beginnt.

Ich unterstelle folgendes Modell: n Entwickler (n > 1) unterhalten sich über ein Softwareprojekt. Dazu bedienen sie sich einer Sprache mit gemeinsamen Zeichenvorrat. Je weniger gut sich die Leute kennen, desto weniger gut kann man eine nicht-standardisierte Sprache dafür verwenden. Weiterhin darf's nicht zu genau werden, man will ja noch nicht coden. UML (aber nur die 1.x... 2.0 ist "bißchen" zu detailiert geraten) ist dafür gar nicht so schlecht. Nicht ideal, aber auch nicht schlecht.

So, nun mache ich einen umgekehrten Induktionsschluß und nehme an, daß auch ein Einzelentwickler (Teamgröße n = 1) so arbeitet - er kommuniziert mit sich selbst genauso über eine Abstraktionsebene. Natürlich völlig unnötig, da man diese Stufe vereinfachen kann. Aber wenn ich will, daß diese Person irgendwann mal im Team arbeitet, benötige ich diese Abstraktionsebene - damit diese Person eben über die notwendige Schnittstelle verfügt.

Netter Nebeneffekt ist, daß man Lehrnende auch mal zwingt, sich von ihrer gottverdammten Programmiersprache zu lösen und mal das Problem abstrakt zu durchdenken.

Abgesehen davon kann man Indern mit UML total toll erklären.

[Steven]

@volkard: Dein langer Artikel spricht mir aus der Seele!

volkard schrieb:

Steven schrieb:

Natürlich mach ich mir bei größeren Projekten schon vorher Notizen, welche Klassen ich brauche und wie diese miteinander in Beziehung (Vererbung) stehen. Allerdings brauch ich dazu keine Formvorschriften a la UML. Das Design des Programmes ist am Ende sowieso ähnlich zum Entwurf mit UML, nur dass ich mir den Aufwand und die Zeit für die Zeichnerei spare.

Aha, sie haben dich schon gefickt!
Die Formvorschriften lehnste ab, aber willst schon den "Entwurf" vorher notieren, nur lockerer.
TU ES NICHT!

Nein, ich habe mich nur unglücklich ausgedrückt: Bei großen Projekten mit mehr als ca. 6-8 Klassen schreibe ich mir auf, welche Klassen ich brauche und welche Klasse von welcher erbt. Viel mehr ist das eigentlich nicht. Für kleine Projekte habe ich das auch noch nie gemacht.

Man muß die Daten malen. Bäumchen, Listchen, Arrays und
so malt man und an denen probt man den im Kopf estehenden Algo und verfeinert und
beginnt ihn zu kapieren. Statt des Malens kann man oft noch besser Karten auslegen,
Münzstapel bauen usw.. Die langsam wachsenden Teile darf man gleich einhacken.
Dabei lernt man auch, wie sich der Algo auf der Maschine anfühlt, evtl ist er ja Mist
und man sollte über nen neuen nachdenken. Und wie er sich auf der Maschine anfühlt,
bestimmt, wie er im weiteren implementiert wird! Bestimmt sogar, für welche
Datenstrukturen man sich entscheidet und darüber wieder Teile des Algos oder ihn ganz.

So mach ich das auch, wenn ich neue Algorithmen entwerfe oder versuche zu verstehen. Klappt eigentlich auch immer ganz gut...

Welchen Nutzen kann es haben, zuerst ne Weile auf Papier zu verbessern, dann
willkürich auf Code zu wechseln und dann im Code weiter zu verbessern?

Meine Rede!

Struktogramme sind schädlich und verschlechtern den entstehenden Code!

Es fragt sich, warum sich diese Irrlehre mit den Struktogrammen so lange gehalten hat.
Hat man auf "goto considered harmfull" von Dijkstra einfach schrecklich überreagiert?
Oder gibt es ein allinformatorisches Prinzip, das besagt, daß stets die Wirtschaftler
mit der wenigsten EDV-Ahnung die Vorgehensweisen erzwingen können? Ich kann es leider
nicht nachvollzehen, da ich nie an Struktogramme glaubte.

Goto macht den Code sogar in manchen Fällen lesbarer, nämlich, wenn man aus mehrfach verschachtelten Schleifen raus will.

Aber die UML-Heinis von heute sind die Strukto-Heinis
von gestern. Sie lehren, man solle UML hier und UML da malen.

Und so einen haben wir als IT-Lehrer...

BTW: Ich wäre mal dafür, diese Grundsatzdiskussion in einen eigenen Thread zu verschieben...

[volkard]

Steven schrieb:

Nein, ich habe mich nur unglücklich ausgedrückt: Bei großen Projekten mit mehr als ca. 6-8 Klassen schreibe ich mir auf, welche Klassen ich brauche und welche Klasse von welcher erbt. Viel mehr ist das eigentlich nicht. Für kleine Projekte habe ich das auch noch nie gemacht.

ich empfehle es auch für 100 klassen nicht. die klasse leuchtet aus sich selbst heraus und ist rund und gut. sie lebt nicht erst im verband mit anderen klassen.

[quote="Steven"]Goto macht den Code sogar in manchen Fällen lesbarer, nämlich, wenn man aus mehrfach verschachtelten Schleifen raus will.[quote]
aber da will man nicht mt goto raus, da man die mehrfach verschachtelen schleifen in ne funktion ausgelagert hat, und aus den schleifen hüpft dort ein return.

[volkard]

Marc++us schrieb:

Volkard, Du bist gerade an meiner Ausfahrt vorbei gerast.

nicht wirklich, fürchte ich.

Hacken alle Leute selbständig darauf los und explorieren ihren Code, passt hinterher vielleicht die Mutter nicht mehr auf das Gewinde. Bei Toll-Collect haben sie hinterher Module zusammenfügen wollen, bei denen die Datenschnittstellen nicht übereinstimmten. Da wäre irgendwann ein Bildchen vielleicht sinnvoll gewesen, bevor man an 2 getrennten Entwicklungsorten mit der Codierung beginnt.

kann es sein, daß ich den befähigten coder unterstelle und du davon ausgehst, mit luschen zu arbeiten?

So, nun mache ich einen umgekehrten Induktionsschluß und nehme an, daß auch ein Einzelentwickler (Teamgröße n = 1) so arbeitet - er kommuniziert mit sich selbst genauso über eine Abstraktionsebene. Natürlich völlig unnötig, da man diese Stufe vereinfachen kann.

und schädlich!

Aber wenn ich will, daß diese Person irgendwann mal im Team arbeitet, benötige ich diese Abstraktionsebene - damit diese Person eben über die notwendige Schnittstelle verfügt.

er soll erstmal coden lernen! dann entwerfen. und nicht wie heutzutage andersrum. das kann nix werden. oder sollen schüler zuerst englische aufsätze schreiben und lernen erst im studium dann die vokabeln dazu?

Netter Nebeneffekt ist, daß man Lehrnende auch mal zwingt, sich von ihrer gottverdammten Programmiersprache zu lösen und mal das Problem abstrakt zu durchdenken.

nope! eine gottverdammte maschine hat drunter zu sein. und man kann in uml nicht denken. eckmarken und stolperfallen des schlechten entwurfs äußern sich immer darin, daß man letztendlich im coden und warten ein fieses problem kriegt. wie will man dafür ein verständnis aufbauen, wen man abstrakte bildchen malt?

edit: streich am besten selbst alle argumente für UML, die mit gleichem wortlaut auch für struktogramme oder für UN sprecvhen würden.

[SirLant]

Hm, also ich hab bisher meist drauf losgeschrieben, weil ich ungefähr im Kopf
wusste wie ich es angehe, mein Nachteil ist, dass das Design ganz von meiner
Laune, Müdigkeit und anderen Einflüssen abhängt, kann man natürlich nachträglich
noch ändern, aber wozu wenn man es mehr zu Spass geschrieben hat

Meine Notizen, wenn ich etwas plane sehen so aus:
-Ich schreib mir auf was ich machen möchte, entwerfe erste Ideen für das Datendesign
-Überlege mir was ich brauche um damit zu arbeiten, dann ändere ich das Datendesign
höchstwarscheinlich, weil man es einfach noch besser machen kann
-Entwerfe ein Klassendesign wo das ganze reinkommt, das ist einfach auf nem Papier:

foo public: bar {
// öffentliche Schnittstellen
// Datenmembers
};

Die Verbindung der Klassen, kann man doch ganz einfach darstellen indem man ein
Blatt nimm die Namen hinschreibt und je nach Art der Beziehung die Linie in ner
anderen Farbe malt. Schnittstellen sind hier doch uninterressant.
Nen Algo entwickle ich eigentlich meist außerhalb und schmiere den erstmal so hin,
versuche zu verbessern und schreibe ihn am schluss nochmal schön (formatierung,
Namen,...) teste ihn nochmal und bau ihn ein.

[Marc++us]

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.

[volkard]

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.

[SirLant]

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.

[Steven]

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.

[volkard]

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=

[SirLant]

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.