En 2024, ma manière de programmer

 (akkartik.name)
2 points par GN⁺ 2024-08-06 | 1 commentaires | Partager sur WhatsApp
  • L’auteur explique qu’il a beaucoup parlé de la manière de choisir des programmes durables et de construire une infrastructure fiable, tout en reconnaissant qu’il n’y parvient toujours pas très bien
  • Au cours du dernier mois, il a réécrit le cœur d’un programme utilisé depuis deux ans, ce qui l’a amené à revenir sur l’évolution de sa façon de programmer au fil de sa vie

2015

  • Il se méfiait des abstractions et accordait une grande importance aux tests et au contrôle de version
  • Il pensait que les problèmes venaient d’un usage excessif des abstractions et d’un manque de tests / de gestion de versions
  • Il a conçu la plateforme Mu1 en faisant des tests et des couches des contraintes de base

2017

  • Début de la refonte de Mu1 vers l’actuel Mu
  • Au départ, il a utilisé toutes les nouvelles idées autour des tests et des couches, puis a progressivement cessé de les employer
  • Mu contient de nombreux tests, mais selon des méthodes classiques, et l’infrastructure en couches n’a pas été portée

2022

  • Début du travail sur Freewheeling Apps
  • Il a commencé sans tests, puis a écrit des tests approfondis pour les parties centrales de l’éditeur de texte
  • Le reste était difficile à tester, mais fonctionnait bien

2024

  • Il a supprimé tous les tests il y a un mois
  • Il a radicalement retravaillé l’éditeur de texte d’une manière qui l’inquiétait auparavant à cause des conflits de fusion avec d’autres Freewheeling Apps
  • Il a cessé de se soucier du contrôle de version
  • En abandonnant les tests et les versions, il a fini par produire un programme bien meilleur

Vision unifiée actuelle d’une programmation durable

  1. Construire de manière durable pour beaucoup de gens est trop difficile, donc il ne faut même pas essayer
  2. La plupart des logiciels sont contaminés par l’incitation à servir beaucoup de monde à court terme. Il faut se concentrer sur des logiciels avec peu de logos, faciles à construire, avec peu de dépendances et sans mises à jour automatiques
  3. De petits changements de contexte peuvent modifier fondamentalement l’adéquation d’un programme à son contexte
  4. Un nouveau programme s’avance toujours, d’une manière ou d’une autre, vers l’inconnu. Souvent, on ne sait pas exactement ce qu’on fait, quelle que soit la direction prise
  5. Les types, les abstractions, les tests, les versions, les machines à états, l’immutabilité, l’analyse formelle, etc. sont des outils utilisables sur un terrain peu familier
  6. Il est inévitable d’abuser de certains de ces outils. Leur usage idéal est bien plus limité que nous le pensons. Leur surutilisation constitue une dette technique
  7. Une fois la compréhension du contexte stabilisée, il peut être utile de jeter une grande partie du programme et de recommencer depuis zéro
  8. Avant de réécrire, il faut avoir en tête d’un seul coup tout ce qu’on attend du programme et tous les scénarios qu’il doit gérer
  9. Il faut tout construire d’un seul tenant
  • Les tests et le contrôle de version empêchent d’atteindre la fin de cette évolution
  • Les tests font oublier les préoccupations et le contrôle de version pousse à rester attaché au passé

L’avis de GN⁺

  • Quand un programme devient trop complexe, il peut devenir impossible de tout garder en mémoire à l’étape 8. Cela vaut pour la plupart des logiciels, surtout ceux écrits par plus d’une personne
  • Tous les logiciels n’ont pas nécessairement besoin d’atteindre l’étape 9. Beaucoup de Freewheeling Apps sont suffisamment simples et évoluent assez lentement pour se stabiliser sans bug avec seulement quelques utilisateurs, quels que soient les choix de conception initiaux
  • La conception orientée données est clairement utile pour atteindre l’étape 9. Ce n’est pas un outil à appliquer aveuglément, mais une manière de penser qui regarde la vue d’ensemble de la façon dont un programme accède aux données, au-delà des choix immédiats de structures de données
  • Ces étapes ne sont peut-être pas entièrement justes. L’auteur sous-estime peut-être des outils avec lesquels il a moins d’expérience
  • Il se demande quelles étapes pourraient exister au-delà de celles-ci

