- J’essaie d’améliorer mes compétences en conception logicielle, et on m’a conseillé d’étudier des bases de code existantes bien conçues
- Je me demande quelles bases de code accessibles publiquement sont considérées comme l’étalon-or en matière de conception logicielle
1. Bases de code recommandées
- Grands projets / projets de référence
- Git, Postgres, CPython
- le « lieutenants model » du noyau Linux
- UNIX v6, les BSD
- Frameworks / bibliothèques
- Systèmes / serveurs
- Jeux / cas particuliers
- Ressources pédagogiques / d’apprentissage
- Autres
- Monocypher (bibliothèque de chiffrement)
- l’implémentation du langage Tcl
2. Lecture de code vs apprentissage par la documentation / la conception
- Les limites du code seul
- une base de code montre l’implémentation, mais masque souvent l’intention de conception et les compromis
- L’importance des documents de conception
- les traces de décision comme les ADR (Architectural Decision Records), les RFC de Rust ou les PEP de Python sont bien plus utiles pour apprendre la conception
- rédiger soi-même des documents de conception peut aussi constituer un excellent entraînement
- Livres et références recommandés
3. Une approche d’apprentissage centrée sur la pratique
- Expérience et essais-erreurs
- on apprend la conception en rencontrant les problèmes de manière répétée, puis en apprenant à les éviter
- lire du code ne suffit pas ; on progresse surtout en écrivant soi-même du code et en résolvant ses échecs
- Apprentissage guidé par l’intérêt
- on apprend plus en profondeur quand on construit un projet qui nous intéresse réellement
- Un coût de l’échec relativement faible
- contrairement à l’ingénierie physique, le coût de l’échec en logiciel est plus faible, ce qui rend l’apprentissage par tentative et erreur particulièrement efficace
4. Débat sur la nature de l’ingénierie logicielle
- La thèse d’une ingénierie encore immature
- si cinq ingénieurs proposent cinq solutions différentes, cela peut être vu comme le signe d’une discipline encore immature en tant qu’ingénierie
- La thèse d’un domaine propice à l’expérimentation
- le logiciel est moins contraint, ce qui autorise de nombreuses solutions ; contrairement à l’ingénierie physique, il n’existe pas toujours une réponse unique
- À la frontière entre art et ingénierie
- la conception peut aussi relever d’une pratique artistique, avec une dimension esthétique, tout en restant de l’ingénierie lorsqu’elle répond à des exigences fonctionnelles
- le logiciel se situe entre flexibilité artistique et rigueur d’ingénierie
5. Méthodes d’apprentissage alternatives
- Analyser du mauvais code
- corriger une base de code mal conçue peut être tout aussi formateur qu’étudier du bon code
- Apprendre à partir de sa propre base de code
- beaucoup considèrent la base de code de leur propre équipe comme la meilleure source d’apprentissage
- mais si le code de l’équipe est mauvais, il est utile de le compléter par des exemples externes
- Apprentissage adapté au domaine
- le plus efficace est de lire des bases de code proches du type de problème que l’on veut résoudre
Principaux enseignements
- les bases de code bien conçues sont utiles, mais l’apprentissage doit aller de pair avec la compréhension des intentions de conception et l’expérience des essais-erreurs
- plus que la simple lecture de code, ce sont surtout les documents de conception et les traces de décision qui servent de ressources d’apprentissage clés
- des projets de très haute qualité comme Git, Postgres, CPython ou la bibliothèque standard de Rust ont une forte valeur pédagogique
- sur le long terme, apprendre à partir de mauvais code et de son propre code est souvent plus concret que de ne regarder que du bon code
Résumé des principaux commentaires
Recommandations de bases de code représentatives (CraigJPerry)
- Serveur mail Postfix
- son architecture centrée sur la sécurité montre une structure proche des microservices avant même que le terme existe
- là où les microservices modernes mettent l’accent sur la distribution à grande échelle dans de grandes organisations, Postfix a été conçu pour la sécurité et la simplicité
- Spring Framework
- on y retrouve une culture qui prend profondément en compte les besoins des développeurs Java en environnement d’entreprise
- c’est un bon exemple d’approche de conception orientée utilisateur
- Git
- une fois compris le concept de base de données objet (blob, tree, commit) et celui de référence, le reste n’est qu’une extension progressive
- l’extension cohérente d’un noyau de concepts est présentée comme un bon exemple de conception
- Varnish
- un reverse proxy haute performance, avec une base de code suffisamment bien structurée pour servir aussi d’outil d’apprentissage
- Lieutenants Model du noyau Linux
- ce n’est pas une base de code à proprement parler, mais c’est une référence utile pour la gestion de logiciels à grande échelle
- il ne s’agit pas seulement de « code bien conçu », mais de cas où les décisions de conception laissent une forte impression
L’importance d’apprendre à partir de bases de code réelles en entreprise (crystal_revenge)
- la plus grande valeur pédagogique se trouve souvent dans la base de code de sa propre équipe
- c’est dans le lien souvent chaotique entre exigences réelles et implémentation qu’on fait l’expérience simultanée des bons et des mauvais choix
- parmi les contraintes du réel, la plus importante est souvent la pression du temps ; l’essentiel est donc d’apprendre à équilibrer conception idéale et réalité
- un bon logiciel est avant tout un logiciel qui répond aux besoins des utilisateurs, et l’expérience répétée aide à concevoir avec plus de chances de succès
Discussions passées et liens utiles (sprobertson)
- le même sujet a été abordé plusieurs fois sur HN
Code vs documents de conception (alphazard)
- une base de code n’est que le résultat d’une implémentation, pas la conception elle-même
- pour apprendre la conception, rédiger des documents de design est plus efficace
- un document doit être suffisamment clair pour qu’une autre personne puisse l’implémenter tel quel
- lister les alternatives et expliquer pourquoi elles ont été écartées constitue une preuve du travail de conception
- un bon concepteur est quelqu’un qui explore un espace de conception plus large puis choisit le bon point d’équilibre
L’importance de comprendre l’ensemble du système (RossBencina)
- le processus consistant à comprendre une base de code dans son ensemble a énormément de valeur
- cela ne sert pas seulement à lire du code bien conçu, mais aussi à apprendre à voir la vue d’ensemble d’un système
- visualiser les relations via des diagrammes, par exemple en UML, peut aider
- approche recommandée pour apprendre :
- lire le code de logiciels similaires à ce que l’on développe soi-même est particulièrement efficace
- comme point de départ, il recommande du code dans un domaine déjà familier (framework web, serveur web, bibliothèque standard Python, VSCode, etc.)
- il vaut mieux commencer par de petits programmes ou des domaines connus
Les critères d’une bonne conception (mamcx)
- une bonne conception correspond à des objectifs et des idées ; la base de code ne montre que le degré de leur implémentation
- une bonne conception ne se résume pas à des adjectifs comme « rapide » ou « sûr » ; elle doit inclure des considérations concrètes et la trace des compromis
- on peut observer ces caractéristiques dans des cas comme Erlang, les premières versions de Pascal ou la conception de nombreux SGBDR
- la bibliothèque standard de Rust, qui met l’accent sur la sécurité et la cohérence, est une bonne ressource d’apprentissage car le code et la documentation reflètent fidèlement ces priorités
Les décisions de conception invisibles (ben30)
- dans une base de code bien conçue, le plus important est souvent ce qui ne se voit pas
- exclure la complexité, éviter les abstractions inutiles ou refuser certains patterns sont des décisions d’absence essentielles
- pour conserver ce contexte, il recommande d’utiliser des ADR (Architectural Decision Records)
- ils permettent d’enregistrer les alternatives, les raisons de leur rejet et les fondements du choix retenu
- cela aide énormément les futurs mainteneurs, mais aussi les outils d’IA
- pour apprendre, il est donc efficace d’examiner non seulement le code, mais aussi les documents de décision de conception comme les ADR, RFC ou PEP
Aucun commentaire pour le moment.