Utils et helper sont sur un bateau…

Petites vaguelettes
  provoquées par un objet tombant à l'eau avec une luminosité évoquant un
  coucher de soleil

Et si on les jetait à l'eau refactorisait ? 😀

Dans une revue de code ou en explorant une base code, ces noms là, tout comme dans une certaine mesure les handlers et autres managers, déclenchent systématiquement dans ma tête une petite alarme 🔔 qui appelle à aller regarder de plus près ce qui se cache derrière.

Ces termes sont très génériques même si ils sont souvent accompagnés d'un préfixe, d'un suffixe ou d'un chemin un peu spécifique (encore qu'on a tous dû tomber au moins une fois sur un src/utils.js quand ce n'est pas src/tools/utils.js 😉). Et par conséquent, la ou les responsabilités de ces composants sont loin d'être claires. D'ailleurs, ce genre de composant a une sérieuse tendance à être un fourre-tout avec beaucoup plus qu'une unique responsabilité.

Aussi, quand ce genre de composant occupe une place importante dans le code en terme de quantité de logique, c'est autant de logique qui n'est pas là où elle aurait plus de sens. L'utilisation abusive de ce genre de composant va de pair avec d'autres code smells, notamment :

  • des objets anémiques : les objets métiers se retrouvent dépourvus de comportement puisqu'il est relégué dans ces helpers et utils ;
  • un manque d'encapsulation : les objets exposent nécessairement plus qu'ils ne devraient pour que ces composants puissent faire leur travail ;
  • des abstractions manquantes : là encore, une responsibilité qui pourrait être proprement isolée dans un composant bien nommé se retrouve diluée.

C'est pourquoi, en ce qui me concerne, chaque mention d'un utils ou d'un helper me rend plus que méfiant. Quasiment systématiquement il existe une meilleure solution en terme d'expressivité, de qualité de code et de maintenabilité.