À lire aussi

1 commentaires

 
GN⁺ 2024-08-06
Avis Hacker News

  • Sans tests, on ne voit pas les problèmes, ce qui donne l’impression qu’ils disparaissent

    • Avec des tests, on a toujours trouvé des bugs
    • Supprimer les tests, c’est se mentir à soi-même
    • Après avoir lu la page, on a l’impression que l’auteur est fatigué de la gestion des variations/de la configuration
    • Il faut beaucoup d’utilisateurs pour gagner de l’argent

  • En renonçant aux tests et aux versions, on a obtenu un meilleur programme

    • En 2024, il est difficile de comprendre qu’on n’utilise pas de gestion de code source
    • Pouvoir travailler sur plusieurs appareils, consulter l’historique, revenir en arrière et créer des branches est extrêmement utile

  • Au départ, je pensais que l’auteur avait tort, mais il y a de bonnes intuitions

    • Ce workflow convient bien à l’auteur
    • Il a probablement déjà vécu des situations où Git ou les tests automatisés réduisaient la productivité
    • Il existe aussi des alternatives simples (par ex. : Dropbox, FTP)
    • L’auteur aime créer de petits programmes
    • Les tests automatisés sont utiles, mais dans son cas leur valeur peut ne pas apparaître

  • La gestion de versions et les tests automatisés résolvent de vrais problèmes

    • De nos jours, démarrer un projet sans gestion de versions est une folie
    • Les tests automatisés sont une bonne pratique essentielle
    • Dans le cas d’usage précis de l’auteur, cela peut être raisonnable

  • Quand on écrit/refactorise un gros programme, il est important d’écrire, jeter, puis réécrire

  • Cet article est déroutant

    • Je me demande pourquoi il a été le premier à recevoir autant de votes positifs

  • De petits changements peuvent profondément modifier l’adéquation d’un programme

    • Il y a l’exemple de K9 Mail
    • K9 Mail a commencé avec une interface non conventionnelle
    • Beaucoup d’utilisateurs se sont plaints de la nouvelle interface
    • Un petit changement a détruit l’adéquation de l’application
    • On utilise encore l’ancienne version

  • Créer un logiciel seul et le créer en équipe, ce sont deux choses totalement différentes

    • Les tests sont un moyen, pas une fin
    • Quand on est confiant, on fait moins de tests
    • On ajoute des tests d’intégration sur les parties importantes
    • Les tests unitaires sont utiles pour concevoir une nouvelle API

  • On a commencé à travailler sur Freewheeling Apps en 2022

    • L’absence de tests était frustrante
    • Une suite de tests donne la confiance nécessaire pour faire évoluer le système
    • Quand la complexité fonctionnelle augmente, les tests deviennent plus difficiles
    • En 2024, tous les tests ont été supprimés
    • Cette philosophie ne s’applique qu’à une seule personne

  • Je ne suis pas d’accord avec l’idée que de petits changements peuvent profondément modifier l’adéquation d’un programme

    • Le court-termisme consiste précisément à s’adapter à de petits changements

  • J’aime l’auteur et j’aime le projet Mu

    • C’est une machine Lisp moderne

  • Je suis dépassé par la complexité du génie logiciel

    • Rejeter toutes les idées n’est pas une solution
    • Il faut écrire des tests, utiliser un VCS et recourir à des abstractions
    • Il faut savoir pourquoi on les utilise, et s’il n’y a pas de raison, il faut réévaluer leur usage