J'entends bien que former les gens à apprendre c'est le plus important, cependant il faut bien se baser sur quelque chose, sinon cela ne reste que théorique et donc au final, ce n'est pas très intéressant.
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 :
J'entends bien que former les gens à apprendre c'est le plus important, cependant il faut bien se baser sur quelque chose, sinon cela ne reste que théorique et donc au final, ce n'est pas très intéressant.
L'apprentissage par l'exemple est certes très intéressant et très formateur. Ce que je voulais dire dans mon message précédent, c'est que se fixer sur une technologie et apprendre uniquement celle ci ne sert à rien.Envoyé par LordMacharius
L'homme est un fou pour l'homme. Toi qui viens de me mettre unaie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.
Parmi toutes ces réponses sur un sujet fort intéressant, je souhaiterai rajouter une petite chose.
Autant c'est bien connu, les études d'informatique sont en général trop théoriques pour que l'élève soit directement opérationnel à l'entrée sur le marché.
Cependant il ne faut pas oublier que les lacunes viennent également de l'autre côté : les entreprises.
Dans bon nombre d'entre-elles on code à l'arrache pour hier avec comme principal souci la productivité plutôt que le code propre et bien pensé, en ignorant ou en utilisant de travers les outils "théoriques" connus. Certes pour une entreprise la productivité est non négligeable, mais passer du temps sur l'analyse et la conception, le modèle de données, des cycles de développement bien appliqués et un cahier des charges complet et respecté à la lettre n'est jamais du temps perdu. Sauf que ça ne se remarque qu'à plus long terme.
Donc dans l'hypothèse où une entreprise exploite au mieux le modèle de l'ingénierie informatique, non les théories et outils liés indirectement au codage qu'on apprend à l'école est loin d'être inutile.
La conception, comme le dit Hellwing ça fait ses preuves sur le long terme. Je perds un temps fous à repasser sur des applis codées il y a 15 ans parce qu'elles sont tellement bordéliques que je ne m'y retrouve pas.
Alors qu'avec une doc, un plan du bouzin tout serait beaucoup plus simple et fait plus vite ...
L'homme est un fou pour l'homme. Toi qui viens de me mettre un
Je suis d'accord. Quand je vois que certains critiques l'aspect modélisation et cahier des charges qu'on matraque pendant les études. Je n'ai qu'une question à leur poser.Donc dans l'hypothèse où une entreprise exploite au mieux le modèle de l'ingénierie informatique, non les théories et outils liés indirectement au codage qu'on apprend à l'école est loin d'être inutile.
Comment ferez-vous pour debugger (ou migrer sur une nouvelle techno) un programme dans 5 ans dont plus personne ne souvient ce qu'il est sensé faire ?
Bah ... ON redéveloppe tout. Perte de temps, donc d'argent.
L'homme est un fou pour l'homme. Toi qui viens de me mettre un
Attention j'ai pas dis que c'était inutileJuste que (dans mon cas en tout cas) les répartitions avait été mal faites en terme de temps d'enseignement.
Perso comme le temps de conception / documentation n'est pas compris dans le temps de chiffrage des projets , j'ai arrêter de donner de mon temps perso. Bon courage à celui qui prendra la suiteComment ferez-vous pour debugger (ou migrer sur une nouvelle techno) un programme dans 5 ans dont plus personne ne souvient ce qu'il est sensé faire ?
Je ne l'ai pas critiqué. Juste, je dis que l'important, c'est d'apprendre aux gens à relativiser. Une spec, ça n'est pas la Bible, et si quelqu'un y trouve une erreur, c'est de son devoir de corriger(ou de demander la correction si il n'a pas la main sur la spec).
Mon expérience, c'est qu'aucun plan de bataille ne survit au premier contact avec l'ennemi. Aucune spec ne correspond au produit final. Pourtant, avoir fait une spec fait gagner bien du temps. Simplement, il n'existe pas de spec complétement à égalité avec le programme.
C'est une bonne partie de mon métier. Avec parfois, 10, 20 voire 36 ans d'âge sur le code refondu. C'est compliqué, couteux, mais ça se fait. Y compris quand le code est, euh, non optimisé pour la lecture...(euphémisme). La méthode? Ben, se servir de son cerveau. Il n'y a pas de méthode qui marche à coup sur, on est obligé de s'adapter. Souviron parlait de créativité, c'est typiquement un domaine ou il en faut. Et il faut savoir tester, aussi. A fond.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Oui... M'enfin en grande partie. Sur mes 2 ans et demi d'XP , j'ai effectué 5 missions. Une seule d'entre elles portait sur une application à développer from scractch à partir de zéro. Les 4 autres c'était de la maintenance. Perso je n'ai pas de problème parce que par définition un logiciel n'est pas fini. il y aura tôt ou tard :
- une petite fonctionnalité qui manque, qu'on n'aurait pas pris en compte dès le départ et qu'il faudra ajouter : il s'agit d'une maintenance évolutive.
- Des bugs qui ont échappé lors des phases de test du logiciel et qu'on a détectés grâce à l'un des cas d'utilisation un peu tordue d'un utilisateur ou tout simplement que la montée en charge du logiciel a entraîné de gros problème de performance : il s'agit d'une maintenance corrective.
Perso, je n'ai aucun problème à effectuer l'un ou l'autre des 2 types de maintenance (bien que je préfère une évolution qu'une correction de bugs). Je considère cela comme un challenge à relever et après tout on saura comment c'est fait ailleurs. Si c'est mal fait on prend note pour ne pas faire la même bêtise que les développeurs qui ont développé la première version du logiciel. Si c'est bien fait alors alors tant mieux il y aura moins de stress et avec un peu de chance on aura découvert comment une architecture qu'on ne maîtrisait pas a été mise en place et du coup on se met à jour au niveau connaissance.
Le problème n'est pas le fait qu'on fasse beaucoup de maintenance. Pour moi le véritable problème c'est la qualité de certaines applications. Sur les 4 applications pour lesquelles j'ai fait la maintenance un seul respectait une architecture bien définie avec une très bonne documentation technique. Le reste c'était du n'importe quoi et il fallait de la gymnastique partout dans le code pour pouvoir ajouter la nouvelle fonctionnalité demandée. Le truc le plus gênant ce sont les effets de bords qui me font perdre un temps énorme parce que tout simplement t'as modifié un truc et un autre truc qui marchait avant ne marche plus.
Bref je ne regrette pas du tout d'avoir commencé par la maintenance parce j'apprend plein de chose comme ça et cela évite que je fasse les bêtises que j'ai rencontrées dans une nouvelle application.
Je connais pas trop l'enseignement en France, mais apparemement dans les écoles, les élèves sont préparés à être chef de projet. Donc à un seul métier.
Ce serait intéressant d'avoir un projet de ce type. Dans ce cas, je préfère plutôt que le projet parte d'une application sans architecture codée par le professeur lui-même en y insérant tous les anti-patterns connus. Après dire aux étudiants de les détecter et de les corriger. Voilà c'est ça la réalité sur le terrain. La plupart des applications mal faites sont sûrement codées par des débutants. Connaitre les bonnes pratiques en partant d'une application pourrie est une bonne idée
Dernière modification par Invité ; 24/04/2012 à 16h58.
Apprendre à coder, c'est bien
Apprendre les "concepts" de la maintenance aussi...
Maintenant, qu'en tu regardes les offres d'emplois (en tout cas sur Toulouse), généralement, le langage de programmation est spécifié... et je pense que si tu
envoies ton CV en disant, je m'en fiche du langage mais prenez moi car je "sais" développer, tu risques d'avoir des refus assez rapides et nets...
Après, les technologies évoluent, mais on ne fait pas changer de langage de programmation à un développeur tous les ans... entre le temps de formation, le temps de la maitrise du langage, etc... ce n'est pas rentable...
D'ailleurs, regarder, dans le domaine de l'embarqué, on fait encore massivement du C, C++ (idem dans le jeu) alors que Java et .Net existe depuis bien longtemps maintenant... (ok, pas de débat sur les performances de ces langages)...
Les geeks développeurs apprennent tous les langages bien souvent... mais au final, se "focaliser" sur un langage permet aussi de maitriser parfaitement celui ci et TOUS les concepts sous-jacents...
Après, dans les écoles, il faut bien faire un choix.. je regrette juste que dans les universités, on privilégie massivement C++ et Linux que la plateforme Windows (à cause du coup de la licence de l'OS d'une part et puis le coté anti-microsoft qui perdure dans ce milieu (même si tout le monde n'est
pas réticent aux produits de dev gratuit de microsoft)...
The Monz, Toulouse
Expertise dans la logistique et le développement pour
plateforme .Net (Windows, Windows CE, Android)
En fonction des formations ?
Étant actuellement en deuxième a
En fonction des formations ?
Étant actuellement en deuxième année de BTS Informatique de Gestion (maintenant SIO) je peux affirmer que notre classe est consciente de cela, la majorité de nos stage de cette année était de la maintenance ou de la reprise d'applications lourdes existantes. Pour le reste il s'agissait de création d'application orientée web pour assurer une présence sur internet (vitrine ou service). Nos professeurs nous le dissent, il faut reprendre les applications lourdes développée a l'époque ou développeur était moins un métier a part entière qu'aujourd'hui ou que tout simplement les contraintes et les technos ont évoluée. Il est vrai que que notre formation est plus proche du milieu du travail que va pouvoir l’être un cursus plus classique en université par exemple. Je pense plus qu'il s'agit d'une question de cursus et/ou d'expériences personnelles.
La maintenabilité est purement subjective dans beaucoup cas car elle dépend avant tout du niveau moyen des intervenants présents et futurs.
Si nous résumons la maintenabilité à ceci:
1) "Facile" à faire évoluer
2) "Facile" à modifier
3) "Facile" à corriger
Et que l'on essaye de les appliquer sur un projet de grande taille (minimum 500k de lignes de code). Il est impossible d'appliquer les meilleures techniques pour avoir 1, 2, 3 si le niveau moyen est bas. La facilité est subjective. Dans la bouche de beaucoup de "managers", maintenable signifie surtout "peut être compris par n'importe qui".
L'argument ne tient que si l'on parle de chefs de projets dans le cadre de projets ponctuels : emballez, c'est livré! Ce n'est à mon avis pas la majorité des cas et la composante maintenance/bugfix/évolutions fait partie intégrante de la gestion de projet. A vrai dire c'est la gestion de projet qui m'a en quelque sorte éveillé à la problématique de la maintenabilité.
Jérôme, pourrais-tu détailler de quelle façon les problématiques liées à la maintenance sont abordées dans ta formation? Vous enseigne-t-on des méthodologies ou pratiques particulières, etc?
Je trouve que le mot "maintenance" est plutôt mal choisi car il inclut l'éventualité d'une "panne" ou l'incapacité du logiciel à être autonome dans la gestion de ses données. Pour moi un logiciel qui a besoin de "maintenance" est en version Beta.
Je préfère le mot "évolution" ou "correction". Il est effectivement très difficile de faire évoluer un logiciel dont on n'est pas le créateur d'autant plus si il est mal ou pas commenté et documenté. J'ai refusé plusieurs fois ce genre de demande.
J'ajoute que corriger ou améliorer de vieilles applications "lourdes" c'est maintenir des sociétés dans les technologies du passé. Ceci aboutira tôt ou tard à des problèmes de sécurité et d'interopérabilité.
Dans la majorité des cas et si c'est possible financièrement il vaut mieux proposer un nouveau logiciel qu'en maintenir un vieux. Je vais même plus loin en disant que la vie d'un logiciel ne doit pas dépasser 5 ans.
Bonjour,
Personellement, je ne trouve pas qu'ont soient bien formés aux problèmes de maintenance logiciel.
J'ai eu la chance de pouvoir effectuer un stage chez un éditeur de logiciel pendant mon BTS et c'est à ce moment que j'ai vraiment découvert la difficulté et les techniques nécessaires pour arriver à nos fins...
Je dirais plutôt qu'en BTS, on se focalise plus sur la modelisation et conception que sur la programmation elle même car d'après nos profs, cela n'a plus d'avenir.
A terme on utilisera soit disant des AGL, beurk !
Je pense aussi que la formation est rarement portée sur la maintenance, on nous apprend à faire du code propre et facile à maintenir (enfin, en théorie), mais on ne nous apprend pas à corriger un code mal conçu, ce qui en fait représente une grosse partie du métier (les raisons ont déjà été cités inutile de paraphraser), on se retrouve souvent à devoir corriger ou modifier le code d'une tierce personne, et ça il faut l'apprendre sur le terrain parce qu'on ne nous y prépare pas
Les cas sont de toute manière trop multiples et trop spécifique pour y être totalement préparé, mais des exercices de "décryptage" de code ne seraient pas de trop, mettre l'élève face à une partie d'un programme (et pas juste 20 lignes, il faut qu'il cherche l’aiguille dans la botte de foin), et lui dire "voilà, le bug c'est ça, ça survient quand je fais ça (et là on est gentils, en cas réel certains utilisateurs décrivent moins que ça....), tu me trouve l'endroit exact où ça foire, et tu proposes 2 solutions, une rapide pour l'urgence, et une permettant d'éviter que ce genre de bug se reproduise".
Mettre face à un cas révoltant (code mal conçu, pas commenté, pas documenté, application qui fait la tartine et le café alors qu'on lui demande beaucoup moins) est le meilleur moyen de faire comprendre l'intérêt des bonnes pratique de développement, et que l'élève se pose les bonnes questions, car on nous dit "il faut toujours bien réfléchir et analyser avant de dev etc..." mais au final, tant qu'on ne voit pas sur quoi ça peut déboucher, on se dit que c'est juste pour faire plus sérieux, alors que non C'EST important de prendre le temps, de commenter, de documenter, de réfléchir avant de se lancer, etc...
De toute manière, on a tous déjà dû faire quelque chose en vitesse et pas le faire au mieux, si ce n'est pas le cas vous avez bien de la chance, mais si vous avez des gens au dessus de vous qui veulent quelque chose, à un moment ou à un autre vous serez amené à faire un truc en vitesse dans l'urgence, et quand on est pas forcément assez expérimenté ça aboutit souvent sur de la casse, et au mieux ça tiendra jusqu'à une demande d'évolution ou il faudra tout refaire, on n'y échappera pas, parfois c'est justifié, parfois c'est juste parce que les entreprises ne pigent pas qu'une appli doit être réfléchi et que ça fait parti du temps de dev.
Avant de parler de "Facile", si on commençait par définir la maintenabilité par
1) être capable de faire évoluer sans forcément tout réécrire de 0
2) être capable de modifier sans tout casser et sans créer 50 bugs sur des fonctions qui n'auraient pas dû être touchées
3) savoir corriger, et donc savoir trouver le problème
Le mot maintenance regroupe des notions très larges, cela peut être une réinitialisation périodique d'une configuration ou une purge des fichiers log, par exemple, ce qui n'a rien à voir avec des bugs, mais ça peut-être aussi les corrections des bugs, ou l'ajout de fonctionnalités. Evolution et Correction sont de la maintenance.
La maintenance concerne toute intervention sur une version dite Release, installée c'est l'utilisateur. Si les versions Beta sont clairement identifiées comme non totalement testées et donc pouvant potentiellement comporter des bugs importants, les versions Release ne sont pas exempte de bugs non plus. Le zéro défaut n'existe pas et n'existera jamais.
Une correction, ou une évolution ponctuelle coutera toujours moins cher que la reprise totale du logiciel, même si le cumul sur l'année peut largement dépassé le cout d'un nouveau logiciel. Si les financiers sont sensibles aux cumul des couts, etc, au moment de sortir de carnet de chèque, c'est toujours le cout immédiat qu'ils regardent. C'est pour cela que l'on maintient les logiciels plus facilement que de nouveaux développements.Tu n'as pas dû faire beaucoup de maintenance dans ta vie alors. Et ne va pas dans le domaine de la finance, on y trouve encore très facilement des logiciels qui ont plus de 30 ans, en cobol notamment.
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
Ben voyons
Quand une société a une "vieille" appli qui marche, débuggée depuis X années, et qui fait ce qu'elle doit faire, le fait de changer pour soi-disant la mettre au goût du jour est une aberration technique : non seulement on n'est pas certain de reproduire la même chose (on est même quasi-certain du contraire), mais on est certain d'ntroduire des bugs qui mettront des années à être identifiés/corrigés, pour un gain la plupart du temps négligeable au vu des risques et du temps (et donc du coût), tout ça parce que le nouveau dev qui s'en occupe a la flemme de comprendre ce qui se faisait... ou d'utiliser un langage qu'il ne juge plus "à la mode"...
Un excellent blog :
Rewrite considered harmful ?
Et on peut aouter : "condemning yourself to a life of debug.. and misery from your clients"If you have a very successful application, don't look at all that old, messy code as being "stale". Look at it as a living organism that can perhaps be healed, and can evolve. You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it
"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
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