2.9 Construction logicielle

Vue d’ensemble et motivation

La construction logicielle est où la conception devient du code fonctionnel. C’est le travail détaillé du codage, de la vérification, du test unitaire, du test d’intégration, et du débogage. Le guide Software Engineering Body of Knowledge (SWEBOK) traite la construction comme son propre domaine de connaissance, et pour une bonne raison : c’est là que se passe la plupart de votre travail quotidien. Les choix que vous faites ligne par ligne (comment vous contenez la complexité, comment vous gérez les erreurs, à quel point vous laissez les choses lisibles) décident si un système peut être compris, changé, et digne de confiance pour les années à venir.

Sur une grande équipe, la construction est un effort de groupe, pas solitaire. Des centaines d’ingénieurs écrivent dans une base de code partagée qui survivra au temps de n’importe quelle personne dans l’équipe. Donc la barre n’est pas « est-ce que ça fonctionne sur ma machine aujourd’hui ». C’est « un étranger peut-il changer cela en sécurité dans cinq ans ». La construction se connecte vers le haut aux exigences (chapitre 2.8) et à la conception (chapitre 2.2), qui vous disent quoi construire et sa forme. Elle se connecte latéralement aux normes de codage (chapitre 2.1), au test (chapitre 2.4), et à la revue de code (chapitre 2.5), qui façonnent comment le travail est exprimé, vérifié, et inspecté. Une bonne construction transforme une conception solide en un atout maintenable. Une mauvaise construction transforme même une bonne conception en un passif.

Dans les contextes d’entreprise et gouvernementaux, la construction porte un poids supplémentaire. Ces systèmes sont à longue durée de vie, fortement réglementés, et souvent critiques pour la sécurité ou les citoyens. La programmation défensive, la gestion d’erreurs disciplinée, et le code évidemment correct ne sont pas des gentillesses ici ; ce sont des exigences pour l’assurance, l’audit, et la continuité à travers des décennies et le renouvellement de personnel. L’objectif est du code qui communique son intention, résiste à l’échec, et peut être vérifié. Du code qui fonctionne simplement ne suffit pas.

Principes clés

Minimisez la complexité avant tout ; l’ennemi principal de la construction à grande échelle est le code que personne ne peut pleinement comprendre.
Anticipez le changement ; construisez afin que les modifications futures probables soient localisées et peu coûteuses.
Construisez pour la vérification ; écrivez du code dont l’exactitude est facile à vérifier par les tests, la revue, et le raisonnement.
Réutilisez délibérément ; construisez sur des composants existants dignes de confiance plutôt que de réinventer, mais évitez de coupler aux mauvaises abstractions.
Suivez les normes ; la cohérence à travers une base de code réduit le coût cognitif de chaque futur changement.
Gérez les erreurs et les états invalides explicitement ; rendez les modes d’échec visibles plutôt que silencieux.
Gardez le code lisible ; la construction est de la communication avec les futurs mainteneurs en premier et le compilateur en second.

Recommandations

Minimisez la complexité comme discipline principale

Faites de la réduction de la complexité, essentielle et accidentelle, votre objectif central. Écrivez de petites fonctions et modules à but unique. Préférez des noms clairs aux astuces intelligentes. Gardez l’imbrication peu profonde et le flux de contrôle linéaire. Localisez les décisions afin que comprendre un morceau de code ne vous force pas à tenir tout le système en tête. La complexité est ce qui rend les grandes bases de code lentes à changer et dangereuses à toucher, alors pesez chaque choix selon s’il ajoute de la complexité ou la retire. Appliquez les principes de conception du chapitre 2.2 à petite échelle aussi : haute cohésion, faible couplage, et séparation des préoccupations claire comptent autant dans une seule fonction que dans une architecture.

Construisez pour le changement et pour la vérification

Pensez à l’avance aux changements les plus probables à venir (nouvelles règles métier, nouvelles intégrations, nouvelles réglementations) et isolez-les derrière des interfaces stables afin que le changement reste local. En même temps, écrivez du code facile à vérifier : des fonctions pures (les mêmes entrées produisent toujours la même sortie, sans effets de bord) où vous le pouvez, un état caché minimal, et des dépendances rendues explicites afin que les tests puissent les substituer. Le code difficile à tester est généralement du code difficile à comprendre et à changer. La testabilité (chapitre 2.4) est un signal de conception, pas seulement une préoccupation de QA.

