Principes de programmation qu'on ne vous a jamais enseignés

FrançaisالعربيةDeutschEnglishEspañolहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00Savez-vous pourquoi certaines personnes ne semblent jamais progresser en tant que développeurs bien qu'elles passent des années dans
00:00:04ce domaine ? Il existe divers facteurs en jeu. Et l'une de ces raisons est de ne pas comprendre
00:00:09les principes fondamentaux de la programmation. Ce ne sont pas juste des concepts théoriques qu'on apprend une fois
00:00:14pour les oublier. Ce sont les éléments concrets qui vous feront réellement progresser plus vite en tant que développeur.
00:00:19Commençons par le premier principe, la règle du boy-scout. Ce principe vient des scouts américains.
00:00:25En gros, ils ont cette règle simple : laissez le camping plus propre que vous ne l'avez trouvé.
00:00:31Je ne sais pas combien d'entre vous connaissent "Uncle Bob", mais c'est lui qui a popularisé ce concept
00:00:36au sein de la communauté de programmation, qui consiste à laisser le code légèrement plus propre que vous ne l'avez trouvé.
00:00:41Lorsque vous effectuez des modifications sur une base de code existante, la qualité du code se dégrade souvent, ce qui peut
00:00:47augmenter la dette technique. Et la dette technique peut être réduite par une amélioration continue,
00:00:52aussi minime soit-elle. Supposons, par exemple, que vous soyez chargé de modifier
00:00:57la valeur dans cette fonction. Vous l'avez fait, mais vous pouvez voir que le nom de la variable n'est pas assez
00:01:03explicite. Alors, comme la plupart des développeurs, vous pourriez simplement l'ignorer et valider ce qu'on vous a confié.
00:01:08Mais si vous suivez ce principe, vous changeriez aussi le nom de la variable pour quelque chose de plus
00:01:12compréhensible. C'est juste un exemple simple, pas seulement pour les noms de variables, mais si vous voyez quelque chose qui
00:01:18peut être amélioré, faites-le simplement. Et ce geste simple sera vraiment précieux pour la base de code.
00:01:24Deuxième principe, évitez l'optimisation prématurée. Cela signifie : n'essayez pas de rendre votre
00:01:30code plus rapide avant qu'il n'ait réellement besoin de l'être. D'abord, faites en sorte qu'il fonctionne. Ensuite, optimisez si nécessaire.
00:01:36Il y a cette célèbre citation de Donald Knuth : "l'optimisation prématurée est la racine de tous les maux",
00:01:42ce qui est vrai car les programmeurs perdent souvent la majeure partie de leur temps à s'inquiéter de la vitesse
00:01:47des parties non critiques de leurs programmes. C'est parce qu'il y a cette mode du concept de
00:01:51tout optimiser. Ce principe n'est pas contre l'optimisation de votre base de code. Il s'agit de
00:01:57comprendre ce qui doit être optimisé et, surtout, quand l'optimiser. Et je pense que c'est
00:02:03la faiblesse de la plupart des développeurs, car j'ai vu des gens utiliser des microservices alors qu'ils n'ont que
00:02:08100 utilisateurs ou ajouter du cache pour quelque chose qui n'est même pas nécessaire. Troisième principe,
00:02:14écrivez du code pour celui qui va le maintenir, ce qui signifie simplement que lorsque vous écrivez du code, vous devriez le faire de telle
00:02:19façon que les futurs développeurs qui maintiendront votre code n'aient pas de difficulté à le gérer et
00:02:23à le comprendre. C'est parce que le code que vous écrivez aujourd'hui sera maintenu par d'autres développeurs ou par
00:02:29vous-même. Si vous vous concentrez uniquement sur le fait que ça marche et non sur la clarté, alors à l'avenir, si vous
00:02:35devez revenir sur ce code, vous aurez beaucoup de mal à comprendre ce qui se passe. Regardez simplement
00:02:39cet exemple. Les deux fonctionnent et accomplissent exactement la même fonctionnalité. Mais lequel préféreriez-vous
00:02:45voir dans votre base de code ? Donc, la leçon est que chaque fois que vous écrivez ou générez du code via l'IA,
00:02:50assurez-vous toujours qu'il soit plus facile à comprendre et maintenable avant de valider votre travail.
00:02:55Notre quatrième principe s'appelle YAGNI, qui est simplement l'abréviation de "You Ain't Gonna Need It" (Vous n'en aurez pas besoin).
00:03:01Ce principe signifie simplement que vous ne devriez pas construire quelque chose dont vous n'avez pas réellement besoin, juste parce que
00:03:06peut-être que vous en aurez besoin plus tard. Car la plupart des développeurs ont l'habitude de prédire ce dont
00:03:10ils pourraient avoir besoin à l'avenir. Mais la plupart du temps, ils ne seront jamais utilisés et ne font qu'ajouter de la
00:03:16complexité inutile au projet. Rappelez-vous toujours de ceci. Si vous travaillez sur quelque chose qui pourrait être nécessaire à l'
00:03:21avenir, vous ne consacrez pas votre temps à ce dont vous avez besoin actuellement. Cinquième principe : faites la chose
00:03:27la plus simple qui puisse fonctionner. Cela signifie que face à un problème, choisissez toujours la
00:03:32solution la plus simple qui fonctionne réellement. Ne réfléchissez pas trop. Ne sur-ingéniez pas. Demandez-vous
00:03:38simplement : quelle est la chose la plus simple qui pourrait résoudre ceci dès maintenant ? Cette idée vient de l'extreme
00:03:43programming, qui nous dit de construire quelque chose de simple d'abord, puis de le refactoriser en quelque chose
00:03:48de meilleur. La plupart des développeurs ne s'en rendent pas compte, mais ils essaient souvent de construire la solution parfaite dès
00:03:53le début, ce qui finit par compliquer inutilement leur solution. Avec ce principe, vous obtenez un code
00:03:59fonctionnel plus rapidement et, même si vous devez le modifier plus tard, c'est généralement plus facile que de réparer une conception complexe
00:04:04qui était erronée. Et croyez-moi, en tant que développeur, réaliser quand on est en train de sur-ingénier quelque chose
00:04:10est très important. Donc, c'étaient les cinq principes de programmation que vous devriez commencer à
00:04:14appliquer dès maintenant. En dehors de ceux-ci, il existe aussi d'autres principes que je n'ai pas couverts
00:04:19dans cette vidéo. Si cela vous a été utile, faites-le moi savoir dans les commentaires et je créerai une deuxième partie.
00:04:24Pour l'instant, c'est tout. Assurez-vous de montrer un peu de soutien et je vous verrai dans la prochaine vidéo.

Key Takeaway

L'amélioration continue, le maintien de la lisibilité et la simplicité fonctionnelle immédiate sont les trois piliers qui permettent de progresser rapidement et efficacement en tant que développeur.

Highlights

  • La règle du boy-scout impose de laisser une base de code légèrement plus propre que dans son état initial lors de chaque modification.

  • L'optimisation prématurée constitue la cause principale de perte de temps sur les parties non critiques des programmes.

  • L'écriture de code doit systématiquement privilégier la lisibilité pour le développeur chargé de la maintenance future.

  • Le principe YAGNI (« You Ain't Gonna Need It ») proscrit la construction de fonctionnalités basées sur des besoins hypothétiques futurs.

  • La conception doit privilégier la solution la plus simple qui fonctionne immédiatement, avant toute tentative de raffinement ou de refactorisation.

Timeline

La règle du boy-scout

  • Chaque intervention sur un code existant doit laisser le projet dans un état plus propre.
  • Le renommage de variables peu explicites est une application concrète de ce principe.

Ce concept consiste à améliorer continuellement la qualité du code à chaque petite modification effectuée. Au lieu de négliger des détails techniques sous prétexte de valider rapidement une tâche, le développeur ajuste les éléments peu clairs comme les noms de variables. Cette approche réduit progressivement la dette technique accumulée au sein de la base de code.

Gestion de l'optimisation

  • L'optimisation prématurée est identifiée comme une source majeure d'inefficacité.
  • Le fonctionnement du programme doit précéder toute recherche de vitesse.

Les programmeurs consacrent souvent un temps excessif à optimiser des segments de code non critiques. Cette tendance, décrite par Donald Knuth comme la racine de tous les maux, conduit à une sur-ingénierie inutile, comme l'implémentation de microservices ou de caches pour des projets à faible trafic utilisateur.

Maintenance et lisibilité

  • Le code doit être conçu pour faciliter la compréhension du prochain développeur.
  • La clarté du code est primordiale, même pour du code généré par IA.

Le code écrit aujourd'hui devra être relu et maintenu demain. Se concentrer uniquement sur l'exécution fonctionnelle au détriment de la lisibilité complexifie inutilement les futures interventions. La priorité doit être donnée à la compréhension du code par autrui avant toute validation.

YAGNI et simplicité

  • Le principe YAGNI évite l'ajout de fonctionnalités inutiles basées sur des prédictions.
  • La solution la plus simple qui résout le problème actuel doit être choisie en priorité.

Construire des éléments en anticipant des besoins futurs non avérés génère une complexité inutile. Il est préférable d'adopter une approche issue de l'extreme programming : développer une solution simple dès maintenant, puis la refactoriser par la suite si nécessaire. Cela permet d'obtenir un code fonctionnel beaucoup plus rapidement que de tenter de concevoir une structure parfaite dès le départ.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video