Developer's notebook

Quand du code me parait obsolète, je vérifie qu'il n'est pas utilisé en lançant un CTRL+SHIFT+G sur mon workspace Eclipse, avant de le supprimer.

Cette manoeuvre m'a trahie plusieurs fois :

1. la classe était instanciée dans Spring
2. la classe était utilisée... mais sur un projet qui n'était pas ouvert dans mon workspace. Ouvrir tous les projets juste pour cela a quand même un coût non négligeable. De plus, la manoeuvre n'est pas possible quand on a plusieurs branches (les différents projets portant le même nom).
3. la méthode était utilisée dans de l'introspection. C'est là que je me dis, décidément, la réflection pose un véritable problème pour le refactoring.

Des tests d'intégration en JUnit ou Fitnesse peuvent révéler le premier souci. On se rend compte des deux autres à un moment ou un autre mais trop tard pour facilement identifier le problème.

Misko Hevery reprend dans Design for testability les différents points abordés lors de ses clean code talks.

En conséquence, si vous avez regardé les vidéos clean code talks, vous allez sentir quelques répétitions.

J'entends assez souvent "il faut", "il ne faut pas", comme si c'était une loi venant d'une instance suprême. Ce n'est pas un reflexe de remettre les choses en cause et de se demander pourquoi on fait quelque chose. Questionner n'est pas forcément bien vu non plus et peut heurter. C'est la force de l'habitude.

Si un projet plante, et que le manager n'a rien fait de "spécial", on se dira que c'est la faute à pas de chance. S'il a eu le malheur d'innover, en mettant en place des méthodes agiles par exemple, alors il y a de grandes chances pour que ce soit cette innovation qui soit pointée du doigt. Quelque part, suivre sans interroger se comprend, nous supposons que d'autres gens se sont déjà penchés sur la question. Heureusement que nous avons un minimum confiance en notre passé.

Extrait d'une conversation :

Bonnie : On devrait regrouper les imports statiques des matchers JUnit que l'on utilise dans une librairie à part, et ne faire qu'un seul import.

Clyde, hésitant : S'ils sont amenés à être utilisés ensemble, pourquoi le framework ne met pas directement tout dans un seul import ou dans le même package? Plutot que pousser chacun à tout repackager?

Bonnie : C'est une bonne pratique, même sur Xebia ils le disent. Si tu ne me crois pas, tu peux demander aux architectes, ils te diront la même chose.

Ah bah s'ils le disent... Autant vous dire que l'argument qui tue "c'est Jacques que tout le monde respecte qui l'a dit" a beaucoup aidé Clyde.

Cela n'empêche pas Bonnie d'avoir raison. Un argument est évoqué dans Clean Code, elle concerne les API externes en général. L'idée est de réduire le couplage de notre code avec les API externes tout bêtement. Si elles changent, il n'y aura qu'un endroit à changer. Depuis, j'ai cette "note pour moi-même" : même si les raisons me paraissent évidentes, elles ne le sont pas pour tout le monde, il vaut mieux dire d'emblée pourquoi je pense qu'il vaut mieux faire ci que cela.

Je m'égare, je m'égare. Là où je voulais en venir, c'était qu'on m'avait fait remarquer un jour "qu'il ne faut pas faire travailler un constructeur, même pas en appelant une méthode init()". Je savais cela, mais honnêtement, je ne savais pas très bien pourquoi. Du coup, quand un petit travail dans le constructeur me facilitait la vie, je le faisais quand même...

Et bien voici une raison, citée par Misko Hevery dans Don't Look For Things : pour poser un test sur un objet, l'opération que l'on ne peut absolument pas éviter est d'instancier l'objet et donc d'invoquer le constructeur. S'il y a des opérations compliquées dans le constructeur, nous sommes obligés de faire avec dans les tests. Et tous les tests utilisant cet objet en tant que collaborateur auront le même boulet à trainer (à moins d'avoir un framework magique qui permette de mocker les constructeurs).

Je suis en train de lire Clean Code de Robert Martin et je me rends compte que ma facon de coder est beaucoup plus sale que je ne le pensais, en dépit de tous mes efforts. C'est un peu comme la musique : c'est facile de sentir que quelqu'un chante faux, c'est une autre histoire de savoir chanter juste. Ce livre apporte également beaucoup de réponses à des problématiques que j'avais rencontré, qui me génaient mais que je ne savais pas comment résoudre.

Le billet d'aujourd'hui concerne le recours aux méthodes privées. Ma facon de procéder était la suivante : je code, et s'il y a deux fois le meme code, je crée une méthode privée pour factoriser. J'aimais bien aussi tout avoir sous les yeux, dans la même méthode, plutot qu'éparpillée dans la classe.

L'approche de Martin est différente : le code propre doit se lire comme un roman. Les méthodes privées ont, de fait, un autre role : donner du sens au code. C'est seulement si nous souhaitons connaitre le détail que l'on rentre dans la méthode privée.