Des guides plus que des dogmes
On est entouré de principes, de lois, de modèles, de méthodes et d’un tas d’autres concepts. C’est utile pour construire des choses complexes comme des logiciels - on a besoin d’être aidé. Pour autant, je conseille de garder un minimum de recul et de questionnement face à ces grands écrits - ce ne sont pas des vérités absolues en toutes circonstances. Notre cerveau est plus que jamais important.
J’aime considérer les principes (& co) comme des guides. Ils me donnent des indications sur ce que je fais pour prendre de la hauteur. Ça m’aide à réfléchir et à me questionner. Suis-je dans une bonne direction ? Pourquoi ce principe semble m’alerter ici ? Qu’est-ce que ça va m’apporter ? De quoi ai-je besoin ? En me posant des questions, je m’assure de prendre en compte mon contexte et de m’y adapter. Je cherche aussi à bien comprendre le principe, pour qu’il me guide au mieux. Peut-être que ça ne fait pas sens de l’appliquer ici.
Un exemple avec le principe DRY (Don’t Repeat Yourself). Je viens d’écrire du code qui ressemble à un autre morceau de code ailleurs dans le projet. Le voyant DRY s’allume et me dit d’éviter la duplication. En prenant du recul, je peux me demander si c’est réellement de la duplication. Est-ce qu’ils sont dans le même domaine métier ? Est-ce qu’ils ont les mêmes raisons de changer ? À quel point est-ce identique ? Ou même, est-ce trop tôt ? Même si le principe peut m’indiquer un comportement à adopter, je prends d’abord soin de réfléchir et d’analyser mon contexte.
À l’opposé, une approche plus dogmatique des principes. On arrête de réfléchir, on ne se pose pas (trop) de questions. On applique bêtement ce que le principe nous dit. En même temps il n’y a pas à réfléchir, si le principe le dit, c’est forcément vrai. Alors on le fait. On commence même à avoir une vision binaire : je respecte ou je ne respecte pas. D’ailleurs, si je ne respecte pas, c’est évidemment mal.
En reprenant l’exemple du principe DRY, j’aurais sûrement supprimé la duplication tout de suite. Sans questionnement. Deux bouts de code qui se ressemblent ? Oula, vite ! Qu’on me supprime cette duplication ! Pourtant, il s’agissait de règles métiers de deux domaines différents. Peu de temps après, j’aurais cassé le comportement d’un des deux domaines en modifiant ce bout de code non dupliqué. Espérons qu’un test unitaire soit passé au rouge et que ce ne soit pas les retours alarmants de la prod qui auront mis en avant le problème.
Continuons de réfléchir, de creuser les principes en profondeur et de prendre en compte notre contexte. N’appliquons pas bêtement et évitons les vérités absolues.