Un bon développeur est un développeur flemmard !

Bonjour,

En lisant le billet de autran sur la reprise de code.. Il me semble nécessaire de faire un point sur ce sujet. En effet, selon moi, certains points important ne sont pas couvert ! Ce qui résulte en une vision optimise, (pour ne pas dire naïve de la reprise de code.) En effet, la plus part du temps, les reprises "douloureuses" le sont pour des raisons externes au code ou au développeur d'origine.

Pourquoi le code change de main ?
En premier lieu, il y a la raison qui fait que ce code change de main. Que cela soit par ce que le développeur d'origine n'est plus présent. Cela est variable mais les plus classique sont celles-ci : Sur-charge, congé, plus dans l'entreprise... Dans tout ce cas, il est rare d'avoir la possibilité d'aller poser une question à cette personne directement.

Pourquoi le code a besoin d'être repris ?
Puis, il ne faut pas oublié la raison qui pousse la "reprise" développement non fini ? Évolution se basant sur ce code ? Cela peut-être aussi la réécriture d'un bug fix. Celui-ci tout le monde sait qu'il n'est pas propre et qu'il faut le ré-développer, mais tu ne trouvera aucune documentation technique ou fonctionnel dessus.
Mais si tu ne reprends pas un bug fix... C'est que tu écris un bug fix. Avec un peu de chance, le problème a été détecté en production et la correction est vital, ultra prioritaire. Et donc le responsable qui va venir te voir toutes les heures pour avoir des nouvelles.

L'investissement nécessaire !

Il n'est pas rare qu'une reprise de code, soit sur un domaine métier que le nouveau développeur ne maitrise pas ou une partie de l'application qu'il n'a pas l'habitude de gérer. Et là avant de pouvoir écrire la moindre ligne de code, il va falloir comprendre ce que fait le code... Comment ? Pourquoi ? Mais, il faut aussi comprendre le métier Cela demande un investissement et probablement dans un domaine moins familier que d'habitude.

En suite, il vient la partie "réécriture", quelque soit le responsable, si celui-ci entends ce mot, il sait que cela n'est pas bon signe. Car, cela est synonyme de délai, surcout et risque.

Le contexte !

S’il n’y a pas de documentation, le code sera de lui-même élu au rang de travail non professionnel. Aucun chef de projet ne pourra alors reprocher à son développeur de vouloir réécrire un code réputé peu sérieux.

Pour avoir fait un certain nombre d'entreprise. Je peux te dire que la documentation sérieuse et à jour, c'est ultra rare. En particulier, pour les projets déjà en production depuis un petit moment. Et si elle existe, il faut encore la retrouver !
Or lorsqu'un projet est en production chez un client, si celui-ci en a fait une recette et que la documentation n'existe "plus". Le comportement de cette production devient par défaut le comportement nominal. Et donc, si le traitement d'un petit bug vient remettre en question une partie de l'implémentation/comportement de l'application. Même si celui-ci est faux, il est très compliqué d'aller voir le client et lui expliquer cela. Et même si le client est consulté par rapport au problème. Il est totalement possible que sa réponse soit :

Envoyé par Le client qui connait le bug depuis 10ans

Oui, on le sait depuis un moment. Ne le corrigez pas, on a un traitement qui corrige les données par ailleurs.
Ou
On utilise ce comportement pour traiter des cas spécifique.

Et je ne vous parle même pas du cas dû à la déclaration d'un bug qui est une évolution fonctionnelle non identifiée.

Donc les vrais difficultés dans la reprise de code sont :

• La raison du changement de développeur.
• La raison de la "reprise"
• L'investissement technique et fonctionnel nécessaire pour la reprise.
• Le contexte de la reprise.

Même, si il y a potentiellement des facteurs supplémentaires :

• Non respect des normes.
• Code trop complexe dû à une mauvaise implémentation
• Manque de commentaire

Conclusion :
Pour finir, il y a un dernier détail qui tue. C'est la question qui va être nécessairement posé sur le développement/code du développeur d'origine. Cette question est bien plus politique qu'autre chose... Et je n'y vois que trois réponses possibles :

• Mettre en cause l'organisation (Attention si c'est un responsable qui pose la question #Suicide)
• Mettre en cause le développeur d'origine. (Bizarrement la plus fréquente quand celui-ci n'est plus là.)
• Mettre en cause un élément externe (Là, il faut l'argumentaire qui va bien)
• Esquiver la question

Cordialement,
Patrick Kolodziejczyk