- Lors d’une conversation récente avec un CEO tech renommé et des ingénieurs, j’ai entendu parler d’une méthodologie de développement logiciel intéressante. Elle m’a amené à réfléchir à d’autres heuristiques et généralisations.
Sa méthode
- Au début de la journée, commencer à travailler sur une fonctionnalité. Si elle n’est pas terminée à la fin de la journée, tout supprimer et recommencer le lendemain. Les tests unitaires écrits peuvent être conservés.
- Si, après plusieurs jours, il est toujours impossible d’implémenter la fonctionnalité, réfléchir aux fondations, à l’infrastructure ou au refactoring qui la rendraient possible, les mettre en place, puis revenir à la fonctionnalité.
- Cette approche ressemble au mouvement de l’Extreme Programming de la fin des années 1990 et du début des années 2000.
Réflexions sur la méthode
« Tout écrire deux fois »
- Conseil donné aux ingénieurs juniors : résoudre le problème, enregistrer le code sur une branche, puis le réécrire.
- Cette méthode a été découverte par hasard après la panne d’un ordinateur portable. La réécriture n’a pris que 25 % du temps de l’implémentation initiale, et le résultat était bien meilleur.
- Avec 1,25 fois plus de temps, on peut obtenir un code d’une qualité deux fois supérieure. Utile pour les projets qui nécessitent une maintenance sur le long terme.
- La méthode « recommencer chaque jour » est encore plus extrême. À chaque réécriture, on finit par trouver une solution plus élégante.
« La quantité a sa propre qualité »
- Une citation de Staline s’applique aussi aux ingénieurs logiciel. Pour un ingénieur junior, les 100 000 premières lignes de code sont indispensables.
- La méthode « recommencer chaque jour » aide à écrire ces 100 000 lignes plus vite.
- Résoudre le même problème de manière répétée est utile pour mémoriser les patterns.
- Avec 5 000 lignes de code parfaites, on peut voir tous les patterns majeurs. Les 95 000 lignes restantes réorganisent les neurones par la répétition.
Comparaison avec l’heuristique du « pistolet sur la tempe »
- À la personne qui propose une solution à un problème, demander : « Si vous deviez le terminer en 24 heures, comment feriez-vous ? »
- Cette méthode casse l’effet de cadrage et le biais d’ancrage. En quelques minutes, elle peut souvent faire émerger un plan qui pourrait se terminer en une journée.
- En pratique, ce n’est pas un plan réellement réalisable en une journée, mais la nouvelle solution peut souvent être terminée en quelques jours.
- Le but de cette expérience de pensée n’est pas de produire une solution réelle, mais d’établir une borne inférieure pour la solution.
Trouver un chemin
- L’essentiel consiste à trouver un chemin dans l’espace du problème. Chaque chemin est une solution, et le rôle de l’ingénieur est de trouver le meilleur chemin.
- Il vaut la peine de réfléchir aux similitudes entre ces heuristiques et les différents algorithmes de pathfinding.
- Il en va de même pour les heuristiques d’ingénierie : devenir un meilleur ingénieur, c’est trouver de meilleurs chemins dans l’espace du problème.
Résumé de GN⁺
- Cet article explore des méthodologies et heuristiques efficaces en développement logiciel.
- La méthode « recommencer chaque jour » et l’approche « tout écrire deux fois » sont utiles pour améliorer la qualité du code.
- La résolution répétée de problèmes aide à la reconnaissance des patterns et à la réorganisation des neurones.
- L’heuristique du « pistolet sur la tempe » est utile pour fixer une borne inférieure de la solution.
- Trouver le meilleur chemin dans l’espace du problème est le rôle central de l’ingénieur.
5 commentaires
Vous êtes fou ? Seules des personnes qui ont un temps fou à perdre peuvent faire ça ; est-ce vraiment quelque chose de réaliste ?
Dans l’environnement SI coréen, ce serait impossible, n’est-ce pas... haha. Peut-être seulement pour un projet perso.
Je n’avais absolument pas pensé à cette approche.
Il faut que j’essaie, haha
Je suis tout à fait d’accord sur la réécriture.
Il m’est arrivé de supprimer par erreur du code sur lequel je travaillais, puis en le réécrivant,
j’ai fini par prendre en compte des éléments que j’avais ignorés au milieu parce que je trouvais trop pénible de modifier la conception,
et au final le résultat était même meilleur.
Commentaires Hacker News
Écrire une nouvelle fonctionnalité deux fois est une bonne stratégie. Mais pour un développeur orienté business ou un chef de projet, cela peut sembler être un retard inutile
La question « et s’il fallait le terminer en 24 heures ? » est une question qu’un chef de projet ne peut pas se permettre de poser
Un bon code s’écrit en choisissant les bonnes abstractions
Avec des collègues compétents, on peut montrer ce qu’il est possible de faire en peu de temps
Je partage l’avis selon lequel il est bon d’écrire le logiciel deux fois
Si l’on n’est pas capable d’implémenter une fonctionnalité même après quelques jours, il faut d’abord mettre en place l’infrastructure ou faire le refactoring nécessaire
« En 24 heures » et « tout écrire deux fois » sont liés
Ce post fait partie des meilleurs « conseils de programmation »
Parfois, il faut laisser tourner un thread en arrière-plan pour résoudre un problème
L’approche suivante est utile