Réutilisez délibérément et standardisez

Tendez la main vers des bibliothèques et composants internes bien maintenus et dignes de confiance avant de réécrire la logique fondamentale, et utilisez-les à travers des interfaces claires (chapitre 2.3). Construisez des composants réutilisables seulement quand un véritable deuxième cas d’usage existe, parce que généraliser trop tôt est sa propre forme de complexité. Appliquez les normes de codage et le style de votre organisation (chapitre 2.1) uniformément, idéalement appliqués par des formateurs et linters automatisés, afin que toute la base de code se lise comme si un seul auteur méticuleux l’avait écrite.

Pratiquez la programmation défensive avec jugement

Validez les entrées aux frontières de confiance (requêtes externes, E/S de fichier et réseau, entrée utilisateur) et traitez toute donnée traversant ces frontières comme hostile jusqu’à preuve du contraire. À l’intérieur d’un module bien testé, cependant, n’étouffez pas chaque ligne dans des contrôles redondants qui cachent la logique et suppriment les vrais échecs. La règle est simple : défendez aux frontières, faites confiance à l’intérieur. Utilisez des assertions pour documenter et appliquer des invariants qui ne devraient jamais être faux dans un programme correct. Utilisez des exceptions et la gestion d’erreurs pour des conditions qui peuvent légitimement se produire à l’exécution. Gardez les deux séparés : les assertions gardent les suppositions du programmeur, la gestion d’erreurs gère l’échec attendu.

Gérez les erreurs explicitement et échouez en sécurité

Pour chaque erreur, décidez délibérément quoi faire : récupérer, retenter, propager, ou échouer rapidement. N’avalez jamais silencieusement une exception ni n’ignorez une erreur retournée ; un échec supprimé revient comme un défaut mystérieux plus tard. Gardez du contexte dans vos messages d’erreur et journaux afin que les échecs puissent être diagnostiqués. Dans les systèmes critiques pour la sécurité et les citoyens, échouez vers un état sûr et connu plutôt que de continuer dans un état corrompu. Donnez au chemin d’erreur autant de réflexion qu’au chemin heureux, parce qu’en production le chemin d’erreur est où la confiance se gagne ou se perd.

Intégrez la qualité pendant la construction

La qualité est intégrée, pas inspectée après coup. Écrivez des tests unitaires aux côtés du code, exécutez l’analyse statique et les linters continuellement, et gardez les fonctions assez petites pour être raisonnées. Utilisez des noms et une structure auto-explicatifs afin que vos commentaires puissent expliquer pourquoi, pas quoi. Refactorisez au fur et à mesure pour garder le code habitable. La revue de code (chapitre 2.5) est le filet humain, mais la plupart de la qualité doit être là avant même que la revue ne commence.

Choisissez et standardisez les outils de construction

Standardisez la chaîne d’outils (compilateurs, systèmes de construction, formateurs, linters, analyseurs statiques, débogueurs, gestionnaires de dépendances, et configurations d’IDE) afin que chaque ingénieur travaille dans un environnement cohérent et reproductible. Câblez ces outils dans le pipeline afin que les contrôles de qualité ne soient pas optionnels. Intégrez délibérément les outils de codage assistés par IA, et traitez leur sortie comme un brouillon qui doit passer les mêmes normes, revue, et tests que tout autre code.

Compromis : avantages et inconvénients

Pratique	Avantages	Inconvénients
Minimisation agressive de la complexité	Lisible, modifiable, faible taux de défauts	Peut sembler lent ; risque de sur-abstraction si mal appliquée
Contrôles défensifs extensifs	Attrape les mauvais états tôt, frontières robustes	Encombre la logique ; peut masquer de vrais bugs si excessif
Assertions pour les invariants	Documente et applique les suppositions	Désactivées dans certaines constructions de production ; pas de la gestion d’erreurs
Forte réutilisation de bibliothèques	Moins de code à posséder ; livraison plus rapide	Risque de dépendance, couplage, exposition de chaîne d’approvisionnement
Normes et linting stricts	Base de code uniforme, à faible friction	Configuration initiale ; peut sembler rigide pour les individus
Construire pour la testabilité	Code vérifiable, modifiable	Peut ajouter une indirection que certains voient comme de la cérémonie

