J'étudiais encore le génie logiciel lorsque je suis entré en contact avec Théorie de la vitre brisée. Même si je ne me souviens pas quand j'en ai entendu parler pour la première fois, cela m'a laissé une impression durable. La théorie provient d'une expérience réalisée à la fin des années 60, dont vous trouverez toutes les informations dans un excellent article que NPR a créé.
En résumé, les chercheurs ont placé deux voitures, dépouillées de leur plaque d'immatriculation, dans deux zones différentes : la première dans un quartier problématique de New York et la seconde dans un quartier riche de l'État de Californie. La première voiture a été vandalisée quelques minutes après avoir été abandonnée, tandis que la seconde est restée seule pendant quelques jours. Les chercheurs ont alors décidé de casser une vitre de la deuxième voiture. Quelques minutes plus tard, quelqu'un a commencé à voler les pièces de la voiture, qui est rapidement devenue aussi détruite que la première.
Récemment, j'ai partagé cette histoire avec un de mes collègues lors d'une pause-café. Quelques jours plus tard, il m'a dit qu'il appliquait maintenant cette philosophie à son style de codage et de révision de code. C'était de la musique à mes oreilles, car c'est quelque chose que j'essaie toujours de transmettre aux équipes avec lesquelles je travaille.
Jetons un coup d'œil au morceau de code suivant, trouvé dans une base de code que j'ai trouvée et avec laquelle je travaille actuellement.
L'objectif n'est pas d'examiner les raisons pour lesquelles nous avons abouti à une solution aussi compliquée, mais plutôt de nous mettre à la place du développeur à qui on a demandé de modifier quelque chose.
Maintenant, posez-vous les questions suivantes :
Une réponse honnête indiquera non sur les deux questions. Le code surcomplexe est quelque chose que nous, les développeurs, avons l'habitude de trouver. Nous savons par cœur qu'il faut du temps pour comprendre et modifier le code.
Examinons maintenant une version remaniée du code précédent et posons les deux mêmes questions.
Il est de loin plus facile de modifier ce morceau de code que de modifier le précédent. Et contrairement à ce qui se passe habituellement dans l'esprit d'un développeur, lorsque les délais sont serrés, il est utile de garder une base de code petite et bien organisée.
Souvent, nous ne pensons pas à la façon dont le maintien du code en bon état constitue un avantage pour les autres personnes travaillant sur le projet. Mais un projet avec un code bien écrit incitera tout le monde à imiter le comportement, à suivre les conventions et à fournir un code de qualité similaire. S'il n'y a pas de vitres cassées sur le projet, les gens seront moins tentés d'en casser une.
L'avantage de favoriser un comportement de fenêtre ininterrompu est qu'en fin de compte, il se propagera dans l'ensemble équipe de développement logiciel, et impacter tous les projets de l'entreprise. Espérons que cela fonctionnera également comme un signe pour les autres départements et que la philosophie sera adoptée en dehors du domaine de la base de code de l'entreprise.
L'expérience des vitres brisées me vient à l'esprit de temps en temps, car elle illustre l'importance des comportements mineurs pour éviter les problèmes liés à l'échelle et, en fin de compte, la chute des systèmes dans le chaos. C'est l'une des règles qui vaut la peine d'être respectée.
Vous avez trouvé cet article intéressant ? Ceux-ci vous plairont peut-être aussi !
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
