La première règle de la programmation : c'est toujours votre faute
Vous connaissez le sentiment. Cela nous est tous arrivé à un moment donné: vous avez examiné le code une douzaine de fois et vous n'y trouvez toujours pas de problème. Mais il y a un bug ou une erreur dont vous n'arrivez pas à vous débarrasser. Il doit simplement y avoir un problème avec la machine sur laquelle vous codez, avec le système d'exploitation sous lequel vous utilisez, avec les outils et les bibliothèques que vous utilisez. Il faut juste qu'il y en ait !
Peu importe à quel point vous êtes désespéré, ne choisissez pas cette voie. C'est sur cette voie que se trouve l'informatique et la programmation vaudou, par coïncidence. Bref, de la folie.
Il est frustrant de se cogner la tête à plusieurs reprises contre des bugs difficiles et obscurs, mais ne laissez pas le désespoir vous égarer. Une partie essentielle du fait d'être un programmeur humble est de réaliser que chaque fois qu'il y a un problème avec le code que vous avez écrit, c'est toujours de votre faute. Ceci est bien résumé dans The Pragmatic Programmer comme « Select Is't Broken » :
Dans la plupart des projets, le code que vous déboguez peut être un mélange de code d'application écrit par vous et/ou d'autres membres de votre équipe de projet, de produits tiers (base de données, connectivité, bibliothèques graphiques, communications ou algorithmes spécialisés, etc.) et/ou de la plateforme (système d'exploitation, bibliothèques système et compilateurs).
Il est possible qu'un bug existe dans le système d'exploitation, le compilateur ou un produit tiers, mais cela ne devrait pas être votre première pensée. Il est beaucoup plus probable que le bug existe dans le code de l’application en cours de développement. Il est généralement plus rentable de supposer que le code de l'application appelle incorrectement une bibliothèque que de supposer que la bibliothèque elle-même est défectueuse. Même si le problème vient d'un tiers, vous devrez quand même éliminer votre code avant de soumettre le rapport de bogue.
Nous avons travaillé sur un projet dans lequel un ingénieur senior était convaincu que l'appel système Select était interrompu sur Solaris . Aucune force de persuasion ou de logique ne pouvait le faire changer d'avis (le fait que toutes les autres applications réseau de la boîte fonctionnaient correctement n'était pas pertinent). Il a passé des semaines à rédiger des solutions de contournement qui, pour une raison étrange, ne semblaient pas résoudre le problème. Lorsqu'il a finalement été obligé de s'asseoir et de lire la documentation sur Select, il a découvert le problème et l'a corrigé en quelques minutes. Nous utilisons désormais l'expression « la sélection est cassée » comme un doux rappel chaque fois que l'un de nous commence à blâmer le système pour une faute qui est probablement la nôtre.
Le revers de la propriété du code est la responsabilité du code . Quel que soit le problème avec votre logiciel (peut-être que ce n'est même pas votre code en premier lieu), supposez toujours que le problème vient de votre code et agissez en conséquence. Si vous souhaitez soumettre le monde à votre logiciel, assumez l'entière responsabilité de ses échecs. Même si, techniquement parlant, ce n’est pas obligatoire. C'est ainsi que vous gagnez le respect et la crédibilité. Vous ne gagnez certainement pas le respect ou la crédibilité en rejetant sans cesse les erreurs et les problèmes sur d'autres personnes, d'autres entreprises, d'autres sources.
Statistiquement, vous l’aurez compris, il est incroyablement rare qu’un bogue ou une erreur dans votre logiciel ne soit pas de votre faute. Dans Code Complete , Steve McConnell a cité deux études qui le prouvent :
Deux études réalisées [en 1973 et 1984] ont révélé que, sur le total des erreurs signalées, environ 95 % sont causées par des programmeurs , 2 % par des logiciels système (le compilateur et le système d'exploitation), 2 % par d'autres logiciels et 1 % par le matériel. Les logiciels système et les outils de développement sont utilisés aujourd'hui par beaucoup plus de personnes que dans les années 1970 et 1980, et ma meilleure hypothèse est donc qu'aujourd'hui, un pourcentage encore plus élevé d'erreurs sont imputables aux programmeurs.
Quel que soit le problème avec votre logiciel, devenez propriétaire. Commencez par votre code et étudiez de plus en plus loin jusqu'à ce que vous ayez une preuve définitive de l'endroit où se situe le problème. Si le problème réside dans un autre morceau de code que vous ne contrôlez pas, vous aurez non seulement acquis des compétences essentielles de dépannage et de diagnostic, mais vous disposerez également d'une piste d'audit de preuves pour étayer vos affirmations. C'est certainement beaucoup plus de travail que de hausser les épaules et de pointer du doigt le système d'exploitation, les outils ou le framework - mais cela engendre également un sentiment de confiance et de respect qu'il est peu probable d'atteindre en pointant du doigt et en esquivant.
Si vous aspirez vraiment à devenir un programmeur humble, vous ne devriez avoir aucun scrupule à dire "hé, c'est de ma faute - et j'irai au fond des choses".
Merci de m’avoir lu!