Le compromis central en construction est la vitesse à court terme contre la modifiabilité à long terme. Prendre des raccourcis (sauter la gestion d’erreurs, tolérer la complexité, ignorer les normes) semble plus rapide sur le moment, et c’est presque toujours plus coûteux sur la vie du système. L’échec opposé est la sur-ingénierie : trop de défensive, d’abstraction spéculative, et de généralité dont personne n’a besoin. Une construction habile vit au milieu : aussi simple que possible, aussi défensive que les frontières l’exigent, et pas plus.

Questions à discuter avec votre équipe

Quelle est notre définition partagée et concrète de « trop complexe », et où l’appliquons-nous avant la fusion ? « Minimiser la complexité » est la discipline centrale de la construction, mais comme slogan, elle perd tout argument face à une échéance. Dans une grande équipe où des centaines de personnes écrivent dans une base de code, la complexité doit être mesurable, donc convenez de signaux sur lesquels vous agirez réellement : longueur de fonction, profondeur d’imbrication, complexité cyclomatique, et le nombre de choses qu’un lecteur doit tenir en tête pour comprendre un changement. Apportez votre pire contrevenant à la réunion et demandez si votre revue actuelle l’aurait attrapé. La réponse devrait se transformer en une porte de pipeline ou un élément de liste de contrôle de revue, parce qu’un seuil appliqué par un outil vaut plus qu’un principe appliqué par la volonté, et cela épargne à votre prochaine recrue l’accumulation lente de code que personne ne peut toucher en sécurité.
En production, nos chemins d’erreur se comportent-ils comme nous les avons conçus, et quand avons-nous pour la dernière fois exercé l’un d’eux exprès ? Le conseil de construction dit de donner au chemin d’erreur autant de réflexion qu’au chemin heureux, pourtant le chemin d’erreur est généralement le code le moins testé que vous possédez, et dans un système critique pour les citoyens ou la sécurité, c’est où la confiance se gagne ou se perd. Une exception supprimée ou un code de retour ignoré devient un défaut mystérieux des semaines plus tard, et « échouer vers un état sûr » est une promesse que vous ne pouvez pas tenir si vous ne l’avez jamais vu se produire. Apportez votre historique d’incidents : combien de pannes passées se retracent à une erreur avalée ou un chemin de récupération non testé ? L’action est de tester délibérément l’échec (injectez la carte refusée, le délai d’attente, l’entrée malformée) et d’exiger que chaque erreur soit gérée, journalisée avec contexte, ou propagée, jamais silencieusement abandonnée.
Quelles parties de notre base de code sont difficiles à tester, et que nous dit cette difficulté sur la conception ? Le code qui résiste au test est presque toujours du code qui cache l’état, se couple aux mauvaises dépendances, ou fait trop, donc la testabilité est un signal de conception, pas une réflexion après coup de QA. Sur un système d’entreprise à longue durée de vie, cela compte parce que les modules pénibles à tester aujourd’hui sont ceux qu’un étranger aura peur de changer dans cinq ans. Apportez la classe ou le service pour lequel votre équipe redoute d’écrire des tests et demandez pourquoi : l’état est-il caché, les dépendances sont-elles impossibles à substituer, la fonction fait-elle trois travaux ? La réponse devrait conduire la refactorisation vers des fonctions pures, des dépendances explicites, et de petites unités à but unique, parce que rendre le code vérifiable est le même travail que le rendre compréhensible et peu coûteux à changer.
Quand réutilisons-nous une bibliothèque externe contre construisons-nous la capacité nous-mêmes, et qui possède le risque de chaîne d’approvisionnement que nous prenons ? Tendre la main vers une bibliothèque de confiance est plus rapide que réinventer la logique fondamentale, pourtant chaque dépendance que vous ajoutez est du code que vous ne contrôlez pas, ne pouvez pas facilement auditer, et devez corriger le jour où il est compromis. Sur une grande équipe, le danger est que cent ingénieurs tirent chacun leurs propres dépendances transitives jusqu’à ce que personne ne puisse dire ce que la base de code exécute réellement. Apportez votre inventaire de dépendances et demandez trois choses concrètes : combien de bibliothèques ne sont pas maintenues, combien portent des vulnérabilités connues, et combien enveloppent une logique assez simple pour être possédée entièrement. La considération concurrente est réelle, parce qu’écrire votre propre cryptographie ou gestion de dates est presque toujours pire qu’une bibliothèque éprouvée, donc l’objectif est une politique de réutilisation délibérée plutôt qu’un évitement général. Dans les contextes d’entreprise et gouvernementaux, ajoutez l’angle des marchés publics et de la conformité de licence, puisqu’une dépendance non vérifiée peut porter une licence incompatible avec vos obligations ou une provenance qu’aucun auditeur n’acceptera.
Comment tenons-nous le code généré par IA aux mêmes normes de construction que le code écrit par humain, et pouvons-nous distinguer les deux quand cela compte ? Les assistants de codage IA produisent des brouillons plausibles rapidement, et la tentation est de traiter leur sortie comme finie parce qu’elle compile et semble idiomatique. La règle de ce chapitre est que le code généré passe la même revue, tests, et normes que tout autre, et une grande équipe doit rendre cette règle opérationnelle plutôt qu’aspirationnelle. Apportez des exemples de changements assistés par IA livrés récemment et demandez si chacun portait des tests, a passé l’analyse statique, et a été réellement compris par l’humain qui l’a soumis, ou s’il a été laissé passer sur confiance. La pression concurrente est la vélocité, parce que ces assistants sont réellement productifs et ralentir chaque suggestion jusqu’à un rythme d’escargot gaspille le bénéfice. Dans les contextes réglementés et gouvernementaux, ajoutez l’angle de la provenance et de la responsabilité, parce que vous pourriez devoir attester qui est responsable d’une ligne de code et si un fragment généré porte une question de licence ou de droit d’auteur à laquelle vous ne pouvez pas répondre.
Notre chaîne d’outils de construction est-elle réellement standardisée et appliquée dans le pipeline, ou les individus travaillent-ils encore dans des configurations incompatibles ? Une chaîne d’outils partagée de formateur, linter, analyseur statique, système de construction, et gestionnaire de dépendances laisse un ingénieur se déplacer avec confiance à travers des services non familiers, parce que le code se lit comme une seule voix et les contrôles sont identiques partout. Quand elle dérive, chaque équipe réinvente sa propre configuration, le temps de revue est dépensé à débattre du style, et des défauts que l’analyseur d’une équipe aurait attrapés passent à travers celui d’une autre. Apportez la liste des dépôts qui n’exécutent pas les contrôles standards à chaque commit et demandez pourquoi chacun s’est retiré. La tension est qu’une configuration mandatée unique peut sembler rigide pour des équipes aux besoins réellement différents, alors décidez où l’uniformité vaut la friction et où une exception documentée convient. Pour une grande entreprise ou un organisme public, liez cela à la reproductibilité et l’audit, parce qu’une construction que vous ne pouvez pas reproduire octet par octet depuis une chaîne d’outils contrôlée est une que vous ne pouvez pas défendre devant un évaluateur des années plus tard.

