Bonjour, Habr!
J'attire votre attention sur une traduction de l'article "
Simple Hickey " de Robert C. Martin (Oncle Bob).
Rich Hickey a prononcé une excellente conférence sur Strange Loop intitulée Simple, Easy. Je vous recommande fortement de passer une heure à l'écouter. Cette performance vaut chaque seconde.
Il y aura certaines choses dans cette conférence avec lesquelles vous n'êtes pas d'accord. Lorsque cela se produit, arrêtez-vous et pensez - réfléchissez sérieusement - êtes-vous vraiment en désaccord. Vous ne devriez peut-être pas penser qu'il en est ainsi.
Par exemple, Rich dit des choses apparemment dédaigneuses sur TDD et Agile et Refactoring - les vaches sacrées de la communauté Agile. Si vous êtes attaché à cette communauté, vous pouvez réagir négativement. Pas besoin. Rich ne néglige pas la pratique. Il néglige la religion - l'insouciance - la frivolité.
Rich compare les tests unitaires aux rails de sécurité. Puis il fait un très bon point. Il dit que lorsque vous avez une erreur, cette erreur a réussi vos tests. Et maintenant quoi? Vous devriez maintenant trouver l'erreur. Et si le système n'est pas simple, ce ne sera pas facile. (Veuillez noter que j'ai utilisé les mots ici simplement et facilement. Le début du discours de Rich est lié aux différentes définitions que ces mots ont. Je vous suggère de vous arrêter à cet endroit et d'écouter les dix premières minutes de son discours, puis de revenir à nouveau dans ce paragraphe.)
Rich souligne que les sprinters courent vite, mais pas pour longtemps. Il dit ensuite qu'Agile a "résolu" ce problème en tirant simplement le pistolet de démarrage encore et encore et rapidement. Il sourit et le public rit. Il poursuit en disant que le sprint continu ne rend pas nécessairement les systèmes simples et que la simplicité est la clé de la vitesse.
Bien sûr, il a raison. Martin Fowler en a parlé dans son article «Flaccid Scrum». Et c'est ce que beaucoup d'entre nous dans la communauté Agile ont exprimé. Ces courtes itérations sans bonnes pratiques techniques ne conduisent pas à un développement rapide. Au contraire, cela conduit à un gâchis.
Rich rit à l'idée qu'une suite de tests vous permettra de changer le code. Il dit que les tests sont un filet de sécurité, rien de plus. Nous, TDDers, savons qu'une suite de tests est nécessaire si nous voulons changer le code sans crainte. Mais Rich a raison sur le filet de sécurité. Un système de sécurité peut vous aider à simplifier votre système s'il est déjà simple. Mais un système de sécurité sous une grosse liasse de terre n'aura que peu d'aide pour démêler le gâchis. Oh, ne vous méprenez pas. J'ai besoin de ces tests! Mais le travail ne sera pas facile. (encore ce mot).
Voici un autre discours de Rich: Hammock Driven Development, dans lequel il nous encourage à réfléchir, et pas seulement à écrire des morceaux de code.
Alors voilà. Rich craint, à juste titre, que nous ayons une culture complexe. Lorsqu'une tâche est définie pour les programmeurs, ils s'exécutent et écrivent beaucoup de code déroutant, en utilisant des cadres et des outils "simples", sans donner au problème une signification appropriée. Ce que nous confondons légèreté et simplicité. (Par exemple, Rails est facile, mais ce n'est pas facile.) Sa plainte concernant les tests est que nous les avons utilisés pour remplacer l'idée. Ce qui est bon pour nous, car nous avons écrit les tests, mais en fait nous n'avons pas passé assez de temps sur le problème qu'il mérite. Nous n'avons pas simplifié le problème. Nous avons simplement fait ce qui était facile.
Donc, en vérité, la communauté Agile et l'ensemble de la communauté des logiciels sont infectés par cette maladie. Trop souvent, nous faisons ce qui est facile, en raison de ce qui est simple. Et donc nous faisons un gâchis. Mais ce n'est pas la valeur de l'agilité maintenant et ne le sera jamais. Et ce n'est bien sûr pas la valeur de la maîtrise du logiciel! En effet, faire ce qui est simple, contrairement à ce qui est facile, est l'une des caractéristiques déterminantes d'un assistant logiciel.
En fin de compte, je pense que la perception TDD de Rich est déformée par ce qu'il voit dans l'industrie. Honnêtement, je pense qu'il a manqué quelques détails. Et je pense qu'il comprendrait que cette pratique lui serait aussi utile qu'à moi. Pas comme un moyen d'éviter de penser et de se jeter dans le pétrin, mais comme un moyen discipliné d'être détaillé, prudent et réfléchi.
Demandez-vous maintenant ce que TDD signifie pour vous. TDD est-il la discipline que vous utilisez pour faciliter les choses? Ou est-ce une discipline que vous utilisez pour être réfléchie, prudente et non compliquée?