Préférence pour le throwaway code plutôt que les documents de conception

 (softwaredoug.com)
3 points par GN⁺ 2024-12-16 | 1 commentaires | Partager sur WhatsApp

  • Nous imaginons que le développement logiciel suit un flux propre et ordonné

    • on rédige un document de conception, puis on déploie de petites modifications via des PR pour implémenter une fonctionnalité
    • l’historique Git paraît propre et bien rangé
    • mais la réalité est différente

  • Écart entre document de conception et implémentation réelle

    • implémenter à l’identique un document de conception est une illusion
    • une fois le codage commencé, on finit par modifier le contenu du document de conception
    • aucun plan ne survit au contact avec l’ennemi

  • Nouvelle méthodologie de conception : immersion dans le code

    • utiliser des brouillons de PR pour implémenter des prototypes
    • recueillir des retours très tôt afin d’ajuster l’approche
    • documenter les brouillons de PR comme archive historique des idées de conception
    • être prêt à jeter complètement un brouillon de PR
    • faire évoluer progressivement le brouillon de PR vers des PR par étapes
    • tester chaque PR étape par étape et en renforcer la robustesse

  • Importance de la maturité

    • la capacité à abandonner les idées déjà codées est essentielle
    • transmettre la connaissance organisationnelle compte davantage que le nombre de lignes de code
    • s’aligner tôt sur les points importants afin que le travail de prototypage ne soit pas gaspillé

  • Utiliser les PR comme documentation

    • les PR sont l’une des meilleures formes de documentation pour les développeurs
    • les PR sont des artefacts historiques qui reflètent l’état à un moment précis
    • les documents de conception fournissent souvent des informations différentes de la réalité

  • Importance du prototype

    • un prototype vaut plus que 1000 documents de conception
    • pour impulser le changement, il faut le faire avec du code, pas avec des documents
    • l’organisation doit voir les prototypes comme des questions, et non comme des réponses

  • Utilité des documents de conception

    • utiles pour organiser et archiver les retours de diverses parties prenantes
    • utiles lorsque l’idée est trop conceptuelle ou de trop long terme
    • utiles lorsqu’exprimer une idée par écrit est plus efficace que de la coder
    • utiles lorsque l’organisation n’a pas la discipline nécessaire pour abandonner sa première solution
    • ils offrent un cadre où les profils juniors peuvent remettre en question en toute sécurité les idées des développeurs seniors

  • Mauvais usages des documents de conception

    • utilisés pour ralentir le processus chez des développeurs moins expérimentés
    • utilisés comme documentation, mais deviennent vite obsolètes
    • tentent de résoudre tous les problèmes de conception alors que les vrais problèmes se découvrent en codant

  • Si l’équipe peut faire preuve de discipline, bricoler est bien plus efficace que concevoir sur document

    • il est recommandé de construire cette discipline au sein de l’organisation
    • au final, le code a plus de poids que les mots

À lire aussi

1 commentaires

 
GN⁺ 2024-12-16
Avis Hacker News

  • Le prototypage est une partie importante du processus de conception, et il est nécessaire de définir le problème et de clarifier la solution

    • Parfois, un simple document suffit, mais parfois il faut beaucoup de retours et d’itérations
    • Il existe un dicton : « quelques semaines de code peuvent faire économiser quelques heures de planification »

  • L’écriture est utile pour explorer un problème, et certains ont vécu l’expérience de penser avoir compris un problème avant que l’écriture ne fasse surgir de nouvelles questions

    • Cela rappelle le cas d’un mentor qui a utilisé Lucidchart pour expliquer six mois de travail

  • Certains ont déjà utilisé des solutions temporaires pour terminer un projet dans les délais

    • Ces solutions temporaires servent aussi d’outils de support à la production, et sont utilisées comme solution de repli lorsque la version permanente est interrompue

  • Le plus gros problème des documents de conception, c’est que personne ne les lit

    • Le problème du prototypage, c’est que les gens le considèrent comme le code final
    • Certains préfèrent une approche hybride : planifier et documenter de façon rigoureuse, puis écrire du code de prototype d’une qualité suffisante pour être utilisé dans le produit final

  • La différence entre les retours sur le code et sur la conception est importante

    • Les documents de conception poussent à poser la question du « pourquoi » dans l’espace du problème
    • Quand un prototype fonctionne, il devient plus difficile de soulever ces questions

  • Si la description du poste consiste à écrire beaucoup de code pour voir ce qui fonctionne, GPT peut le remplacer plus vite et à moindre coût

    • Obtenir un consensus sur ce qu’il faut construire reste toujours un défi

  • Presque personne n’imagine que le développement logiciel suit un flux propre et bien ordonné

    • Écrire du code ressemble à l’écriture : les brouillons sont toujours mauvais, et les bons textes sont beaucoup retravaillés

  • Certains ont déjà vu du code s’empiler comme un Jenga, au point que plus personne ne veut y toucher

  • Certains préfèrent un processus qui documente les décisions de conception à l’aide d’un fil de commentaires continu

    • Ils utilisent des issues GitHub pour mener ce processus

  • Certains réfléchissent à cette approche, en se disant que dans le pire des cas elle peut faire perdre beaucoup de temps

    • La rédaction d’un document de conception a été la plus utile lorsqu’ils avaient suffisamment réfléchi au problème pour pouvoir préciser les propriétés nécessaires à une implémentation correcte
    • Mettre en œuvre une solution partielle et l’améliorer progressivement a aussi été une approche fructueuse