Regard sectoriel

Jeune pousse. La vitesse gagne, alors mettez en place un formateur et un linter partagés dès le premier jour, validez les entrées à votre unique frontière externe, et gardez le code interne propre plutôt que défensif sur chaque ligne. Sautez l’abstraction spéculative et le processus lourd : avec deux ou trois ingénieurs, toute l’équipe tient la base de code en tête, et le vrai risque est la complexité qui survit à cette mémoire partagée. Appuyez-vous sur des bibliothèques de confiance pour tout ce qui est fondamental afin d’écrire aussi peu de code que possible que vous puissiez bien posséder.

Petite entreprise. Sans ingénieur de construction dédié et avec un budget serré, préférez les conventions que vos outils existants appliquent gratuitement : un formateur et un linter livrés avec le langage, des défauts sensés, et un petit ensemble de règles dont tout le monde peut se souvenir. Achetez ou adoptez des bibliothèques bien maintenues plutôt que de construire une infrastructure que vous ne pouvez pas doter en personnel pour maintenir. Dépensez votre discipline limitée sur les deux choses qui font le plus mal quand négligées, valider l’entrée à la frontière et ne jamais avaler une erreur silencieusement.

Grande entreprise. Avec des centaines d’ingénieurs écrivant dans du code partagé, la priorité est l’uniformité et l’application : une chaîne d’outils standard câblée dans le pipeline, des portes d’analyse statique, et des règles de validation de frontière appliquées partout afin que les gens se déplacent avec confiance entre services. Gérez le risque de dépendance et de chaîne d’approvisionnement comme un processus gouverné plutôt qu’une improvisation par équipe, et utilisez des assertions pour encoder les invariants de domaine qui doivent tenir à travers chaque équipe. Traitez les normes de construction comme le substrat qui garde une base de code habitable à travers des décennies et le renouvellement de personnel.

