Question HN : quelle est la meilleure base de code sur laquelle vous avez travaillé ?

• Qu’est-ce qui la rendait si bonne ?
  • Y avait-il quelqu’un pour imposer de bonnes pratiques ?
  • Faisiez-vous partie d’un groupe d’ingénieurs exceptionnels ?
  • Ou bien autre chose ?

L’avis de GN⁺

• Cet article soulève une question intéressante sur la manière dont les bonnes pratiques sont maintenues dans un environnement de développement logiciel
• Il peut aider à comprendre la différence entre l’imposition de bonnes pratiques et un environnement plus autonome
• Parmi d’autres projets dotés de fonctionnalités similaires, on peut citer le système de code review de Google ou le système de pull requests de GitHub
• Lors de l’adoption d’une nouvelle technologie ou de l’open source, il faut réfléchir à la manière dont cela peut s’intégrer à la culture de l’équipe et aux processus existants
• Le maintien de bonnes pratiques est un élément important pour améliorer la productivité de l’équipe et la qualité du code

[GN⁺]

Commentaire Hacker News

• Le monorepo de Google était excellent du point de vue des outils

  • Il était possible de générer un snapshot de toute la base de code en quelques secondes
  • Les builds étaient parfaitement reproductibles et exécutés sur un cluster de build
  • Le langage de configuration des builds était très simple et concis
  • La recherche dans le code était instantanée
  • L’historique des fichiers se chargeait instantanément
  • Le blame par ligne se chargeait en quelques secondes
  • La recherche de symboles était immédiate dans presque tous les fichiers
  • Un style cohérent était imposé par une culture partagée, des linters automatiques et des vérifications avant soumission
  • Des raccourcis permettaient de créer des liens profonds vers un fichier/une version/une ligne, ce qui facilitait le partage de code
  • De nombreuses vérifications avant soumission garantissaient la qualité du code et des tests
  • Les revues de code et l’association avec les tests lors des modifications de code étaient obligatoires

• Le code serveur d’AOL était excellent

  • Il était écrit par des personnes ayant une compréhension approfondie de la programmation Unix et de l’utilisation des boucles d’événements
  • Il était écrit en C, et on s’attendait à ce qu’il tourne pendant des mois sans planter
  • En cas d’arrêt anormal, un backtrace du core était envoyé par e-mail au responsable
  • En cas de fuite mémoire, l’équipe d’exploitation réagissait immédiatement
  • Tout pouvait être rechargé sur le serveur en cours d’exécution sans redémarrage
  • Les serveurs étaient administrés à l’aide d’un port de contrôle TCP et d’un interpréteur TCL
  • Il montait en charge sur des dizaines puis des centaines de machines physiques avec le « No Threads Kernel »
  • Les 200 développeurs Unix partageaient une compréhension commune
  • Des rédacteurs techniques interviewaient les développeurs pour écrire des livres transmissibles aux développeurs externes
  • Le principe consistait à échanger des messages réseau sans rien écrire sur disque

• La base de code de mon précédent emploi était excellente

  • Les ingénieurs étaient très compétents et sans ego
  • L’équipe était composée de 4 seniors et de 3 ingénieurs principal
  • Chaque nouvelle exigence était discutée de manière civilisée
  • Même les membres juniors pouvaient facilement suivre le code existant

• La base de code de Postgres était très bien organisée

  • Il n’était pas nécessaire de s’inquiéter de la sécurité mémoire
  • Les macros étaient utilisées avec soin, dans le respect des humains
  • La base de code de Postgres était considérée comme l’étalon-or du développement
  • Un remerciement était adressé à l’équipe pgrx

• Le framework de tests d’intégration d’un grand service Python était excellent

  • Il était construit au-dessus d’un framework de tests d’intégration existant
  • Il définissait une sémantique claire pour les composants de test
  • Les composants de test étaient construits à partir d’un ensemble initial
  • Les revues de code garantissaient que les nouveaux composants respectaient cette sémantique
  • À long terme, cela n’a pas bien fonctionné

• La base de code Google3 était immense et fonctionnait très bien

  • Les dépendances étaient relancées à chaque modification
  • Les commits étaient des snapshots immuables efficaces
  • C’était bien supérieur à GitHub

• La meilleure base de code était celle que j’ai écrite moi-même

• La base de code de Cocotron était très impressionnante

  • On cherchait comment porter des applications Mac Cocoa vers Windows
  • Une seule personne a implémenté toutes les API essentielles
  • Elle a été utilisée avec succès dans des applications GUI complexes et personnalisées
  • La concentration est importante

• La base de code de Facebook permettait des mises à niveau continues du code

  • Beaucoup d’efforts étaient consacrés à la conception du langage et aux outils
  • Le code existant était continuellement mis à niveau
  • Dans les autres entreprises, il était difficile de passer après une réécriture majeure

• L’API HTTP de CouchDB tenait entièrement dans un seul fichier

  • C’était un bon point de départ pour apprendre les bases de données et la programmation web
  • Elle a ensuite été refactorisée par l’équipe
  • Il était intéressant de voir le passage de l’inspiration à l’usage réel