Mais l'envie de jouer avec des pilotes est malgré tout assez forte :p
En fait, sans surprise, je me reconnais beaucoup de mon parcours de développeur dans tes propos, et effectivement, avoir un bon prétexte pour étudier une certaine partie d'une technologie, est généralement le meilleur moyen de s'y mettre, tant au niveau de la motivation que du support de travail.
Quant à la maintenance, le code à déjà au moins 2 ans, mais cumule à la fois les défauts de jeunesse et une dette technique impressionnante.
Pourtant, deux ans, ce n'est pas grand chose. :)
Faire du vrai nettoyage, voire du refactoring, et même in fine un plan de transition douce d'une techno à l'autre sans interruption de service sont des projets extrêmement intéressants en eux-mêmes, surtout avec des outils comme Git (une fois qu'on le maîtrise bien). À condition d'arriver à le faire admettre, comme on en parlait ailleurs. C'est toujours pénible quand on a un chef qui nous dit qu'on a pas le temps de tout ré-écrire quand on est face à une bouse infâme et qui donne ensuite l'ordre exact inverse une fois qu'on a fini d'appréhender la chose.
Enfin, on m'a un peu expliquer les antécédents donc je peux comprendre, mais je n'ai pas trop envie de travailler avec un code aussi inutilement complexe, sachant qu'en plus je vais être le seul à intervenir dessus, théoriquement.
Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter. C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.
Je le dis d'expérience parce que pour avoir travaillé sur un gros projet interne à une compagnie, il m'a fallu beaucoup de temps pour m'approprier la chose et une fois cela fait, je n'avais plus le temps de documenter mes propres contributions. Pourtant, le leader initial du projet a eu le bon goût (parce qu'on lui a demandé) d'écrire un gros document dans un traitement de texte (écrit comme un livre, donc) pour présenter la chose. C'était bien, mais c'était assez rébarbatif à lire, c'était un cours presque déjà obsolète étant donné la rapidité des cycles de développement, et surtout : ce n'était de fait pas un « manuel », quelque chose qu'on pourrait directement ouvrir à la bonne page quand on travaille sur un point particulier du projet.
[^] # Re: Pour quelles applications ?
Posté par Obsidian . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 3.
En fait, sans surprise, je me reconnais beaucoup de mon parcours de développeur dans tes propos, et effectivement, avoir un bon prétexte pour étudier une certaine partie d'une technologie, est généralement le meilleur moyen de s'y mettre, tant au niveau de la motivation que du support de travail.
Pourtant, deux ans, ce n'est pas grand chose. :)
Faire du vrai nettoyage, voire du refactoring, et même in fine un plan de transition douce d'une techno à l'autre sans interruption de service sont des projets extrêmement intéressants en eux-mêmes, surtout avec des outils comme Git (une fois qu'on le maîtrise bien). À condition d'arriver à le faire admettre, comme on en parlait ailleurs. C'est toujours pénible quand on a un chef qui nous dit qu'on a pas le temps de tout ré-écrire quand on est face à une bouse infâme et qui donne ensuite l'ordre exact inverse une fois qu'on a fini d'appréhender la chose.
Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter. C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.
Je le dis d'expérience parce que pour avoir travaillé sur un gros projet interne à une compagnie, il m'a fallu beaucoup de temps pour m'approprier la chose et une fois cela fait, je n'avais plus le temps de documenter mes propres contributions. Pourtant, le leader initial du projet a eu le bon goût (parce qu'on lui a demandé) d'écrire un gros document dans un traitement de texte (écrit comme un livre, donc) pour présenter la chose. C'était bien, mais c'était assez rébarbatif à lire, c'était un cours presque déjà obsolète étant donné la rapidité des cycles de développement, et surtout : ce n'était de fait pas un « manuel », quelque chose qu'on pourrait directement ouvrir à la bonne page quand on travaille sur un point particulier du projet.