Gouvernement. Les systèmes à longue durée de vie et critiques pour les citoyens font de la construction disciplinée une question d’assurance et de responsabilité. Isolez les règles volatiles comme la législation derrière des interfaces stables afin que le changement reste local et traçable aux exigences, échouez vers des états sûrs et connus plutôt que de continuer dans un état corrompu, et livrez chaque module avec des tests qui doublent comme preuve d’audit. Les obligations de marchés publics et de transparence signifient que votre chaîne d’outils, vos dépendances, et votre gestion d’erreurs doivent être documentées assez bien pour qu’un fonctionnaire qui arrive des années plus tard, ou un auditeur externe, puisse vérifier que le code est correct.

Exemples

Jeune pousse. Une start-up de trois ingénieurs câble un formateur et un linter partagés dès le premier jour et les exécute à chaque commit, donc la base de code se lit comme une seule voix même en ajoutant des prestataires. Ils valident les entrées à leur frontière API et traitent tout ce qui vient de l’extérieur comme hostile, mais gardent la logique interne propre plutôt que de l’étouffer dans des contrôles redondants. Quand un webhook de paiement commence à échouer, la correction est rapide parce qu’aucune exception n’a jamais été silencieusement avalée et le message d’erreur porte assez de contexte pour pointer directement vers la cause. Toute la configuration a pris un après-midi et leur a épargné l’accumulation lente de complexité qui aurait rendu la première semaine de leur prochaine recrue misérable.

Grande entreprise. Une société de paiements mondiale applique une chaîne d’outils partagée à travers des centaines d’ingénieurs : formatage et linting automatisés à chaque commit, portes d’analyse statique dans le pipeline, et une règle que toutes les entrées externes sont validées aux frontières de service. La logique de domaine utilise des assertions pour appliquer des invariants comme « une écriture de grand livre s’équilibre toujours », tandis que des conditions d’exécution comme une carte refusée sont gérées comme des résultats explicites et journalisés. Parce que les normes sont uniformes et les erreurs ne sont jamais silencieusement avalées, les ingénieurs se déplacent avec confiance à travers des services non familiers, et les incidents de production peuvent être diagnostiqués directement depuis les journaux.

Gouvernement. Une agence fiscale nationale construit un système d’évaluation à longue durée de vie censé fonctionner pendant des décennies sous une législation changeante. La construction isole chaque règle fiscale derrière une interface stable, donc les changements législatifs annuels restent locaux et traçables aux exigences (chapitre 2.8). La validation défensive garde chaque entrée face aux citoyens. Les chemins d’erreur échouent vers un état sûr qui n’émet jamais silencieusement une évaluation incorrecte. Chaque module est livré avec des tests unitaires comme preuve d’audit. Parce que la construction est standardisée et bien documentée, de nouveaux fonctionnaires peuvent maintenir en sécurité du code écrit par des prédécesseurs partis depuis longtemps.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

Le retour sur une construction disciplinée est la capacité durable de changer le logiciel à moindre coût et en sécurité, et c’est là que se décide la plupart du coût total de possession d’un système. Les études d’économie logicielle montrent constamment que la plupart du coût de vie d’un système est la maintenance, et le coût de maintenance est dominé par à quel point le code est compréhensible et modifiable. Minimiser la complexité, gérer les erreurs explicitement, et suivre les normes abaissent directement le coût de chaque futur changement et de chaque incident de production.

Le coût d’adoption est modeste et surtout en amont : fixer les normes, câbler les linters et analyseurs, et construire l’habitude d’écrire du code vérifiable et défensif. Le coût de la négligence, en revanche, s’accumule. La complexité s’accumule en code lent à changer et risqué à toucher. Les erreurs silencieuses se transforment en incidents de production coûteux. Le style incohérent multiplie l’effort de chaque revue et chaque intégration. Pour convaincre la direction, reliez la qualité de construction au taux d’échec des changements, au temps moyen de rétablissement, au taux d’échappement de défauts, et au temps d’intégration, tous que la discipline de construction améliore directement.

