Ca dépend du niveau de la formation.
Au départ il faut déjà former les élèves à un langage, qu'ils sachent déjà coder des tests et des petits programmes de bidouille avant d'apprendre des méthodes d'organisation de dev d'application.
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 :
Ca dépend du niveau de la formation.
Au départ il faut déjà former les élèves à un langage, qu'ils sachent déjà coder des tests et des petits programmes de bidouille avant d'apprendre des méthodes d'organisation de dev d'application.
google is your friend
Tu ne parles que de rigueur dans la programmation ?Envoyé par bob25
Mais ne t'es tu jamais dit que la rigueur en programmation/développement, provient aussi de la rigueur en français, en math, en fait dans toutes disciplines enseignées et dès ton plus jeune age. La rigueur en sport est aussi formatrice si tu pratiques un entrainement régulier. C'est une erreur de croire qu'être rigoureux ce n'est valable que pour un domaine particulier. Donc, de manière général, la rigueur s'enseigne dès le plus jeune age à l'école.
C'est aussi une erreur de penser qu'il faut apprendre un langage AVANT d'apprendre à développer. En théorie il faudrait apprendre à penser un programme avant d'apprendre à l'implémenter. Cependant en pratique, c'est chose à peu près impossible. L'apprentissage du premier langage doit être accompagné par les premiers pas en méthodologie, sinon c'est souvent terrible au niveau des réflexes acquis (programmer... puis penser après -_-)
Ça me rappelle l'enfer que j'ai connu en travaillant et en étant évalué "en équipe" sur un projet avec des personnages sans aucune rigueur. Pour ne pas perdre mon job, il fallait que je refasse le code de certains de mes coquipiers qui se vantaient de programmer à la vitesse de l'éclair.
C'est vrai qu'ils faisaient ça plus rapidement que moi. Ils étaient devant leur clavier et "pitonnaient" gaiement pendant que je faisais du pseudo-code ou des plans d'entrée/sortie. Mais ce que je produisais fonctionnait toujours selon les spécifications et ne contenait pas de bogues, tout le contraire de leur produit à eux. Et je devais me tapper leur travail par la suite...
Bon, c'est intéressant tout ça, mais on se perd toujours autant dans ce vieux débat
Pour apporter ma réflexion du jour : je suis pro (je gagne ma vie en développant et en concevant, et je commence même à "manager"). Bon, je n'ai pas toujours besoin de réfléchir à ce que je fais pour le faire. Quand je sens que je ne suis pas sur, je prends un feuille ou un tableau blanc et je pose le problème. Je fais des diagrammes dans ma "manière de réfléchir" (plus rapide), puis je les traduit dans un UML-like pour le faire comprendre aux autres (communication).
Mais, ce n'est pas tout.
J'aime bien "bidouiller" (tenter des trucs, résoudre un problème en trouvant moi-même la solution à force de tâtonnement, passer des heures sur un algo à la con jusqu'à trouver LA solution qui m'aurait permis d'obtenir les félicitations de mon vieux prof d'algo barbu). Et puis, dans certains cas où tu ne sais pas où tu mets les pieds, tu es bien obligé. Encore que je m'appuies toujours sur une "méthode itérative" (quelque chose qu'on apprend en seconde mais dont l'industrie ne connait pas les grands bénéfices, mais bref, passons).
Bah oui, mais je suis aussi un gros fainéant.
Pourquoi me taper des heures à faire quelque chose que quelqu'un a déjà fait un jour quelque part dans le monde? voire que j'aurai déjà fait moi-même. La vie est trop courte, désolé...
Un de mes collègues (ça balance) qui apparaît plutôt "bon", disons capable de réflexion sur l'informatique en général, capable de sortir des discours sur la méthode de conception et de programmation, bon "bidouilleur", mais il ne sait pas ré-utiliser. C'est dingue. Il a la solution sous les yeux, pour moi c'est réglé en 3-coups-de-cuillères-à-pot-allez-hop-café, mais non. "Bidouiller" (rechercher la solution par lui même) c'est sa passion.
Et c'est dommage car c'est anti-productif (et dans l'informatique industrielle, c'est fatal)
C'est là où ça pose un problème : Dans un monde "pro" (la plus grande activité aujourd'hui doit être justement l'informatique industrielle, à vérifier, je parle de ce que je connais bien), on n'a pas le temps de continuer ses études. Dikjtra (orthographe catastrophique), c'était avant qu'il fallait le découvrir. Maintenant, c'est go-go-go.
Bref, selon la branche et les objectifs de la boite pour laquelle on bosse, il faut être pro(ductif). Or passer du temps à bidouiller n'est pas pro(ductif).
Mais dans un autre contexte, en bidouillant, avec une bonne étoile, on peut toujours s'en sortir et même gagner le jackpot.
Mais bon, au final, ça reste un peu un mythe tout ça...
Un Pro, fait un plan, des diagrammes pour éclaircir sa pensée et quelque protorypes pour évaluer la faisabilité de choses dont il ne maîtrise pas tout à fait les notions et effectue une liste de tests unitaires pour vérifier la solidité de ses interfaces et de ses méthodes.
Un bidouilleur commence par un prototype sans avoir fait de plan et sans pensée parfaitement logique. Se décourage au bout de la moitié du projet ou termine un programme avec plein de bugs parce qu'il n'a pas été testé.
Et ben je suis un bidouilleur plus qu'un pro. pourtant j'ai eu droit un article dasn le magazine netbeans sur mon projet, et j'ai trouvé un boulot grace a ce projet.Un Pro, fait un plan, des diagrammes pour éclaircir sa pensée et quelque protorypes pour évaluer la faisabilité de choses dont il ne maîtrise pas tout à fait les notions et effectue une liste de tests unitaires pour vérifier la solidité de ses interfaces et de ses méthodes.
Un bidouilleur commence par un prototype sans avoir fait de plan et sans pensée parfaitement logique. Se décourage au bout de la moitié du projet ou termine un programme avec plein de bugs parce qu'il n'a pas été testé.
Pour l'environnement PRO, je vous dit ca dans 3semaines quant j'aurai vraiment commencé le boulot.
Systèmes d'Informations Géographiques
- Projets : Unlicense.science - Apache.SIS
Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons
Vos messages sont intéressants mais n'ont très peu de valeur car vous ne parlez ni du langage utilisé, ni des méthodes de travail, ni des conditions de travail, ni de type de projet, de sa durée et de son encadrement (bon chef de projet, réunion sans fin, budget illimité...)
Ensuite, on parle de quoi? de la phase d'installation, de sélection des outils ou on démarre quand le workspace est en place ? Car je sais pas pour vous mais moi rien que d'installer tous les outils de dev, avec les bonnes versions, et la bonne configuration du soft, ca prend déjà pas mal de temps et ça oblige à devoir bidouiller
J'ai 2 exemples simples de programmeurs que j'ai rencontré durant ma petite vie :
- exemple 1 : langage : java, style de boite : pme 200 salariés, moyenne d'age 25 ans, méthode de travail : aucune, conditions de travail : avoir très vite des résultats, cible : interne, cadre : outil de gestion,
mentalité : je code, re-code tout moi en utilisant le minimum vital en outil externe, chef de projet : aucun, équipe : développeur seul, aucune date de fin de projet
=> résultat : travail sans commentaires, passe son temps à recoder l'existant, travail au jour le jour sans documentation, sans spécification écrite, sans diagramme, maîtrise bien le langage
- exemple 2 : langage : java, méthode de travail : on fait de la qualité (spé, analyse, définition des rôles...) , style de boite : ssii, conditions de travail : travail au forfait pour gros client, cible : employés non informaticien, cadre : outil de gestion, mentalité : on se forme, on utilise max d'outils existant qui simplifie et aide au dev, on s'entraide et on avance ensemble, chef de projet : oui, équipe : 5 dev, 1 archi, 1 cdf (3 analystes), date de fin de projet : oui
=> résultat : le projet n'est pas encore entré dans la phase de dev, l'analyse se termine, le projet correspond à la théorie et aux méthodes de conception enseignées par les prof
Entre ces 2 exemples, il y a un creux énormes alors que des 2 côtés ce sont des personnes qui ont de l'expérience sur plusieurs projets.
Pour revenir sur la question du début, pour moi la différence entre bidouilleur et pro, ne se situe pas vraiment au niveau du code mais plus sur les conditions de travail et sur le type de projet. Quand un client demande de la merde, on lui fait de la merde et s'il est satisfait, tant mieux c'était le but.
et par rapport à la qualité pure du développement, utiliser des outils d'aide au développement c'est pas nécessaire, c'est juste obligatoire, la programmation c'est pas un art nouveau, il y a quand même plusieurs années que des personnes tout aussi intelligente que vous ont travaillé sur des projets et en ont tiré des outils pour aider les suivants à travailler mieux, alors faut pas s'en priver.
Dans un monde parfait, un développeur commencerait pas créer son langage, puis à coder son compilateur, puis il coderait des logiciels pour des clients, et il serait riche et surtout célébre. Mais ce monde n'existe pas pour 2 raisons : le temps et le temps !
Le temps (1) car il faudrait 5 vies pour penser, coder et débugger tout ca
Le temps (2) car il y en a d'autres qui sont passés avant vous et c'est quand même mieux de vivre avec son temps que dans un temps qui ne corrspond qu'au passé.
Non certainement pas.
Dans un monde parfait, on aurait un langage unifié et facile à utiliser.
Actuellement, dans un monde parfait, on se soucie le moins possible du langage lorsqu'on commence le projet et on ne travaille certainement pas seul pour des raisons qualités. Tu ne dirais certainement pas que dans un monde parfait le mécanicien fonderait sa propre clé à molette ? Pourquoi veux tu que le développeur s'attache à un élément aussi non pertinent pour son projet que de créer l'outil ? Ce n'est certainement pas un cas parfait s'il a besoin de faire ça, et encore moins s'il doit le faire tout seul.
C'est bien sur ça que porte l'essentiel des messages jusqu'ici ? Pourquoi dis tu que les « messages sont intéressants mais n'ont très peu de valeur » ? Finalement tu dis la même chose que la plupart: c'est la méthodologie qui fait la différence.
Car je suis tombé sur des cas où le but était de développer le maximum d'outils maisons (dans le jeu vidéo par exemple ils ne font que ça).Non certainement pas.
Dans un monde parfait, on aurait un langage unifié et facile à utiliser.
Actuellement, dans un monde parfait, on se soucie le moins possible du langage lorsqu'on commence le projet et on ne travaille certainement pas seul pour des raisons qualités. Tu ne dirais certainement pas que dans un monde parfait le mécanicien fonderait sa propre clé à molette ? Pourquoi veux tu que le développeur s'attache à un élément aussi non pertinent pour son projet que de créer l'outil ? Ce n'est certainement pas un cas parfait s'il a besoin de faire ça, et encore moins s'il doit le faire tout seul.
Le point sur lequel je tenais à bien situer c'est qu'on ne travaille pas dans les mêmes conditions selon le projet, le client, bref la struture générale du projet donc de là à définir une différence entre le bidouillage et le travail pro c'est difficile surtout quand on ne donne aucun paramètre.
Un dev peut très bien bidouiller en php (sans utiliser de framework ni MVC) et réaliser un outil correct car la structure de son projet ne lui demandait pas d'utiliser des outils trop lourds.
Et il peut en même temps savoir travailler sur des projets plus gros et plus dur à gérer, ce qui fait de lui un pro peutêtre.
Non je dis en plus que ca dépend du cadre du projetPourquoi dis tu que les « messages sont intéressants mais n'ont très peu de valeur » ? Finalement tu dis la même chose que la plupart: c'est la méthodologie qui fait la différence.
Non il ne font pas que çaMais c'est vrai qu'il en font beaucoup. Les grosses boites ont effectivement tendance à vouloir tout développer à l'interne sans utiliser la technologie externe.
Personne n'a dit que bidouiller n'apporte jamais de bon résultat.Le point sur lequel je tenais à bien situer c'est qu'on ne travaille pas dans les mêmes conditions selon le projet, le client, bref la struture générale du projet donc de là à définir une différence entre le bidouillage et le travail pro c'est difficile surtout quand on ne donne aucun paramètre.
Un dev peut très bien bidouiller en php (sans utiliser de framework ni MVC) et réaliser un outil correct car la structure de son projet ne lui demandait pas d'utiliser des outils trop lourds.
C'est ce qu'on dit: sur un projet encadré, dans une méthodologie contrôlée tu travailles dans un cadre professionnel, même si c'est chez toi. Quand tu n'as pas de méthodologie, quand il n'y a finalement pas de cadre au projet tu bidouilles. Personne (enfin dans les réponses sérieuses) n'a voulu définir la personne derrière le développeur de manière absolue, mais uniquement le travail effectué par la personne.Et il peut en même temps savoir travailler sur des projets plus gros et plus dur à gérer, ce qui fait de lui un pro peutêtre. [...] Non je dis en plus que ca dépend du cadre du projet
Bonjour à tous.
Dans le cadre du développement de programmes de calcul scientifique (c'est mon domaine et je ne suis pas certain que mon opinion puisse être étendue à d'autres domaines), le bidouilleur est celui qui ne connait que la programmation; le professionnel est celui qui connait aussi à fond les lois qui régissent les phénomènes physiques étudiés et les algorithmes qu'il va utiliser. Lors du test d'un programme, il est indispensable de pouvoir juger de la validité des résultats obtenus.
Dans les questions posées sur nos forums, on voit de nombreux cas où leur auteur sait programmer plus ou moins correctement, mais ignore tout de la réalité physique des phénomènes étudiés. Un exemple particulièrement frappant se rencontre en traitement de signal: nombreux sont ceux qui considèrent que leur signal est une séquence de valeurs discrètes. Or un signal est en réalité une tension (signal électrique, exprimé en volts) ou une pression (signal acoustique, exprimé en pascals). Ce signal est une grandeur physique continue que l'on peut artificiellement échantillonner pour le traiter numériquement.
Jean-Marc Blanc
Calcul numérique de processus industriels
Formation, conseil, développement
Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer. (Guillaume le Taiseux)
Je ne pense pas que l'on puisse assimiler le terme de "pro" à des connaissances dans d'autres domaines quand il s'agit de programation. En effet, le programmeur professionel, ou développeur professionel, n'a pas besoin de toutes les connaissances sur le sujet qu'il traite; les conseillers sont là pour lui fournir les calculs et les algorithmes. Son rôle, au développeur, se limite à produire une application stable et bien structurés selon les spécifications des experts dans le domaine approprié.
Par contre, il doit posséder des connaissances approfondies sur les méthodes de développement et sur le langage qu'il utilise. Sans ça, il ne peut en résulter que tâtonnements et erreurs.
Ce que tu dis est vrai parce que tu réduis développeur à programmeur. Mais un développeur n'est pas forcément programmeur. Il peut être concepteur ou analyste. Si en tant que concepteur, il n'a pas non plus le problème sus-cité par FR119492, l'analyste là lui. Un analyste est un lien entre les différents parties prenantes (en anglais stackholder). Il doit donc connaître suffisamment le domaine du problème pour fournir une description de ce dernier. Sans aller jusqu'à l'expertise la plus complète, qui n'est pas en général faisable, il y a nécessité d'apprendre les connaissances du métier un minimum. Sinon il ne peut être le « pont » entre les experts et les concepteurs. C'est peut être ce que tu as appelé des conseillers. Mais dans ce cas, ce sont aussi des développeurs. Inversement, l'analyste n'a pas à connaitre le langage qui servira à développer le système logiciel. Donc tous les développeurs n'ont pas besoin de maîtriser le langage utilisé.
Salut à vous !
En théorie, tu as raison, mais en pratique, ça me marche pas si les "experts" ne connaissent rien à l'informatique et le programmeur rien au "domaine approprié": ils ne se comprendront pas s'ils n'ont pas un vocabulaire commun. En outre, ma longue expérience industriels m'a appris que les cahiers des charges sont toujours incomplets et souvent contradictoires. Alors, ça va tellement mieux quand une seule personne supervise le développement d'un bout à l'autre de la chaîne, sans intermédiaires.selon les spécifications des experts dans le domaine approprié
Jean-Marc Blanc
Calcul numérique de processus industriels
Formation, conseil, développement
Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer. (Guillaume le Taiseux)
On a besoin de 200 mots pour être capable de dire et expliquer absolument n'importe quoi, parait-il.
Ah oui mais non. Ça ça a énormément changé. Les outils et les méthodes pour produire des documents de besoins adaptés, pour le suivit, pour la gestion de configuration, pour la validation des besoins etc. ont évolué en 10 ans. Pour preuve, les enseignements universitaires ont changé et pas à peu près. Il était temps certes, mais l'informatique étant jeune, il a fallu passé par une période d'expérimentation en industrie. Maintenant, les industriels apprécient et reconnaissent de plus en plus la pertinence des enseignements. D'un point de vue local, quand je parle d'industriels, je parle d'IBM, de CGI, d'Hydro Québec , de France Telecom par exemple avec qui nous avons des liens et des partenariats. En général, il existe des cours de gestions d'équipe dans les programmes d'informatique et de génie logiciel. Ils ne sont pas forcément obligatoire certes. Mais c'est bien mieux qu'avant. L'informatique n'est plus uniquement vu comme une technique avec une connaissance théorique, mais de plus en plus comme un savoir-faire à la manière des domaines de génie.
je dirais oui mais non
Je suis plutôt pas mal d'accord (et même pratiquement à 100%) avec Jean-Marc.
Certes l'enseignement a évolué, mais, et on le voit au post qui a remonté ce débat, les capacités individuelles restent...
Et le cloisonnement - ou décloisonnement - des "métiers" informatiques n'empêchent ni le langage technique, ni l'introduction de concepts étrangers, ni l'incompréhension globale entre 2 mondes si il n'y a personne ayant un minimum la double compétence...
Ne serait-ce que l'obligation de documentation, à chaque étape se produit une traduction, qui intrinséquement introduit transformation et perte relative d'un certain nombre d'informations...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Encore une fois les méthodologies et les outils sont maintenant mieux adaptés. L'enseignement impose, en GL par exemple, des cours de gestion d'équipes et de projet. Les projets actuels ne peuvent être le fait d'une personne qui fait tout. Je connais de nombreux projets industriels où l'équipe des besoins est clairement distinctes de l'équipe de conception/implémentation qui est distincte de l'équipe qualité... et la communication est excellente.je dirais oui mais non
Je suis plutôt pas mal d'accord (et même pratiquement à 100%) avec Jean-Marc.
Certes l'enseignement a évolué, mais, et on le voit au post qui a remonté ce débat, les capacités individuelles restent...
Et le cloisonnement - ou décloisonnement - des "métiers" informatiques n'empêchent ni le langage technique, ni l'introduction de concepts étrangers, ni l'incompréhension globale entre 2 mondes si il n'y a personne ayant un minimum la double compétence...
Ne serait-ce que l'obligation de documentation, à chaque étape se produit une traduction, qui intrinséquement introduit transformation et perte relative d'un certain nombre d'informations...
Je ne croirais jamais que j'aurais dit ça, mais je pense, que cette fois-ci Souviron, tu as une vision vieillote de l'informatique. Ceci dit sans méchanceté et sans dénigrement bien sûr. Tout ce que tu cites est vrai au niveau des termes et des risques existent, mais la donne s'est considérablement améliorée. L'informatique se rapproche des autres industries et acquiert comme elles l'ont fait des bons outils et des bonnes approches. Certes il y a toujours un lien: l'équipe de direction, le producteur ou autre.
Le fait d'avoir des équipes distinctes qui séparent clairement leurs activités à de bien nombreux avantages en terme qualité, qui compensent largement les difficultés à les faire agir ensemble; du moins de nos jours, vu la taille des systèmes.
Mais tu vois, par exemple a l'heure actuelle, je suis dans une structure "moyenne", pas tres loin de chez toi, avec beaucoup de jeunes, et justement une approche theoriquement comme tu le decris...
Mais dans l'application, et bien que les utilisateurs finaux interviennent tous les jours (un groupe de test est a disposition permanente), il n'empeche que ce que je vois de la traduction (que ce soit par eux-meme puisque la methodologie utilisee les oblige a remplir des "requirements") ou les "SD" (software Design) etc etc.. remplies par les informaticiens ne me semblent pas adaptes et ne parlent pas vraiment de la meme chose...
Et j'entend tous les jours des commentaires du style "bah .. On fait comme ca. Et puis si ca marche pas, il y aura un DR ("Defect Report")".
Et pourtant c'est aujourdhui, dans une entreprise industrielle ISO9002 et bientot CMMI niveau 3, avec 80% de jeunes sortant il y a moins de 6 ans des cours....
voili voila...
C'est tout ce que je voulais dire... Ya pas de miracles...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Oh je ne nie pas que ce n'est toujours pas aussi bien rodé que dans l'industrie autre qu'informatique. Mais ça s'améliore quand même. Compares avec ce que tu as du connaître il y a 15 ans. Je suppose que tu vois du changement.
L'idéal serait une personne expert du domaine, discipliné, bon développeur, objectif, capable de s'auto-géré... avec beaucoup de temps devant soi ^_^
Mais on s'entend que c'est très très utopique ça dans la situation actuelle pour les projets de taille moyenne et grande.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager