12. Code bordélique: une fatalité ? 🐷
Cette semaine, dans le SAV de la Tech, on répond à la question d'Audrey:
"Bonjour,
En tant que développeuse, je me suis toujours efforcée de suivre les meilleures pratiques, en m'assurant d'écrire du code propre et bien organisé. Cependant mes collègues ne partagent pas cette rigueur. Ils ont tendance à écrire du code de manière désordonnée, sans se soucier des standards de qualité, ce qui me fait souvent paraitre lente lorsque je dois éditer leur code car il est peu maintenable.
Cette situation est source de frustration pour moi. Non seulement elle rallonge mon temps de travail, car je dois souvent retravailler leur code lorsque je dois le modifier pour ajouter une feature, mais elle me met également dans une position inconfortable. Je crains que mes propositions ne soient perçues comme une critique personnelle, ce qui pourrait nuire à l'ambiance de travail et à mes relations avec mes collègues. De plus ce n'est absolument pas récompensant car mon code fonctionne bien, et le leur bug régulièrement, et de plus ils en sont récompensés car ils résolvent plus d'incidents de prod que moi...
Je suis convaincue que le maintien d'un code propre est essentiel, non seulement pour l'efficacité du développement, mais aussi pour la pérennité du projet sur le long terme. Cependant, je me sens impuissante face à cette culture de l'à-peu-près qui semble ne pas être simplement limitée à mon équipe mais dans l'ensemble du monde du développement.
Auriez-vous des conseils pour m'aider à naviguer dans cette situation difficile ? Je suis pas seulement à la recherche de stratégies pour promouvoir le clean code mais aussi pour, moi aussi trouver l'état d'esprit me permettant de développer des solutions quick-and-dirty et progresser dans une codebase désorganisée.
Merci pour votre aide !"
Épisode enregistré en Janvier 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
Ressources mentionnées dans l'épisode
(🫣 À lire après écoute de l'épisode !)
- Mes collègues veulent pas s’améliorer 😶🌫️ (épisode)
- Clean Code: Guide proposé par Robert C. Martin pour que le code qu'on écrit soit plus facile à lire et à maintenir dans la durée.
- Comment faire du pair programming ? 👯 (épisode)
- Complexité Accidentelle: Complexité introduite dans des programmes informatiques non en raison de la complexité du problème, mais de manière accidentelle en raison de choix de développement non pertinents.
- Root Cause Analysis: L'analyse de cause racine est une démarche de résolution de problème partant du constat qu'il est plus judicieux de traiter les causes d'un problème que d'en traiter les symptômes immédiats. En effet, l'analyse des causes d'un problème permet d'en déterminer une solution définitive, et donc, empêcher qu'il ne se reproduise de nouveau.
- Boyscout Rule: Leave your code better than you found it.
- Pompier Pyromane: Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.
- Diagramme de séquence (UML): Représenter les interactions entre composants aide à mieux comprendre une codebase compliquée.