Sandi Metz a récemment écrit un article proclamant que la duplication est moins chère qu'une mauvaise abstraction. Cet article soulève des points précieux sur les coûts de la généralisation spéculative, mais il fait partie d’une longue série d’articles détaillant et dénonçant ces coûts. À l’heure actuelle, cela devrait être un vieux chapeau d’entendre quelqu’un critiquer l’abstraction, et pourtant le mème persiste.
L'aspect de l'article de Sandi Metz auquel j'aimerais répondre dans ce post est le état d'esprit il favorise ou du moins l’état d’esprit qui y a le plus répondu. Cet état d’esprit est très courant dans les commentaires : il suffit d’accomplir la tâche, rien de plus. Parfois, c'est approprié et c'est la bonne approche à adopter, mais le problème ici est que les coûts de l'abstraction, surtout lorsqu'elle se trompe, sont évidents, et les coûts de l'état d'esprit « la simplicité d'abord » ne sont pas aussi évidents. Je ne parlerai pas des coûts spécifiques du code dupliqué, car ceux-ci sont déjà bien connus. je parlerai du coûts d'opportunité – les opportunités d'apprentissage manquées.
Les bons développeurs doivent constamment apprendre et perfectionner leurs compétences. Il y a toujours place à l'amélioration. La compétence la plus importante à mettre en pratique par les développeurs est de reconnaître les abstractions rentables, car cela repose correctement sur une intuition aiguisée. Il faut voir les coûts se manifester sur le long terme et commettre des erreurs. Les développeurs doivent constamment évaluer leurs décisions passées et prendre des risques sur les nouvelles.
Le coût d’opportunité est un aspect souvent négligé de la dette technique. La raison pour laquelle l’accumulation de dette technique est actuellement le choix le moins coûteux est qu’elle emprunte une voie dont la solution est déjà connue. Il n'y a rien à apprendre, il suffit de mettre en œuvre le hack. C'est bien à petites doses, mais cela perd la possibilité d'apprendre des choses sur la base de code, de découvrir les abstractions manquantes et de créer des outils conceptuels qui peuvent aider à résoudre le problème.
Ainsi, ce que les développeurs de l'exemple de Sandi Metz auraient dû faire, c'est remarquer que cette abstraction particulière leur coûtait plus qu'elle ne leur profitait. C'est une bonne chose à remarquer : c'est une expérience d'apprentissage précieuse. Quels aspects spécifiques de l’abstraction ralentissaient le développement ? Quels éléments ont dérouté les nouveaux développeurs et les ont amenés à aggraver la situation ? Ce sont des questions que les développeurs auraient dû se poser pour tirer les leçons de l’expérience.
Notre équipe de développement organise une séance hebdomadaire que nous appelons « Tech Talks », dans laquelle un développeur parle de quelque chose qu'il a appris cette semaine-là, d'une partie de la base de code qui était plus épineuse qu'elle n'aurait dû l'être, etc. Cette pratique est inestimable pour promouvoir un état d’esprit de croissance et la situation de Mz. L'article de Metz aurait été un parfait exemple à évoquer.
Les développeurs ne devraient pas se concentrer uniquement sur la création de code. Ceux qui limitent ainsi leur attention ne grandissent pas et seront bientôt dépassés par de meilleurs outils. Au lieu de cela, nous devrions reconnaître que le travail d'un développeur consiste à comprendre quelles abstractions s'avéreront utiles pour la base de code. La seule façon d’apprendre cela est par l’expérience.
