Les techniques de réusinage

d’essayer de produire de la valeur ajoutée en modifiant le moins de code possible afin d’éviter les régressions accidentelles. Mais, au fil du temps, ces petites modifications s’accumulent, d’où un code de moins en moins lisible et, au final, incompréhensible. Mais les choses peuvent se dérouler autrement.

Une bonne pratique consiste à réusiner le code existant avant d’ajouter des fonctionnalités ou de corriger les bugs. Votre objectif doit être de modifier la structure de votre code en vue de l’améliorer, de sorte qu’il continue de véhiculer clairement votre conception après la correction du bug ou l’ajout de la nouvelle fonctionnalité. Il faut de la pratique pour développer cette compétence. Vous avez peut-être l’impression de seulement déplacer du code lorsque vous effectuez le réusinage et cela peut tout à fait être l’un des résultats. La clé est d’avoir en tête un objectif qui garantit que vous améliorez réellement la qualité de votre code.

Si vous n’êtes pas très au fait des techniques de réusinage, je vous recommande fortement la lecture de « Refactoring : Improving the Design of Existing Code », par Martin Fowler (Addison-Wesley Professional, 1999) et « Working Effectively with Legacy Code », par Michael Feathers (Prentice Hall PTR, 2004). Ces deux références détaillent différentes techniques et la motivation derrière de nombreuses opérations de réusinage applicables pour améliorer votre code.

L’un des meilleurs moyens de pratiquer le réusinage du code est de travailler sur des exemples et ateliers (labs). Les ateliers ont pour objet de présenter une technique spécifique ou une fonction de bibliothèque. Même s’ils n’ont pas pour vocation d’être du code de production, ils peuvent être adaptés à votre utilisation spécifique et vous faire gagner du temps en proposant du code opérationnel comme base de départ.

Pendant la création de l’exemple d’application pour cet article, je suis parti d’un des exemples Azure fournis par Microsoft. Je l’ai modifié pour ajouter les fonctionnalités dont j’avais besoin, puis j’ai commencé à réusiner la structure voulue. L’avantage est que vous démarrez avec une application opérationnelle et elle le demeure aux différentes phases. Chaque étape doit améliorer la qualité du code et faire en sorte que celui-ci soit plus générique et plus facile à réutiliser dans différentes applications. Dans ce cas, à quel moment allez-vous vous arrêter ? Lorsque vous n’avez plus d’idée d’amélioration visant à faciliter la mise en œuvre de l’exemple dans l’application.