Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Je comprends qu'on puisse être un expert très tôt sur le langage en lui même, mais il me paraît difficile de pouvoir être qualifié d'expérimenté sans prendre en considération le facteur temps.
Un philosophe pourrait connaître tous les points du standard C++03 sans n'avoir codé une seule ligne de code (Scott Meyers ?). En revanche, il serait incapable de compiler un programme parce qu'il n'a aucune fichtre idée de l'existence de GCC. Il lui manque juste un peu d'expérience
Plus sérieusement, on peut apprendre de l'expérience des autres, mais ce n'est pas pour cela que ta propre expérience ne t'enseignera rien. Il y a une chose que le temps m'a enseigné: c'est qu'il y a des choses qu'on n'apprend vraiment qu'avec le temps.
J'espère pour toi que tu ne deviendras pas à 40 ans quelqu'un qui n'a plus rien appris depuis ses 25 ans parce qu'il savait tout alors.
Envoyé par loufoque
essayes d'imaginer ce que diront des jeunots dans ta situation dans 10 ans, lorsque tu leur montreras tes beaux projets, et qu'ils auront été bercés avec toutes les merveilleuses nouveautés dont la plupart d'entre nous arrivent à peine à entrevoir l'utilité aujourd'hui...
souvent, ça donne une bonne leçon d'humilité
Oui, on y a tous pensé je pense. J'avais lu il y a longtemps déjà des astuces pour automatiquement rejeter les commits si le code ne respecte pas des conventions de codage. Je n'ai jamais utilisé Visual C++ Team System, mais je crois que le compilo effectue de l'analyse statique de code au moment de la compilation (il y a effectivement des avantages de le faire à ce moment là : intégration dans l'IDE, rapidité, ...).
Tu peux tagger toi-même des fonctions comme deprecated avec l'extension deprecated de VC++.
http://msdn.microsoft.com/en-us/libr...7y(VS.80).aspx
plutôt chouette, sauf que ça avait provoqué un tollé:
http://www.informit.com/guides/conte...lus&seqNum=259
Il y a aussi PREfast, toujours chez MS. Et puis plein de projets + ou - évolués, depuis le pseudo moteur de regex qui recherche les occurrences de fonctions à bannir (gets, ...) à des trucs comme PC-Lint, qui date de 1985 d'après leur site... Ou encore viva64 pour migrer le code vers du 64 bits.
Bref, beaucoup de choses depuis longtemps, et la solution miracle n'a toujours pas été trouvée. Le truc c'est que tous ces outils, intégrés au compilo ou non, ça coute cher. Les petites boites ne les achètent pas, alors que, paradoxalement, c'est elles qui en auraient le plus besoin parce que les grosses boites encadrent mieux les développeurs.
Ce qui m'amène à dire...
Tout à fait d'accord. Sauf que, de mon point de vue, C++ n'est pas fait pour ça. Pour moi, ce langage ne convient à des petits projets. Mais ne serait-ce qu'à partir de 10.000 lignes de codes, les bénéfices de la "lourdeur" d'organisation d'un projet C++ commencent à se faire sentir. Typiquement, ce genre d'application génère dynamiquement son interface principale (menus, toolbar, etc...), et alors les "clic-odromes" montrent vite leur limites. Car c'est entre autre cela qui procure cet avantage à Java et .Net : la qualité des IDE, du fait que ce sont des langages plus simples à parser / analyser.
Tu parlais de makefile par exemple... Mais tous les projets sérieux les utilise, que ce soit en Java ou .Net (msbuild, c'est du makefile XML). Bref, je pense personnellement que plus le projet grandit, et plus C++ commence à devenir intéressant.
Ce débat C++ vs Java/.Net, je crois que c'est aussi le débat langage libre vs langage "poussé" par une société très puissante. Il y a eu une réflexion dans ce sens suite au rejet des concepts dans C++0x : n'est-ce pas l'échec d'un modèle ouvert face à l'incroyable vitesse d'évolution de .Net par exemple? C'est une question qui secoue beaucoup les sensibilités de chacun, mais je la trouve intéressante.
En fait, c'est assez simple : pour progresser, il faut faire des erreurs. Sauf que certaines personnes savent apprendre du premier coup là où d'autres doivent faire 50 fois la même erreur. C'est pas du tout spécifique à l'informatique.
Ca t'apprend aussi que la résistance d'une chaine est celle de son maillon le plus faible, et que tu ne peux pas vraiment utiliser le C++ moderne ou autre si dans l'équipe il y en a un qui n'arrive pas ou ne veut pas suivre. Dans ce sens ça t'apprend l'humilité, parce qu'avec notre utopie de perfetionniste on arait vite fait de planter le projet.
Une raison de plus pour que les "anciens" ou "expert expérimenté doux génie" écouter les jeunots un peu plus (pas trop non plus hein), c'est aussi rigolo parfois pour un jeune de tomber sur un style de programmation d'antan sans pour autant que cela ressemble à de la digression ou un irrespect de l'expérience des vrais pros
sinon comment vous arrivez à faire la différence entre un jeune et un ancien autrement que par l'âge car dans cette voie cela me semble d'une certaine façon assez discriminatoire
Techniquement sur le langage cela me gêne d'entendre que l'accent est mis sur la compilation pour prévenir des erreurs de type ou de linkage par exemple mais fait totalement abstraction de la programmation des exceptions (qui est inclus d'un certain concept dans le langage que j'appréhende pas bien).
Des messages de compilation pour des exceptions obligatoires que l'on veut traiter à la compilation me semble judicieux, en c++ cela existe mais l'utilisation pratique mise à part quelque exemple douteux sur la gestion de la mémoire est-ce que vous avez des exemples de code ?
L'âge est quand même le premier critère (c'est un peu la définition d'un jeune et d'un ancien). J'ai du mal à comprendre ce que tu veux dire par discriminatoire.
Plus précisément, sur un CV, on regarde le nombre d'années d'expérience, et là ce n'est pas toujours si corrélé à l'age. Il y a des personnes de 35 ans qui ont 12 ans d'expérience, et d'autres qui, entre les stages, les sabbatiques, les voyages, le chomage, les formations et j'en passe, ont du mal à en justifier 5... (j'aimerais pas être ceux là)
On regarde aussi la nature de l'expérience. Un programmeur, comme celui de Klaim, qui a passé 10 ans à ne faire qu'une chose aura un peu moins d'expérience. Celui qui n'est jamais resté plus de 3 mois sur un projet non plus, d'ailleurs (il faut voir pas mal de choses, mais les voir en profondeur).
Ensuite, en entreprise, on s'en rend compte assez vite. Le jeunot va généralement être obsédé par ses "boites à outil". On n'a pas fini de lui décrire le problème qu'il est déjà en train de farfouiller à la recherche de l'algorithme magique "qui règle le problème en une ligne" (même si ce n'est pas le même problème, et s'il lui faut un mois pour écrire correctement cette ligne...). Il aura aussi une plus grande foi dans les specs, les cahiers des charges, et les données, là ou l'ancien sait que les données ne sont à peu près jamais bonnes du premier coup, que les specs changent presque toujours avant d'avoir été programmées, et qu'un cahier des charges, ca synthétise les données et les specs...
Le jeunot aura généralement aussi du mal à évaluer, le temps nécessaire à une tâche (c'est aussi mauvais de le sous estimer que de le surestimer, dans ce contexte), les volumes de données et de traitement liés à un programme, l'évolutivité d'un morceau de code, ou simplement les bugs. Quand un calcul compliqué donne un résultat manifestement faux, il faut d'abord se rendre compte qu'il est faux, et ensuite deviner d'où cela peut venir. C'est le genre de question sur laquelle l'experience se fait sentir...
Francois
Dans GNU/GCC (g++) il y a déjà pas mal de vérifications activables, comme par exemple "-Weffc++". Plus d'info : Google "C++ Dialect Options"
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
C'est bien dit... Et ja rajouterais meme que ca fonctionne quelque soit l'age. Toujours persuade d'etre un pro, on se rend compte 5 ans plus tard qu'on ne l'etait pas.
Je vais peut être (certainement) passer pour un vieux con mais je trouve que avant, quand il n'y avait pas Internet et qu'on devait chercher parfois jusqu'à pas d'heure des solutions aux problèmes avec comme seul ami le bouquin de borland, c'était très formateur. De nos jours, on voit de plus en plus de codeurs qui ne savent plus "chercher" et qui se précipitent sur google ou sur un forum au moindre soucis...
Ne t'inquiètes pas, on voit aussi de plus en plus de personnes qui se dirigent vers les bons endroits avec les bonnes méthodes.
Y'a beaucoup plus de personnes qu'avant qui s'y mettent et qui travaillent sérieusement dans leur coin avec de bonnes ressources, et qui se font une très bonne expérience.
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Heureusement, sinon qui va prendre la releve ^^
P-ê te fais-tu avoir par le fait que les informations sont plus simple d'accès et qu'il y a donc plus d'amateur du dimanche qui n'aime que le côté positif ( càd quand ça fonctionne ) et qui veulent que leurs problèmes soient résous "bêtement" par qqn d'autre ?
l'âge c'est flou, d'ailleurs je suis curieux de savoir à quelle âge tu estimes qu'on est plus un jeunot ou que l'on devient un ancien, j'ose espérer que la marge est grande
C'est certainement vrai, mais le bouquin (quel qu'il soit) a un inconvénient majeur : Il ne présente, en définitive, qu'un seul point de vue (celui de l'auteur)
Et ce problème est d'autant plus marqué si le bouquin est spécialement dédié à un outil / une bibliothèque particulier(ère) comme la VCL de borland.
En effet, le point de vue de l'auteur sera irrémédiablement biaisé par la philosophie de la bibliothèque ou de l'outil en question, et peut donc mener soit à une mauvaise compréhension des base, soit induire de mauvaises habitudes.
Une recherche sur google peut être aussi formatrice que la lecture (ou la recherche dans) d'un bouquin, mais permet de comparer différents points de vue
Reste le problème des forums...
Selon la manière dont on les utilise (et le forum en lui-même), ils peuvent avoir un résultat qui varie véritablement entre l'excellent et l'exécrable
Si on les utilise pour avoir une explication supplémentaire sur un point qui n'est abordé que de manière trop sommaire, pour se donner l'occasion de "changer de point de vue", voire, pour aller "au fond des choses", leur utilisation -- à condition que les intervenants soient compétants... ce qui n'est pas forcément gagné -- aura un effet des plus positif.
Par contre, si l'on se tourne vers le forum simplement pour "avoir la réponse que l'on ne veut pas chercher soi-même", il est clair qu'ils n'ont rien de formateur
A méditer: La solution la plus simple est toujours la moins compliquée
C'est forcément assez flou, parce que les parcours varient d'un individu à l'autre. Mais pour donner une idée à la louche, je dirais ...
- qu'un jeunot a moins de trois ans d'expérience professionnelle (faire de l'ordi à la maison, ou des stages, ca ne compte pas vraiment)
- qu'un ancien traine ses guêtres dans le monde de l'informatique depuis une dizaine d'années au moins, il aura généralement un certain nombre de gros projets derrière lui (je crois que c'est Brooks qui décrit l'ingénieur expérimenté comme celui qui en est à son "troisième système", il parlait là de développement de systèmes d'exploitations, donc je pense qu'il aurait plutôt dit 15-20 ans pour les anciens...)
Entre les deux, faut voir... Une fois de plus, ca peut changer d'un profil à l'autre, mais s'il faut absolument profiler par la date de naissance, par les temps qui courent, un ancien sera généralement né avant 1975, un jeunot dans les années 80...
Maintenant, et pour éviter de relancer une quelconque polémique, être ancien ne veut pas dire être expérimenté, être un jeunot ne veut pas dire être ignorant.
Francois
Brooks parlait du "second system effect" pour les architectes. Pour le premier système qu'on conçoit, on a tendance a être très, tros prudent. Pour le second, on a tendance à se lacher et à mettre tout ce qui serait bien et qu'on n'a pas mis dans le premier. Par la suite, on garde un meilleur compromis.
l'informatique n'est pas une science exacte, et une méthode qui marchera très bien dans un contexte peut foirer dans un autre contexte, et tout projet est unique.
et dans ces cas la loi normale entre en jeu, c'est a dire que lorsqu'on a vu pas mal d'échantillons on se rapproche de la bonne approche a faire, je pourrais même dire que l'informatique se rapproche plus de l'empirique que de la science exacte.
et dans ce cas avoir vu pas mal de projet permet d'affiner notre manière d'aborder les projets, prenons par exemple juste le probléme de déploiement, combien de fois a la fin du dev on se rend compte qu'il y a un souci sur tel machine ou tel configuration, si on a pas vu ces problèmes dans des projets avant on peut tout simplement foirer le projet au cas ou on se rend compte a la fin qu'il y un grand probléme de déploiement.
mais l'expérience a son revers , a force de faire une chose d'une certaine manière ça devient évidente et on ne se rend pas compte que c'est très très compliqué pour un débutant et on ne veut même pas comprendre pourquoi c'est compliqué et c'est toujours la faute au débutant qui n'arrive pas a comprendre facilement.
par exemple chercher sur internet des exemples pour faire la somme et en général vous ne trouvez que la version bugué c'est a dire int sum(int a,int b).
qui est fausse vue que la somme de 2 entiers peut dépasser la capacité d'un entier, mais dans la majorité des contextes ça marche bien mais dans d'autre cas ça peut causer des dégâts surtout qu'on a pas le réflexe de tester avec les grands nombres.
et des fois un expérimenté ne va même pas faire attention a ça vu qu'il a fait plusieurs fois de cette manière , et un étudiant peut faire la remarque
a mon avis il faut toujours entendre aux débutants même s'ils disent des trucs banales , ça peut remettre en question des choses pour un souci d'amélioration, quelqu'un qui a une expérience peut être rigide et ne voit la problématique que d'après ce qu'il a vécu comme expérience or chaque projet est unique et il faut toujours être attentif et ne jamais baisser sa garde parce qu'on a des années d'expériences.
si effectivement cela ne te pose pas de problème d'utiliser comme premier critère un critère flou mais c'est assez bizarre.
- qu'un jeunot a moins de trois ans d'expérience professionnelle (faire de l'ordi à la maison, ou des stages, ca ne compte pas vraiment)
Des stages ce n'est pas une expérience qui compte, dis-moi alors cela sert à quoi d'en faire un ? Quel en est l'objectif majeur ?
C'est ce que j'essaie de dire soit le critère de l'âge n'est pas pertinent du tout, la connaissance théorique et l'application pratique le sont plus, en tout cas c'est moins exclusif, c'est une pensée j'ai envie de dire "à la française"Maintenant, et pour éviter de relancer une quelconque polémique, être ancien ne veut pas dire être expérimenté, être un jeunot ne veut pas dire être ignorant.
Pour le stagiaire, j'en vois trois...
1- Certaines formations exigent des stages. En gros, ca sert à avoir son diplome/ses UV...
2- Ils permettent de se faire une idée rapide sur le monde de l'entreprise et le métier (ça évite une horrible surprise quelques années plus tard)
3- C'est un moyen d'entrer dans les entreprises, à une époque où le chomage est important (en gros, il y a moins de place en CDD/CDI qu'en stage, le stage est une façon de rester en contact)
Pour l'entreprise, je n'en vois qu'un, mais de taille : le stagiaire, ca ne coute pas cher.... Par rapport à la période d'essai, qui permet tout aussi bien de juger d'une personne, ou au CDD qui permet d'embaucher temporairement, le stage ca coute nettement moins. Dans pas mal de secteurs, quand tu as besoin d'embaucher, tu demandes à ton DAF, qui te répond, "CDD/CDI non, stages tant que tu veux" (il ya aussi à cela une raison technique: dans les grands groupes, les stages ne sont pas comptés dans les mêmes ratios que les salaires...)
Ca va etre mon dernier message sur ce fil, on est totalement hors sujet là. (désolé pour les lecteurs que ceci ennuie)
Francois
Euh je pense que si les formations exigent des stages c'est pas pour faire joli et embêter les étudiants. Ce premier point n'est pas un intérêt des stages mais une conséquence des intérêts des stages.1- Certaines formations exigent des stages. En gros, ca sert à avoir son diplome/ses UV...
Répondre avec citation
Partager