Ça marche, je vais pouvoir m’attaquer à la suite.

Je ne sais pas combien de fois j’ai pu entendre cette phrase, un⋅e developpeu⋅r⋅se annonce fièrement que la fonctionnalité sur laquelle il⋅elle travaillait fonctionne enfin et donc on va pouvoir s’attaquer à la fonctionnalité suivante. Je l’ai très probablement prononcée moi même.

Aujourd’hui, quand j’entends ça, ce « ça marche » comme point final au travail en cours je ressens un mélange d’irritation et de désespoir, d’autant plus grand que la personne qui le dit à d’expérience. Qu’on ne voit pas le problème quand on débute, même si ça m’agace, ça ne me surprend pas vraiment¹. Mais quand on a passé des années à se débattre dans du code complexe, difficile à faire évoluer, où corriger un défaut risque d’en introduire tout un tas de nouveaux, j’ai plus de mal. Et pourtant.

Parce que « ça marche », quand c’est votre métier, c’est juste le strict minimum². Dans bien des cas, c’est même la partie facile et rapide du travail. Une fois que « ça marche », on peut alors se mettre à être intelligent.

Déjà, on pourrait se demander si ça marche vraiment ? Qu’est-ce qui nous fait dire que ça marche ? Est-ce juste une intuition, ou est-ce que l’on s’appuie sur des éléments factuels, une série de tests rigoureux³ par exemple ? Est-ce que l’on connaît les limites de fonctionnement ? Ces limites sont-elles acceptable dans le contexte qui nous intéresse ?

Il faut aussi penser à l’avenir : est-ce que ça va continuer à marcher ? Est-ce que le code qu’on a produit est maintenable par ce⋅ux⋅lles qui passeront après nous la semaine prochaine ou dans 15 ans ? Est-ce qu’on pourra le faire évoluer ? Et le jour où l’outil/librairie/framework/trucs sur lequel on s’appuie ne sera plus maintenu, est-ce qu’on pourra facilement en changer ? Est-ce que les choix qui ont été fait nous ferme des portes pour l’avenir ?

Il y a aussi ce qui marchait avant, est-ce que ça marche toujours ? À-t-on de bonnes raisons de penser que notre nouvel ajout n’a rien cassé⁴ ? Est-ce que la solution apportée est cohérente par rapport à l’existant ?

Et tout ce qu’il y a à côté : est-ce que cela s’intègre dans les outils de déploiement/monitoring/… ? Est-ce que l’on pourra se rendre compte rapidement si cela se met à ne plus marcher ? Et dans ce cas, pourra-t-on remonter rapidement à la source de problème ?

Répondre à toutes ces questions de façon satisfaisante⁵ nécessite bien souvent un gros travail de test, de refactoring, de nettoyage, de réflexion plus globale sur le design et l’architecture de votre application. C’est le bon moment pour prendre du recul.

« Ça marche » c’est juste le point de départ.

Photo by 蔡 世宏 @cshang on Unsplash