Was kann ich mit iso c++ machen?
-
@marc++s
jep
-
@Marc++us
Irgendwie sehe ich deinen Punkt nicht. Es geht doch nicht darum, ob oder wann man an Projekten arbeitet. So wie ich die Frage verstanden habe geht es hier eher darum ob und wann man andere Leute ausbildet.
Und von einem Ausbilder würde ich schon erwarten, dass er von dem Stoff den er lehrt auch ein wenig mehr Ahnung hat.
Und nur weil es schon immer uninformierte Ausbilder gab muss man ja nicht selbst so einer werden.Und zu deinem Punkt: Ich glaube ehrlich gesagt nicht, dass man ein Projekt fertig bekommt ohne das zumindest ein paar im Team ein Plan von dem haben was sie machen. Klar an der Uni wird einem beigebracht, dass nur die ganz oben was können müssen und das die Programmierer dann nichts weiter als austauschbare Resourcen sind. Das widerspricht aber so ziemlich allem was ich bisher gelesen habe. Warum sonst gibt es Bücher wie "The mystical man-month" oder "Death-March" (um nur zwei zu nennen)? Wenn alles so einfach ist, warum scheitern dann so unglaublich viele Softwareprojekte?
-
Sie scheitern wegen Nutzung der VHIT-Methode ... Vom Hirn ins Terminal ohne jegliche Überlegung. Das muss allerdings nicht aus mangelnder Kompetenz in Sachen C++ sein.
-
@Marc++us
es macht einen Unterschied (wie Elise bereits ganz am Anfang gesagt hat), ob man mit etwas programmieren kann oder ob man jemanden etwas beibringen kann. Hier geht es ja um den Fall, dass man jemand unterrichten soll, dass kann man aber nicht ohne solide Kentnisse der Sprache.(BTW. Es gibt aber auch einige Autoren, die praktisch arbeiten, wie zB. Herb Sutter)
-
@kingruedi:
Schau Dir mal genau an, welche Tätigkeit Herb Sutter im praktischen macht... das ist eher die Ecke, die ich nannte. Softwareconsultant und externer Projektberater ist für mich keiner mehr, der an Projekten "tippt".@Dimah:
yep, zum Teil auch damit verbunden, daß oftmals die Anforderungen nicht klar sind, welche Funktionalität eigentlich implementiert werden soll. Irgendwann haben alle was fertig, was keiner will, und man zieht die Reißleine. Im seltensten Fall hängt das davon ab, daß jemand etwas nicht beherrscht - dem Fall kann man mit Maßnahmen auch leicht gegensteuern (Seminar, Buch, ext. Berater). Hauptsächlich ist einfach nicht klar, was gewollt ist.@Hume:
Du hast durchaus auch mal ein Team, in dem keiner eine Ahnung von einem Tool hat, trotzdem wird beschlossen dieses zu nehmen, Training on the job. Wie glaubst Du sind die ganzen Firmen von C auf C++ umgestiegen? 6 Monate die Arbeit niedergelegt und gelesen und geübt, bevor ein Projekt gestartet wurde? Da hieß es "das nächste Projekt machen wir in C++", es gab etwas mehr Zeit, die Tools wurden gekauft, und zwischendrin gab's ein paar Seminare wenn Zeit war. Und so entwickeln sich die Kenntnisse der meisten Mitarbeiter. Man hat Probleme, liest etwas rum ob es das Problem schon wo gibt und eine Lösung dafür... auf diese Weise lernt man dann Design Patterns, Templates und Alexandrescu kennen. Wenn der Kommunikationsfluß im Team gut ist passt sich damit der Kenntnisstand gemeinsam und gegenseitig an. Aber diese Evolution erfolgt von Projekt zu Projekt. Alte haben den Stand nicht, neuere mehr, usw. Das perfekte Projekt gibt's nicht. Bei den Freelancern ist das noch 100mal schlimmer, weil da der Kunde ein Tool vorgibt ohne es zu kennen. Bei einem eigenen Team hat man noch Einfluß auf das Tool.
-
Ach so, noch was zu den Trainern: es kann jemand durchaus ein sehr guter Seminarleiter für C++ sein, ohne den Alexandrescu gelesen zu haben.
Das liegt schon daran, daß bei einem typischen 3 oder 5 Tageseminar doch nur ein Bruchteil der Sprache abgehandelt werden kann. Wenn der Teilnehmer mit Aha-Effekten bzgl. Klassen, Polymorphie, vector<T> und delete/Copykonstruktor raus geht, ist das Ziel bereits erfüllt. Darin muß der Leiter natürlich fit sein, aber mehr ist doch typischerweise einem Anfänger gar nicht zu vermitteln.
Und wieviel ist das von C++? 10%? 20%?
-
5 %
-
Schau Dir mal genau an, welche Tätigkeit Herb Sutter im praktischen macht... das ist eher die Ecke, die ich nannte. Softwareconsultant und externer Projektberater ist für mich keiner mehr, der an Projekten "tippt".
Hmm, okay... Was ist mit dir :p da hast du dir selbst eine Falle gestellt
aber du hast natürlich recht, dass die meisten Buch Autoren nicht wirklich an den Projekten tippen Da hieß es "das nächste Projekt machen wir in C++", es gab etwas mehr Zeit, die Tools wurden gekauft, und zwischendrin gab's ein paar Seminare wenn Zeit war.
Das sieht man leider oft an fremden Code
Diese Methode ist IMHO sehr halsbrecherisch. Aber in der Praxis lässt sich das wohl kaum vermeiden 
-
@Marc++us
Marshal Cline und co beschreiben in "C++ FAQs 2nd Edition" sehr schön die Katastrophen die damals beim Umstieg von C auf C++ eintraten. Und alle Autoren dieses Buch arbeiten in der realen Welt (oder haben dort gearbeitet).Schau Dir mal genau an, welche Tätigkeit Herb Sutter im praktischen macht... das ist eher die Ecke, die ich nannte. Softwareconsultant und externer Projektberater ist für mich keiner mehr, der an Projekten "tippt".
Das macht er jetzt, aber hast du dir mal angeschaut, was er früher gemacht hat? Ich glaube kaum, dass man Herb Sutter vorwerfen kann, dass er nicht weiß, was man in der "realen Welt" braucht.
Es ist bisher kaum ein Consultant vom Himmel gefallen.
Oder nimm Frederick Brooks. Dessen "The Mystical Man-Month" enstand auch aus
seiner praktischen Arbeit.Das perfekte Projekt gibt's nicht.
Das habe ich auch nirgends behauptet oder angenommen. Es gibt aber zweifellos gute und schlechte Ausbildungen. Und mir kann keiner erzählen, dass jemand ohne Erfahrung einem Anderen eine gute Ausbildung verpassen kann.
es kann jemand durchaus ein sehr guter Seminarleiter für C++ sein, ohne den Alexandrescu gelesen zu haben.
Würde ich auch niemals bezweifeln. Nur wenn ein Seminarleiter über spezielle Templatetechniken reden will, dann sollte er zumindest mal in die Bücher von Alexandrescu, Vandevoorde, Barton und Nackman usw. reingeschaut haben.
Kein Mensch lernt nur durch Praxis.
-
Dazu sollten wir zunächst mal definieren, was wir unter Praxis verstehen...
Unter "Lernen in der Praxis" verstehe ich eben, daß man mit 3 oder 4 Büchern auf dem Tisch an einem Projekt arbeitet... aber bereits scharf. D.h. jedes Ergebnis muß benutzt werden.
Als "Lernen in der Theorie" verstehe ich, daß man das Buch 1-3 mal durchliest, die Beispiele ausprobiert, eigene Experimente macht, aber losgelöst von Zeit und Raum, ohne sofortigen Verwertungsdruck der Erkenntnisse.
Versteht mich hier nicht falsch, ich bin ein überzeugter Anhänger der theoretischen Grundkenntnisse und hasse Leute, die sich als Praktiker bezeichnen. Es gibt bekanntlich nichts praktischeres als eine gute Theorie.
Ich will einfach darauf hinweisen, daß die Hoffnung oder Vorstellung, man könne sich während realen Projekten vorher oder begleitend ausführlich und grundlegend in die Theorie des Themengebiets einarbeiten ein frommer Wunschtraum ist.
-
Weiß ja net, an was für Projekten ihr arbeitet,
aber ich fände ich schon entspannend wenn ich während eines Projektes mal die Zeit hätte mir zwei Bücher durchzulesen.Ein Faktor wurde hier überhaupt nicht erwähnt (vielleicht hab ich es auch überlesen). Projekte müssen mitunter unter extremen Zeitdruck durchgeführt werden.
Da es nicht viel mit ein paar gemütlichen Seminaren und massig Einarbeitungszeit auf das Projekt buchen.Man muss ja bedenken das es nicht nur die verwendete Technologie ist, meist ist man schon allein genug damit beschäftigt durch die Fachlichkeit zu steigen.
Und in dem Punkt gebe ich Hume recht, in vielen Fällen hängt das gelingen oder nichtgelingen davon ab ob jemand mit den entsprechenden Skills im Team ist.
Zumindest ist es ein immenser Vorteil.Wenn du ein kleines Team hast ca. 4 reine Entwickler davon 1 bis 2 erfahrene und gute Leute ziehst du die anderen halt mit Know-How-Transfer durch.
Kostet zwar verdammt viel Zeit gibt eine keine Alternative und ist ja auch irgendwo 'ne Investition für die Zukunft.Erfahrungen mit Teams wo nur unerfahrene Leute sind oder Leute die die Technologie nicht kennen hab ich nicht gemacht. Aber wo ist hier der Know-How-Transfer?
Klar, mit genügen Zeit und Budget tun es vielleicht auch 4 Putzfrauen.Die Geschichte mit dem Einsetzen eines Freelancer der der keine Ahnung von der verwendeten Technologie hat, kann ein sehr teurer Spass werden. Wenn es keine alternativen gibt sicher, aber nur als letzes Mittel.
O'Dog
[ Dieser Beitrag wurde am 14.01.2003 um 21:42 Uhr von O'Dog editiert. ]
-
Klar, mit genügen Zeit und Budget tun es vielleicht auch 4 Putzfrauen.
Hey, sag nichts gegen Putzfrauen. Bin eine und kann auch Programmieren.
-
Hallo,
ich finde dieser Artikel von Jack Reeves passt ganz gut zum Thema:
http://www.cuj.com/experts/2101/reeves.htm?topic=expertsZwei interessante Stellen:
[...]I have to wonder why it is that not one of the places I have ever worked has had any policy whatsoever about ensuring their people had anything beyond minimum skills[...]
Real engineers (for that matter, most of the rest of the public) see software development as an undisciplined cottage industry that hasn't grown up yet. And as long as the vast majority of practicing software developers do not have a clue about the basic principles that underlie the techniques that they claim to be using, then the public's perception is pretty much a correct one.
