Le refactoring, une pratique nécessaire
Que nous soyons développeur, ops ou architecte nous manipulons des notions en mouvement constant : le besoin client change et sa compréhension évolue.
La robustesse d’un système se consolide. La maîtrise d’une technologie s’améliore. Les besoins en sécurité doivent s’adapter...
Nous ne pouvons être exhaustifs sur les éléments de remise en cause des acquis mais une certitude demeure, rien n’est figé. Les changements de paradigme amenés par le cloud en donnent une belle illustration. Tel service IaaS d’hier se voit proposer une alternative managée demain. Il en va de même avec un langage de programmation et des systèmes d’exploitation dont l’évolution nous offre des moyens de réponses supplémentaires aux besoins métiers. Charge à nous de suivre cette dynamique à travers une pratique nommée “refactoring”. C'est l'objet du livre présenté qui, stricto sensu, fait moins référence au refactoring qu’aux bonnes pratiques associées.
L’auteur
Martin Fowler, l'auteur, promeut depuis plus de 20 ans cette pratique dont la maîtrise est très liée à l’expérience. Notons d’emblée que ce livre a un point de vue résolument “développeur” et un bagage de compréhension de code est conseillé pour comprendre le JavaScript illustrant les concepts. Ce qu’il propose à travers ce livre est une compilation de son expérience via un catalogue de différentes situations et bonnes pratiques associées sur lesquelles il s’est forgé une opinion. On retrouvera son expérience sur d’autres types de sujets sur son site officiel dont la lecture est chaudement conseillée.
Un contenu à la carte et axé pratique
Le refactoring adhère peu à une approche théorique. De ce fait, le livre est très axé sur l’exemple. Les deux premiers chapitres vous expliquent l’intérêt du refactoring, quand l’employer, où l’éviter. Ces propos sont illustrés par un refactoring bout en bout d’une application illustrants les questions à se poser et surtout la continuité du processus.
On y insiste sur le compagnon de route du refactoring qu'est le test. Bien que selon la séniorité du lecteur certains points du livre auront plus ou moins d'intérêt, il est toujours intéressant de revenir sur les motivations du refactoring.
On ne saurait justifier cette pratique pour la beauté du geste. Elle doit avant tout rester utilitariste et guidée par le business. L'objectif est d'organiser son code de telle manière qu'il apparaisse comme une boîte à outils intelligible pour les évolutions à venir.
Ces généralités évoquées, un catalogue de bonnes pratiques contextualisées complétera le livre en donnant des points d'entrée disjoints que le lecteur abordera en fonction du besoin. C'est un aspect intéressant du livre dans la mesure où il n'impose pas de sens de lecture et qu'un développeur junior comme averti y trouvera de nombreuses approches.
Accessible mais pas simpliste
Attention à ne pas confondre ce livre avec un concentré de bon sens. On pourrait être tenté de penser ainsi du fait de l’accessibilité du livre. Pourtant, les différentes approches enseignées doivent se penser de concert. C’est ici que l’on retrouve toute la difficulté du refactoring.
Il ne s'agit pas de bêtement scanner un code pour y appliquer mécaniquement une entrée du catalogue. En premier lieu, le livre prône une approche de refactoring continu. Le refactoring est systématiquement associé à un contexte et les pratiques s'y appliqueront dans un certain ordre en les associant toujours à des tests.
L'expérience montre assez souvent que cette réflexion n'a rien d'évident tant nous trouvons fréquemment à redire sur le code que nous parcourons.
N'y voyez pas non plus un livre à lire une fois puis à reposer. Vous aurez besoin de relire certains passages du livre après avoir expérimenté ce que vous en aurez compris sur des vrais projets. Vous aurez alors une vision différente de la problématique et une deuxième lecture vous apportera une compréhension plus profonde, voire différente du chapitre.
C'est en forgeant que l'on devient forgeron.
Voir au-delà du développement
Comme déjà évoqué, c’est un livre à destination des développeurs mais le développeur doit-il seulement appliquer les principes décrits à son métier d’origine ? Du recul sur ces principes permet une prise de conscience sur le fait qu’ils peuvent s’appliquer beaucoup plus largement à d’autres métiers de l’IT. On parlera de la notion du "clean" déclinée en autant de notions "Clean{Code; Architecture; Infrastructure}".
Les principes y sont similaires :
- Non duplication
- Une ligne ajoutée est un bug potentiel
- Complexité combinatoire à éviter
- Interaction entre composants réduite au strict minimum (couplage faible)
Comme le suggère le nouveau mantra “you build it, you run it” (et inversement), de plus en plus de développeurs sont amenés à faire de l'opérationnel et de l’architecture. De ce fait, de nouvelles pratiques infusent dans ces métiers. Le mouvement DevOps en est une illustration car c’est historiquement la manière pour un développeur de prendre le rôle d’un ops. En particulier, le refactoring s’applique très bien à des tâches opérationnelles ou d’architecture. Cela est d’autant plus vrai depuis l’émergence d’outils riches et matures. Par exemple, Terraform offre un langage (voire des langages si l’on ajoute à HCL Terraform CDK) couplé avec des entités à manipuler dont l’usage se rapproche du métier de développeur.
Dans un registre tout à fait différent, Airflow, un outil ETL (Extract Transform Load), donne aussi lieu à la possibilité de définir, découper, bouger des éléments selon des principes que l’on retrouvera dans ce livre : toute transformation sera idempotente dans la mesure du possible (mutabilité à éviter). Une transformation sera spécialisée sur un point particulier. Son scope doit être limité...
Dans la même veine, penser globalement un système dans le cloud avec tous les services adéquats peut s’apparenter à du développement et donc être adapté aux enseignements du livre. L’approche micro-services qui a si bonne presse de nos jours peut s’interpréter comme une extension des bonnes pratiques de développeurs aux métiers d’ops et d’architecte :
Qu’est-ce qu’un service sinon une macro-classe spécialisée exposant quelques méthodes publiques ? Qu’est-ce qu’une fonction lambda sinon qu’une méthode statique ?
Qu’est-ce qu’un service de log sinon un singleton permettant de centraliser des données ?
Les analogies sont nombreuses et cohérentes avec l'application des schémas de refactoring.
La convergence des métiers
Des profils de plus en plus éclectiques en terme d'expérience apparaissent : développeur puis Data Engineer puis architecte Cloud puis DevOps. Ce qui pourrait sous-tendre une incohérence révèle en réalité une convergence des bonnes pratiques qui permettent de changer de paradigme simplement.
Le fait d’avoir commencé développeur et d'avoir incorporé ces pratiques est une opportunité pour évoluer vers d’autres postes. Non pas dans une approche verticale qui placerait un architecte comme une évolution du développeur, mais dans une approche horizontale pour enrichir un métier avec un point de vue développeur.
Le mot de la fin
Le refactoring de code n'est pas une science dure. Il y a un degré d'interprétation important laissé à la discrétion du développeur. Pourtant, il existe bien une convergence des bonnes pratiques. "Code refactoring 2nd Edition" permet de comprendre et pratiquer cette convergence. Au-delà des pratiques, c'est aussi autour des nombreux métiers de l’IT que l'on retrouve cette convergence. Pour cette raison, nous pouvons raisonnablement penser que cette lecture vous rendra meilleur.e développeur.se au même titre que meilleur.e architecte ou ops. Un livre qui a donc toute sa place dans votre bibliothèque.
Note : Une version physique de ce livre est indispensable. Nous soulignerons à ce titre la qualité exceptionnelle de l’impression et de la couverture permettant une navigation aisée à travers les différentes entrées du catalogue. Voici la référence du livre que vous trouverez aisément sur Internet:
Released November 2018
Publisher(s): Addison-Wesley Professional
ISBN: 9780134757681
Cloud Native
Cloud Native
