Il y a quelques jours, en travaillant sur quelque chose avec React, j'ai réalisé qu'il y avait déjà deux projets où les helpers sont partout, et parfois ils arrivent même à l'étape de code review, avec des discussions sur la question de savoir si une méthode, une classe ou un fichier devrait être appelé helper ou non. C'est généralement fastidieux.
En cherchant sur Internet pour voir si c'était quelque chose qui m'avait seulement touché, j'ai trouvé que c'est plus un moyen d'éviter de tomber dans l'autre rabbit hole : ne pas savoir comment nommer les choses quand il s'agit de programmer.
Dans les vingt minutes que j'ai passées à chercher, j'ai trouvé un post sur Reddit qui mentionne que le problème potentiel est que nous exprimons directement nos propres modèles de pensée dans les noms que nous donnons aux fonctions. Il n'y a rien de mal en ça, mais cela peut nous limiter.
Je suis d'accord avec cet argument. Il y a des moments où les discussions tournent uniquement autour de la façon de nommer quelque chose. Ce qui nous limite, c'est que ces petits blocs nous éloignent de ce qui compte vraiment dans le code que nous programmons :
la logique métier
La logique métier est ce qui nous permet de distinguer si les exigences sont bien exprimées dans des lignes de code, pas les noms que nous donnons aux variables. Les bons noms, la claire expressivité et l'expérience sont les éléments qui apportent vraiment de la valeur. Et cette expérience ne vient pas seulement du travail : aussi d'une sortie au parc avec la famille, avec des amis, lors d'une fête bien organisée.
Ce qui rend le travail monotone aujourd'hui, ce n'est pas le travail lui-même : il y a des problèmes amusants et divers, pas de jour comme le précédent. Ce qui génère des obstacles mentaux, ce sont ces limitations subtiles.
Donc, voici une idée : arrêter d'appeler "helpers" quelque chose qui, en réalité, sont des fonctions.
Des gens avant nous, à travers des livres comme Clean Code, Clean Architecture et bien d'autres, l'ont déjà exprimé : il faut faire les choses simples. Je me souviens d'une règle qu'une maîtresse de bases de données à UTT nous a enseignée : KISS – Keep It Simple, Stu***. C'était amusant à l'époque, mais cela reflète comment les gens avaient tendance à compliquer les choses.
Jusqu'à quand allons-nous rester passifs dans notre travail ? Combien de temps devons-nous attendre pour mûrir et prendre les rênes ?
Je vous invite à vous demander : ce qui est discuté dans cette code review ou ce meeting est-il une vraie limitation, ou sommes-nous simplement en train de tomber dans la loi de la trivialité de Parkinson ?