Nous avons déjà exploré les principes fondamentaux de programmation indispensables à tout développeur. Pourtant, une classe de principes encore plus impactante existe : ceux qui vous rendent sage dans votre code, au-delà de l'intelligence technique.
Ces principes, souvent étranges ou teintés d'humour, sont issus d'années d'expérience. Ils sont pratiques, cruciaux et applicables au quotidien. Préparez-vous à une révélation !
Ce principe, aux multiples variantes, est illustré par la célèbre loi de Zawinski (ou loi de l'enveloppement logiciel), citée dans The Art of UNIX Programming par Jamie Zawinski :
"Chaque programme tente de se développer jusqu'à ce qu'il puisse lire le courrier. Les programmes qui ne peuvent pas se développer sont remplacés par ceux qui le peuvent."
Il décrit la dérive vers une complexité accrue par l'ajout incessant de fonctionnalités superflues, ou fonctionnalité creep. Ce gonflement nuit à la performance et à la maintenabilité.
Il s'étend aussi aux ressources : "Le logiciel s'étend pour consommer toutes les ressources disponibles."
Autrefois limités par le hardware, les développeurs optimisaient rigoureusement. Aujourd'hui, avec plus de puissance, le gonflement persiste. C'est à vous de le contrer.
En contrepoint, Richard P. Gabriel a théorisé dans son essai sur la qualité logicielle :
"Un logiciel limité mais simple à utiliser peut séduire plus l'utilisateur et le marché que l'inverse."
Concentrez-vous sur un problème précis et excellez-y. La simplicité prime. Ignorer cela mène au principe de Peter appliqué au logiciel :
"Un projet trop complexe devient incompréhensible même pour ses créateurs."
Inspiré du principe de Peter en management, il explique pourquoi la simplicité l'emporte souvent.
"Tout code que vous n'avez pas relu depuis six mois ou plus pourrait avoir été écrit par un autre."
Ce rappel humble encourage la croissance continue. Si votre ancien code vous fait grincer des dents, c'est le signe que vous avez progressé. La stagnation est le vrai danger.
"Si une fonctionnalité nécessaire surprend trop, repensez-la."
Publié dans IBM Systems Journal en 1984, ce principe équilibre innovation et conventions. Trop de nouveauté repousse les utilisateurs ; optez pour des améliorations progressives.
"Il y a toujours un bug de plus."
Attribuée à Lubarsky, elle libère du perfectionnisme : testez rigoureusement, corrigez, avancez. Le « bon » suffit souvent.
"Déboguer est deux fois plus dur que coder. Écrire du code 'intelligent' vous rend trop bête pour le déboguer."
Brian Kernighan, co-auteur du livre référence sur C, prône le code simple, lisible et clair, non astucieux. Comme l'explique Robert C. Martin :
"Lire du code représente plus de 90 % du travail. Le rendre lisible facilite l'écriture."
Technique pragmatique de The Pragmatic Programmer : expliquez votre code ligne par ligne à un objet inanimé (comme un canard). Cela révèle les erreurs par reformulation.
Un cadeau idéal pour tout développeur !
"Les premiers 90 % du code prennent 90 % du temps. Les derniers 10 % : les 90 % restants."
De Tom Cargill, complétée par la loi de Hofstadter : "Ça prend toujours plus de temps, même en l'anticiplant."
"Le travail s'étend pour remplir le temps alloué."
De Cyril Northcote Parkinson : fixez des délais serrés et adoptez l'agile (ex. Asana) pour livrer.
"Ajouter des ressources à un projet en retard le retarde davantage."
Formation, conflits et bureaucratie alourdissent. Priorisez la planification.
Ces principes, forgés par des décennies d'expérience, préparent au réel au-delà des formations. Appliquez-les pour une carrière réussie. Maximisez vos opportunités ou explorez des rôles tech sans code.
Quel principe résonne le plus ? Connaissez-vous d'autres pépites ? Dites-le en commentaires !