Anti-patterns et pièges

La montée de complexité : accumuler du code astucieux, profondément imbriqué, ou tentaculaire jusqu’à ce que personne ne le comprenne.
L’avalage silencieux d’erreurs : des blocs catch vides et des codes de retour ignorés qui transforment les échecs en futurs mystères.
L’excès de programmation défensive : des contrôles redondants partout qui enterrent la logique et masquent de vrais défauts.
Confondre les assertions avec la gestion d’erreurs : utiliser des assertions pour des conditions d’exécution, ou des exceptions pour des invariants de programmeur.
La construction par copier-coller : dupliquer la logique au lieu de réutiliser, donc les corrections doivent être faites à de nombreux endroits.
La généralité spéculative : construire des abstractions et de la configurabilité pour des besoins qui n’arrivent jamais.
Ignorer les normes : chaque ingénieur codant à sa façon, multipliant la charge cognitive à travers la base de code.
La construction non testée : écrire du code sans tests accompagnants, différant la vérification à une phase qui n’arrive jamais.

Modèle de maturité

Niveau 1 (Initiation) : La construction est ad hoc et réactive ; la complexité et la gestion d’erreurs varient par individu ; peu de normes existent, et les échecs silencieux sont courants.
Niveau 2 (Développement) : Des normes de codage, formateurs, et linters existent, et une gestion d’erreurs de base et des tests unitaires sont attendus, mais la pratique est incohérente et chaque équipe l’applique différemment.
Niveau 3 (Standardisation) : La minimisation de complexité, la validation de frontière, la gestion d’erreurs explicite, et la testabilité sont documentées et appliquées à l’échelle de l’organisation, dans le pipeline et en revue, afin que toute la base de code se lise comme si un seul auteur méticuleux l’avait écrite.
Niveau 4 (Gestion) : La qualité de construction est mesurée par rapport à des références ; l’équipe suit la complexité cyclomatique, le taux d’échappement de défauts, le taux d’échec des changements, la couverture de test du chemin d’erreur, et les conclusions de revue de code, et agit sur les tendances plutôt que l’opinion.
Niveau 5 (Orchestration) : La construction est continuellement améliorée et intégrée à travers l’organisation ; les modèles défensifs, les normes, et les métriques alimentent la refactorisation et l’outillage ; les outils assistés par IA fonctionnent sous les mêmes portes de qualité, et la pratique s’adapte à mesure que les langages, réglementations, et risques changent.

Pistes de réflexion

Où la complexité accidentelle s’accumule-t-elle le plus dans votre base de code, et quelles habitudes de construction la créent ?
Quelle est la règle réelle de votre équipe pour où valider les entrées et où leur faire confiance ?
Vos ingénieurs distinguent-ils les assertions de la gestion d’erreurs, et cette distinction est-elle cohérente ?
Combien de votre qualité est intégrée pendant la construction contre attrapée plus tard en revue ou en test ?
Comment décidez-vous quand réutiliser une bibliothèque contre construire, étant donné le risque de chaîne d’approvisionnement ?
Comment le code généré par IA devrait-il être tenu aux mêmes normes de construction que le code écrit par humain ?

Points clés à retenir

La construction est où la conception devient du code maintenable ; minimiser la complexité est sa discipline centrale.
Construisez pour le changement et pour la vérification : le code testable et modifiable est du code compréhensible.
Défendez aux frontières de confiance, faites confiance à l’intérieur, et n’avalez jamais les erreurs silencieusement.
Utilisez des assertions pour les invariants et la gestion d’erreurs pour les conditions d’exécution attendues ; ne les confondez pas.
Standardisez les outils et le style, réutilisez délibérément, et intégrez la qualité plutôt que de l’inspecter après coup.

Références et lectures complémentaires

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), domaine de connaissance Construction Logicielle
Steve McConnell, Code Complete: A Practical Handbook of Software Construction
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Andrew Hunt et David Thomas, The Pragmatic Programmer
Martin Fowler, Refactoring: Improving the Design of Existing Code
John Ousterhout, A Philosophy of Software Design