“The Pragmatic Programmer” est une bible pour les développeurs. Il est l’œuvre d’Andrew Hunt et Dave Thomas d’après leurs expériences en tant que développeurs. Leur objectif est simple, faire du lecteur un Pragmatic Programmer, un développeur fier de son travail et qui utilise les meilleures techniques à sa disposition pour faire un travail de qualité.

J’ai vraiment apprécié ce livre facile à lire, rempli de métaphores et tellement inspirant. Il donne envie d’appliquer dans notre quotidien professionnel tous les bons conseils et techniques que les auteurs nous donnent.

Pour chacune de mes lectures, j’essaierais de faire un résumé des points importants à retenir afin que ces lectures ne soient pas perdues.
Pour le résumé de “The Pragmatic Programmer”, je vais reprendre les “tips” qui accompagne les 46 items.

Tips :

1. Care About Your Craft Pourquoi passer son temps à développer des logiciels si on ne prend pas le soin de le faire bien ?
2. Think! About Your Work Désactiver le pilote automatique et prenez le contôle. Ayez un sens critique et réévaluez constamment votre travail.
3. Provide Options, Don’t Make Lame Excuses Au lieu de fournir des excuses, proposez des solutions de contournement. Au lieu de dire que c’est impossible, expliquez ce qu’il est possible de faire à la place.
4. Don’t Live with Broken Windows Améliorer les mauvais choix de conception, les mauvaises décisions et le code “sale” quand vous tombez dessus.
5. Be a Catalyst for Change Vous ne pouvez pas imposer le changement aux personnes. Montrez leur plutôt comment pourrait être le futur et encouragez-les à participer à sa création.
6. Remember the Big Picture Ne restez pas le “nez dans le guidon” et levez la tête pour voir ce qui se passe autour de vous.
7. Make Quality a Requirements Issue Impliquez vos utilisateurs à définir le niveau réel de qualité du projet.
8. Invest Regularly in Your Knowledge Portfolio Apprendre doit devenir une habitude, un réflexe.
9. Critically Analyze What You Read and Hear Ne vous laisser pas influencer par les vendeurs, “buzzs” médiatiques, ou dogmes. Analyser les informations dans votre contexte et celui de votre projet.
10. It’s Both What You Say and the Way You Say It De bonnes idées ne sont rien sans une communication efficace.
11. DRY - Don’t Repeat Yourself Chassez la duplication. Chaque connaissance, au sens large, doit avoir une représentation unique, non ambigu et faisant référence pour tout le système.
12. Make It Easy to Reuse Si votre code est facilement réutilisable, il sera réutilisé. Créer un environnement qui encourage la réutilisabilité.
13. Eliminate Effects Between Unrelated Things Concevez des composants indépendants et qui ont un but unique et bien défini.
14. There Are No Final Decisions Aucune décision n’est gravé dans la pierre. Voyez-les plutôt comme inscrites dans du sable à la plage et préparez-vous aux changements.
15. Use Tracer Bullets to Find the Target L’utilisation de “balles traçantes” permet de raffiner vos idées en essayent des choses et en voyant comment elles se comportent en situation réelle.
16. Prototype to Learn Le prototypage est une expérience d’apprentissage. Sa valeur n’est pas dans le code que vous produisez mais dans les leçons que vous pouvez en tirer.
17. Program Close to the Problem Domain
Concevez et codez dans le langage de vos utilisateurs.
18. Estimate to Avoid Surprises
Estimer avant de commencer. Vous ferez remonter les problèmes potentiels à la surface
19. Iterate the Schedule with the Code
Utiliser l’expérience acquise au cours du projet pour affiner vos estimations.
20. Keep Knowledge in Plain Text
Contrairement à des formats fermés, le “plain text” ne peut devenir obsolète. De plus, il facilite le debuggage et les tests.
21. Use the Power of Command Shell
Ne sous-estimez pas la puissance des commandes Shell face aux interfaces graphiques.
22. Use a Single Editor Well
L’éditeur de texte devrait être une extension de vos mains. Assurez-vous que votre éditeur est configurable, extensible et programmable.
23. Always Use Source Code Control
Un gestionnaire de versions est une machine à voyager dans le temps pour votre travail : vous pouvez revenir dans le passé.
24. Fix the Problem, Not the Blame
Peu importe si un bug est votre faute ou celle d’un autre, ça reste toujours votre problème et il nécessite toujours d’être corrigé.
25. Don’t Panic When Debugging Prenez une grosse inspiration et réfléchissez sur la cause du bug.
26. “select” Isn’t Broken
Il est rare de trouver un bug dans le système d’exploitation ou dans le compilateur, ou même dans une bibliothèque tierce. Le problème est plus vraisemblablement dans l’application.
27. Don’t Assume It, Prove It
Prouver vos intuitions dans l’environnement du projet avec les données réelles et les conditions limites.
28. Learn a Text Manipulation Language
Vous passez la majeure partie de votre journée à travailler avec du texte. Pourquoi ne pas laisser l’ordinateur en faire un peu à votre place ?
29. Write Code That Writes Code
Les générateurs de code augmente votre productivité et évite la duplication d’information.
30. You Can’t Write Perfect SoftwareIl n’y a pas de logiciel parfait. Protéger votre code et les utilisateurs des inévitables erreurs.
31. Design with Contracts
Utiliser la notion de contrat comment documentation et pour vous assurer que votre code ne fasse ni plus ni moins que ce qu’il prétend.
32. Crash Early
Un programme mort fait normalement moins de dégât qu’un programme estropié.
33. Use Assertions to Prevent the Impossible
Une assertion valide vos hypothèses. Utilisez-les pour protéger votre code d’un monde incertain.
34. Use Exceptions for Exceptional ProblemsRéservez les exceptions aux choses exceptionnelles.
35. Finish What You Start
Quand c’est possible, une routine ou un objet qui alloue une ressource devrait aussi être responsable de sa désallocation.
36. Minimize Coupling Between Modules
Évitez le couplage en écrivant du code “timide” et en appliquant la Loi de Déméter.
37. Configure, Don’t IntegrateImplémentez les choix de technologies pour une application avec des options de configuration plutôt que par de l’intégration.
38. Put Abstractions in Code, Details in Metadata
Programmez pour le cas général et placer les spécificités en dehors du code compilé.
39. Analyze Workflow to Improve Concurrency
Utiliser la concurrence pour améliorer les flux de votre application.
40. Design Using Services
Concevez en termes de services : des objets indépendants, concurrents derrière des interfaces bien définies et cohérentes.
41. Always Design for ConcurrencyAutorisez l’accès concurrent et vous concevrez des interfaces plus propres avec moins d’hypothèses.
42. Separate Views from Models
Gagnez en flexibilité facilement en concevant vos applications en termes de modèles et de vues.
43. Use Blackboards to Coordinate Workflow
Utiliser des “tableaux noirs” permet de coordonner des faits et des agents très différents tout en maintenant l’indépendance et l’isolation des différents participants.
44. Don’t Program by Coincidence
Ne compter que sur des choses fiables. Méfiez-vous des complexités accidentelles et ne confondez pas une heureuse coïncidence avec un plan bien déterminé.
45. Estimate the Order of Your Algorithms
Ayez une idée de combien de temps vont prendre vos routines avant de les écrire.
46. Test Your Estimates
L’analyse mathématique de vos algorithmes ne vous dit pas tout. Essayez de mesurer votre code dans l’environnement cible.
47. Refactor Early, Refactor Often
Tout comme réarranger un jardin et enlever la mauvaise herbe, réécrivez, retravailler et revoyez l’architecture de votre code quand c’est nécessaire. Attaquez-vous à la racine du problème.
48. Design to Test
Commencer à réfléchir aux tests avant d’écrire la moindre ligne de code.
49. Test Your Software, or Your Users Will
Tester impitoyablement. Ne laissez pas les utilisateurs trouver les bugs pour vous.
50. Don’t Use Wizard Code You Don’t Understand
Les assistants peuvent générer des portions de code. Soyez sûr de les comprendre dans leur globalité avant de les intégrer dans votre projet.
51. Don’t Gather Requirements, Dig for Them
Les besoins émergent rarement tous seuls. Ils sont souvent enfouis sous des couches d’hypothèses, de méconnaissance et de politique.
52. Work with a User to Think Like a User
C’est la meilleure façon de voir comment un système est utilisé dans des conditions réelles.
53. Abstractions Live Longer than Details
Investissez dans l’abstraction, pas dans l’implémentation. Les abstractions peuvent survivre aux changements d’implémentations et de technologies.
54. Use a Project Glossary
Créez et maintenez une source unique de tous les termes et vocabulaire spécifiques au projet.
55. Don’t Think Outside the Box, Find the Box
Devant un problème impossible, identifiez les contraintes réelles. Demandez-vous : “Est-ce que ce doit être traité de cette façon ? Est-ce que ça doit être fait tout court ?”
56. Start When You’re Ready
Vous augmentez votre expérience toute votre vie. Ne sous-estimez pas vos doutes et votre petite voix intérieure.
57. Some Things Are Better Done than Described
Ne tombez pas dans la spirale de spécifications, à un moment il faut commencer à coder.
58. Don’t Be a Slave to Formal Methods
N’adoptez pas les yeux fermés n’importe quelle technique sans la confronter avec le contexte des pratiques et capacités de développement de votre projet.
59. Costly Tools Don’t Produce Better Designs
Méfiez-vous des super vendeurs, des dogmes de l’industrie et de l’aura des prix. Jugez les outils sur leurs mérites.
60. Organize Teams Around Functionality
Ne séparez pas les concepteurs des codeurs et des testeurs. Construisez vos équipes comme vous construisez votre code.
61. Don’t Use Manual Procedures
Un script exécutera les mêmes instructions dans le même ordre, jour après jour.
62. Test Early, Test Often, Test Automatically
Des tests joués à chaque “build” sont beaucoup plus efficaces que des plans de tests qui dorment sur une étagère.
63. Coding Ain’t Done Until All the Tests RunTout est dit !
64. Use Saboteurs to Test Your Testing
Placer des bugs volontairement dans une copie du code source pour vérifier que vous tests les capturent.
65. Test State Coverage, Not Code Coverage
Identifier et tester les états significatifs de votre programme. Tester seulement les lignes de code n’est pas suffisant.
66. Find Bugs Once
Une fois qu’un testeur humain trouve un bug, ça devrait la dernière fois qu’un humain trouve ce bug.
67. English is Just a Programming LanguageÉcrivez vos documents comme vous écrivez votre code : respectez le principe “DRY“, utilisez les metadata, MVC, génération automatique, etc
68. Build Documentation In, Don’t Bolt It On
La documentation écrite en dehors du code a peu de chance d’être correcte et à jour.
69. Gently Exceed Your Users’ Expectations
Commencez par comprendre les attentes de vos utilisateurs, et ensuite délivrez-leur à peine plus.
70. Sign Your Work
De tout temps, les artisans sont fiers de ce qu’ils produisent. Vous devriez l’être aussi.