Je ne vois que des réponses selon lesquelles nous sommes humains et enclins à nous tromper, ce qui est très vrai ... mais je vois votre question sous un autre angle.
Je pense que vous pouvez écrire des programmes sans bugs, mais ce sont généralement des programmes que vous avez déjà écrits 10 ou 12 fois. La 13ème fois que vous écrivez le même programme à partir de zéro, vous savez déjà comment le faire: vous connaissez le problème, vous connaissez les techniques, les bibliothèques, le langage ... vous le voyez dans votre esprit. Tous les modèles sont là, à tous les niveaux.
Cela me arrive avec des programmes très simples parce que j'enseigne la programmation. Ils sont simples pour moi, mais difficiles pour les étudiants. Et je ne parle pas de solutions aux problèmes que j'ai souvent abordés au tableau. Bien sûr que je les connais. Je veux dire environ 300 programmes qui résolvent quelque chose en utilisant des concepts que je connais très bien (les concepts que j'enseigne). J'écris ces programmes sans planification et ils fonctionnent, et j'ai l'impression de connaître tous les détails, je n'ai pas du tout besoin de TDD. Je reçois deux ou trois erreurs de compilation (principalement des fautes de frappe et d'autres choses du même genre) et c'est tout. Je peux le faire pour de petits programmes, et je pense aussi que certaines personnes peuvent le faire pour des programmes plus compliqués. Je pense que des gens comme Linus Torvalds ou Daniel J. Bernstein ont une telle clarté d’esprit, c’est le meilleur moyen d’obtenir un codeur sans bugs. Si vouscomprendre les choses profondément, je pense que vous pouvez le faire. Je ne peux le faire que pour des programmes simples, comme je l'ai dit.
Ma conviction est que si vous essayez toujours de faire des programmes bien au-dessus de votre niveau (j'ai déjà passé des années à le faire), vous risquez de vous perdre et de faire des erreurs. De grosses erreurs comme celles dans lesquelles vous réalisez soudainement que votre solution ne peut pas fonctionner, lorsque vous comprenez enfin le problème et devez effectuer des modifications si compliquées qu'elles risquent de vous empêcher de résoudre votre problème ou de rendre le code horrible. TDD est pour ces cas, je crois. Vous savez que vous ne résolvez pas le problème que vous abordez et que vous mettez donc des tests partout pour vous assurer que vous disposez d'une base solide. TDD ne résout cependant pas la vision de 10 000 pieds. Vous pourriez marcher en rond avec un code parfaitement propre tout le temps.
Cependant, si vous essayez de faire quelque chose de nouveau, mais juste au - dessus de votre niveau, votre programme pourrait être parfait ou presque parfait. Je pense qu'il est vraiment difficile de savoir quels sont les programmes qui se trouvent dans votre "frontière du savoir", mais en théorie, c'est la meilleure façon d'apprendre. En fait, je réécris beaucoup de programmes à partir de rien. Certaines personnes le font, mais vous avez besoin de beaucoup de temps et de patience car la troisième fois que vous répétez un programme non trivial, vous ne vous énervez pas autant que la première fois.
Mon conseil est donc le suivant: ne pensez pas que vous comprenez quelque chose tant que vous ne pourrez pas écrire un programme exempt d'erreurs rien que pour cela. Et essayez ensuite de combiner deux de ces concepts que vous connaissez profondément dans le même programme. Je suis presque sûr que vous aurez bien compris la première fois. L'un des meilleurs moyens consiste à réécrire des logiciels non triviaux, ce qui a demandé beaucoup d'efforts dès la première fois (je le fais actuellement avec les applications Android). Chaque fois que je recommence, je change quelque chose ou j'ajoute des choses, juste pour ajouter un peu de plaisir, et je peux vous dire que je vais de mieux en mieux ... peut-être pas sans insectes mais vraiment fier.