PLSQL Best Practices

Description du livre ici.

Mikado Method

J'ai lu ça et là pas mal de choses sur la Mikado Method ces derniers temps. J'ai pu profiter de longues heures de vol pour dévorer le bouquin (je vous ai dit que je possédais un Kindle ?)

Il s'agit d'une méthode pour faire du refactoring dans du code legacy. On peut la voir comme une amélioration ou une industrialisation au draft refactoring proposé par Michael Feathers dans Working Effectively With Legacy Code (pas de lien, j'ai déjà fait une pub gratos pour Amazon plus haut).

Vous avez tous joué aux mikados. On a plein de bâtonnets en foutoir et il faut les récupérer un par un sans faire bouger les autres. L'objectif est de récupérer celui avec la spirale bleue appelé... le mikado ! Celui-ci fait gagner plein de points et assure au joueur qui s'en empare de remporter la victoire. Si on fait bouger un autre bâtonnet, on passe son tour et on est frustrer d'avoir à attendre pour recommencer.

Si on reprend cette analogie, le refactoring proposé par la mikado method s'apparente à jouer au mikado comme un gros bourrin : en essayant de choper le mikado dès le début du jeu ! On ne sait jamais, si cela fonctionne, on aura gagné un paquet de temps et d'énergie...

Voilà comment ce déroule le processus :

1. Vous vous fixez votre objectif. Cela peut être d'ajouter une fonctionnalité, ou de diminuer le couplage entre plusieurs composants, etc. Il s'agit de l'objectif final. Il vous semble difficile à remplir directement. Sinon, ce n'est pas drôle.
2. Vous essayez d'attendre l'objectif directement, réalisant les actions à mener sans vous soucier du reste du code.
3. Normalement, dans tout bon système legacy (c'est à dire existant depuis plus de deux jours en moyenne...), votre projet ne doit plus compiler car vous avez des erreurs de compilation sur énormément de classes. Cette situation dégage un objectif secondaire : vous devez régler ces problèmes avant de remplir votre objectif principal. Vous le notez.
4. C'est le plus important et le plus douloureux : vous faites un revert des modifications pour rendre le système à nouveau fonctionnel.
5. Vous tentez d'atteindre les objectifs secondaires avant l'objectif initial. Si cela ne fonctionne pas, vous dégagez de nouveaux objectifs, faites un rollback et recommencez.
6. Itérez jusqu'à la mort ou jusqu'à avoir rempli l'objectif principal (ou les deux, comme dirait mon chef).

J'ai trouvé ça plutôt intéressant et vous incite à lire le livre. Un point fort je trouve est que les auteurs proposent d'accompagner les différentes étapes par la mise en place d'un diagramme montrant les différents objectifs à remplir et les liens entre eux. Ceci permet de faciliter la communication dans l'équipe et de voir l'avancement dans la réalisation de l'objectif initial.

Je suis arrivé sur un nouveau projet legacy (il a plus de 2 jours), et j'imagine déjà des cas dans lesquels je pourrai utiliser cette Mikado Method !

Lecture d'XP Explained

J'ai lu récemment la seconde édition de Extreme Programming Explained de Kent Beck. Cela peut paraître assez incroyable qu'un fan comme moi d'XP n'ait pas encore lu ce livre... Pourtant c'est bien le cas !

Avant de le lire, je pensais que ce serait un texte radical, à la Robert Martin, du genre "si vous voulez faire de l'XP demain, il faut développer en TDD exclusivement et faire du pair programming tout le temps". En fait, Kent Beck n'est pas du tout comme ça. Il a plutôt tendance à dire qu'il faut y aller progressivement. Tester une pratique, constater les bénéfices avant d'aller plus loin. Somme toute, le livre est assez motivant et l'auteur sait bien qu'il propose des pratiques assez, n'ayons pas peur des mots, extrêmes.

Dans sa première partie, le livre se focalise sur les valeurs derrière XP qui sont :

• Communication
• Simplicité
• Feedback
• Courage
• Respect

Déjà, je trouve que ce n'est pas toujours évident de suivre ces valeurs au quotidien !

De ces valeurs découlent des principes et les pratiques qui sont à présent bien connues, si bien qu'elles sont devenues une caricature de l'agilité : un tableau avec des post-its, un ordi pour deux et pas de code avant d'écrire les tests les loulous !

L'hypothèse est que ces pratiques vont bien ensemble. Toutefois, s'il est conseillé de toutes les utiliser, il suffit d'en développer une pour en récolter rapidement les bénéfices. Il est vrai que se mettre au TDD permet d'avoir une meilleure qualité de code. Je le vérifie personnellement tous les jours. Les autres pratiques sont toute aussi intéressantes (même le pair programming, je vous jure !).

Lors de la première édition du livre, on s'aperçoit que les concepts avancés par Beck étaient assez théoriques : ils n'ont, à ce que je crois comprendre, été appliqués que dans le cadre du fameux projet chez Chrysler. Pour la deuxième édition, il a appris des retours des early adopters et des détracteurs. Certains points pour lequel il pensait qu'XP n'était pas adapté ne sont plus un problème, car certains l'on fait (par exemple, utiliser XP dans une équipe dispersées sur plusieurs sites). Certaines fois, son discours s'est radicalisé. La longueur de l'itération est ainsi passé de 2 à 1 semaine.

Enfin, j'ai eu une révélation sur un grand obstacle à l'adoption d'XP et des pratiques Agiles en général développé vers la fin du livre. Bizarrement, je n'en avais pas conscience avant de le lire.

XP ne peut pas marcher si les vraies valeurs de l'entreprise dans laquelle vous travaillez sont en opposition avec les valeurs XP. On ne parle évidemment pas des valeurs communiquées par les équipes marketing, mais ce celles qui sont révélées par le comportement des employés. Si dans votre entreprise, on a l'habitude de cacher des choses aux clients, on est alourdit par des tonnes de procédures et que les gens craignent de prendre leurs responsabilités alors ce n'est peut-être pas une bonne idée de souhaiter investir dans XP. Cela ne pourra pas marcher.

Je pense que c'est un point à méditer, alors que beaucoup d'entreprises se déclarent aujourd'hui expertes Scrum / Agile !

PS : pour terminer le fan service, vous pouvez retrouver sur le podcast Software Engineering Radio une interview de Kent Beck.

PPS : je ne sais pas vous, mais j'ai bien envie de coder en Smalltalk là !

Sur ce à plus tard et n'oubliez pas de lire des livres.

Pragmatic Programmer

J'ai enfin lu le livre "Pragmatic Programmer" de Dave Thomas et Andrew Hunt. L'ouvrage date de 1999 mais reste furieusement d'actualité : le mouvement du Software Craftsmanship fait notemment référence à son sous titre "From Journeyman to Master".
Dans ce livre, les auteurs ont rassemblé leurs réflexions sur ce qui pourrait améliorer leur métier au quotidien et en ont extrait 70 conseils.

Certains sont très connus et sont souvent cités sur le Net. Cependant, nous avons là les intentions initiales derrières ces concepts. A titre d'exemple, le principe DRY pour Don't Repeat Yourself est réutilisé dans la présentations des frameworks web full stack comme Rails. Dans le livre, nous apprenons que les auteurs souhaitent pousser ce principe dans tous les domaines du développement. Que ce soit le code,  l'architecture ou même la documentation, l'information ne doit se trouver qu'à un endroit. A partir de ce postulat, il n'est pas étonnant que les auteurs soient de fervants promoteurs de la méta-programmation et du langage Ruby depuis 10 ans.

Ce principe a eu un écho douloureux pour moi ces derniers temps : j'ai retouché un document d'exploitation redondant simultanément avec la spécification technique, le code d'ordonnancement et le code applicatif.

Je ne vais pas paraphraser tout le livre... Malgré son âge, seuls quelques de sujets sont aujourd'hui un peu passés de mode : des choses sur Perl ou la programmation par contrat. C'est un livre que je conseillerais de lire aux débutants. Que les allergiques à l'Anglais se rassurent, la langue n'est pas compliquée. Seul problème : comme d'habitude, le livre est cher (vive le Kindle).

Merci pour l'héritage

Je viens de terminer le livre de Michael Feathers "Working Effectively With Legacy Code". Ce livre donne des pistes pour travailler sur du code dépourvu de tests unitaires, l'objectif étant de développer suffisamment de tests unitaires pour pouvoir faire évoluer le code.
Cette problématique n'est pas triviale. En effet, l'intéret d'une pratique comme le TDD est que le code est construit pour être testé ce qui permet de faire évoluer en toute sécurité le design du système.

Que trouve-t-on quand on doit faire évoluer l'héritage (legacy) de plusieurs années développement en SSII :

• de grosses classes / fichiers ;


• de grosses fonctions ;


• un couplage fort entre les composants, comme du code métier appelant directement une base de données (merci le Pro*C !).

Les techniques proposées dans le livre visent à réduire le couplage pour permettre d'écrire une couverture suffisantede TU.

Le point fort d'après moi est d'adopter un point de vue très pragmatique : bien souvent, on intervient sur du vieux code pour faire une corerction ou une simple évolution. Le budget est rarement propice à une refonte globale du design du système. M. Feathers ne propose pas de changer du code critiquable en code parfait mais bien de se donner les moyen d'intervenir efficacement de manière sécurisée. Ainsi, plusieurs solutions proposées présentent des entorses au principe d'encapsulation*.

Pour moi, ce livre est un must read pour tout développeur professionnel tant les situations décrites font partie de notre auotidien. On le vaincra, ce mauvais code !



* Je conseillerais aux puristes de l'encapsulation d'essayer Python, ça les détendra (ou le contraire).