Appliquer ce que tu dis à une base de code réelle ca ne marche pas. Sur ta base de code une immense majorité va finir à la poubelle, ne jamais évoluer, ou se faire détruire par un changement de spec fonctionelle, de techno ou je ne sais quoi. Passer du temps à réécrire pour la beauté de la chose c'est à 99% perdre du temps.
Attention ca ne veut absolument pas dire qu'il faut accumuler de la dette technique ou se foutre de la qualité du code bien au contraire. Le but est que quand on livre un fonctionalité, on est globalement satisfait du travail produit, c'est propre documenté, testé. Sauf cas exceptionel il faut alors souvent resister à l'appel de la réécriture qui va enlever autant de bugs qu'en remettre (la couverture de tes tests reste constante) et qui est surement veine.
Ton travail de refactoring tu le fais quand tu as besoin (c'est à dire que tu dois retoucher au code pour d'autres besoins fonctionels ou non fonctionels) et exceptionellement quand c'est vraiment justifier tu le passes en dette technique.
Bref ton code il devrait être raisonablement bon dès que tu livres, sinon tu t'es un peu perdu en chemin. Si tu es dans un hot spot de ton appli tu vas passer ton temps dessus et tu vas l'ameillorer petit à petit mais pas uniquement pour la beauté de la chose à fonctionalité équivalente. Sinon "raisonablement" est souvent largement suffisant. Après si tu t'es vraiment lourder sur un truc, bha c'est de la sâle dette technique.
Il faut s'adapter à la situation, mais resister au mythe de la réécriture qui va resoudre tout les problèmes est aussi important que de savoir identifier et juger les faiblesses de ce qu'on produit.
[^] # Re: Code review
Posté par ckyl . En réponse au journal Du code propre, c'est quoi ?. Évalué à 6.
Tout est toujours question de pragmatisme.
Appliquer ce que tu dis à une base de code réelle ca ne marche pas. Sur ta base de code une immense majorité va finir à la poubelle, ne jamais évoluer, ou se faire détruire par un changement de spec fonctionelle, de techno ou je ne sais quoi. Passer du temps à réécrire pour la beauté de la chose c'est à 99% perdre du temps.
Attention ca ne veut absolument pas dire qu'il faut accumuler de la dette technique ou se foutre de la qualité du code bien au contraire. Le but est que quand on livre un fonctionalité, on est globalement satisfait du travail produit, c'est propre documenté, testé. Sauf cas exceptionel il faut alors souvent resister à l'appel de la réécriture qui va enlever autant de bugs qu'en remettre (la couverture de tes tests reste constante) et qui est surement veine.
Ton travail de refactoring tu le fais quand tu as besoin (c'est à dire que tu dois retoucher au code pour d'autres besoins fonctionels ou non fonctionels) et exceptionellement quand c'est vraiment justifier tu le passes en dette technique.
Bref ton code il devrait être raisonablement bon dès que tu livres, sinon tu t'es un peu perdu en chemin. Si tu es dans un hot spot de ton appli tu vas passer ton temps dessus et tu vas l'ameillorer petit à petit mais pas uniquement pour la beauté de la chose à fonctionalité équivalente. Sinon "raisonablement" est souvent largement suffisant. Après si tu t'es vraiment lourder sur un truc, bha c'est de la sâle dette technique.
Il faut s'adapter à la situation, mais resister au mythe de la réécriture qui va resoudre tout les problèmes est aussi important que de savoir identifier et juger les faiblesses de ce qu'on produit.