Code et art de l'entretien de la moto : les défauts typiques des débutants

Le codage est facile, dit-on, c'est comme faire du vélo. Eh bien, la programmation est en fait une moto, très puissante et rapide. Avec le codage, tout comme avec la conduite, il faut être responsable et conscient pour rester en selle et doubler cela pour être un gagnant. En effet, les motards et les codeurs partagent les mêmes erreurs de débutant : les néophytes ont souvent tendance à se concentrer sur des outils rapides et puissants et des astuces innovantes, pensant que cela seul définit un véritable maître. Cet état d'esprit est en partie dû à « l'effet Dunning-Kruger », où les novices ne parviennent pas à saisir la complexité et l'importance de leur profession. Heureusement, avec l'expérience, même le débutant le plus fervent se rend compte que l'art de la programmation implique bien plus que la simple sélection de l'algorithme optimal. Dans cet article, je souhaite partager mes réflexions sur ce qui compte vraiment pour un programmeur et sur ce que les développeurs débutants et chevronnés doivent garder à l'esprit lors de la création de logiciels et de l'écriture de code.

La lisibilité prime sur la performance, mais pas toujours

Par quoi commencent les motards débutants ? Des chiffres et des gadgets. Puissance, couple, pièces de performance pour grignoter quelques millisecondes théoriques sur un quart de mile… Comme s’ils étaient sur le point de prendre le départ du MotoGP. En attendant, leur tâche principale consiste simplement à apprendre à conduire en toute sécurité. De la même manière, les développeurs débutants se focalisent souvent sur les performances du code alors que ce n’est pas nécessaire. Les articles débattant de la question de savoir si `dict()` ou `{}` est plus efficace en Python, ou des avantages et inconvénients de l’utilisation de frameworks malgré leur potentiel de diminution des performances, alimentent cette obsession. Bien que la compréhension des subtilités de votre langage de programmation soit bénéfique et parfois cruciale – comme dans les logiciels pour les avions, les robots de trading boursier ou les appareils médicaux – elle n’est pas toujours essentielle pour la majorité des programmes que nous créons quotidiennement. Même si vous travaillez sur un logiciel critique pour les performances, il est essentiel de savoir quelles parties du code nécessitent des performances élevées et lesquelles n’en nécessitent pas.

Ce qui compte toujours, c'est la lisibilité du code. De nombreuses études et enquêtes confirment que les développeurs passent plus de temps à lire et à comprendre le code qu'à l'écrire. Par exemple, l'étude « Je sais ce que vous avez fait l’été dernier – Une enquête sur la façon dont les développeurs passent leur temps » ont constaté que seulement 4 % du temps passé dans un IDE est utilisé pour éditer du code. Rapport sur le temps de code global , basée sur une enquête menée auprès de plus de 250 000 développeurs, a révélé que les répondants ne passaient qu'environ 52 minutes par jour à écrire activement du code. Le reste du temps est consacré à la discussion et à la planification du projet, avec environ 41 minutes consacrées à la lecture du code dans l'IDE et à la documentation du projet.

Dans la plupart des cas, notre objectif est de créer un produit maintenable qui ne nécessitera pas de support complexe et qui prospérera dans un environnement concurrentiel. Cela ne signifie pas que nous pouvons complètement ignorer les performances ; nous devons trouver un équilibre où la maintenabilité et les performances coexistent. Si un code haute performance est nécessaire, nous pouvons optimiser les sections lentes après le lancement du projet.

Gardez également à l’esprit que les compilateurs et les interpréteurs évoluent, mais que votre code reste le même. Un extrait de code magique hyper optimisé écrit pour une version de compilateur peut devenir un fiasco inutile pour une autre. De plus, les futurs développeurs – ou même vous – devront travailler avec ce code. Alors, quand devons-nous sacrifier la lisibilité aux performances ?

Pour déterminer quand privilégier les performances par rapport à la lisibilité, il faut identifier les goulots d'étranglement dans votre application :

• Profilage de l'application : si le profilage révèle que des sections de code critiques spécifiques ont un impact significatif sur les performances, l'optimisation de ces fragments peut justifier une lisibilité réduite.

• Tests de charge : la simulation de charges élevées peut aider à identifier les goulots d’étranglement des performances avant qu’ils ne deviennent des problèmes réels.

• Analyse des commentaires des utilisateurs : la collecte des commentaires des utilisateurs peut mettre en évidence les domaines où les performances sont médiocres.

• Journalisation et surveillance : l'analyse des journaux d'exécution et des mesures peut identifier les zones problématiques lors du fonctionnement réel de l'application. Cette étape peut révéler des problèmes inattendus, tels qu'une utilisation incorrecte de l'API entraînant des problèmes de performances.

• Outils d'analyse de code statique : certains outils peuvent suggérer des améliorations de performances lors des révisions de code. L'exécution automatique de ces outils lors des révisions de tâches est une bonne pratique.

  
  

Ces conseils peuvent vous aider à identifier les points faibles de votre application, vous permettant ainsi de vous concentrer sur les optimisations nécessaires. D'après mon expérience personnelle, ces optimisations sont moins susceptibles d'impliquer des constructions de langage exotiques et plus susceptibles d'impliquer l'optimisation des interactions avec la base de données ou l'utilisation d'API externes.

La documentation permet de comprendre le travail effectué

Sur la route, l'une des compétences essentielles en matière de sécurité est d'être prévisible et de savoir lire les intentions des autres. En programmation, tout comme en conduite, vous ne pouvez pas lire directement dans les pensées des autres. Sur deux roues, vous devez remarquer les mouvements subtils et prédire ce que les autres feront la seconde suivante. Les programmeurs possèdent (mais n'utilisent pas toujours) un outil puissant pour remplacer la télépathie : la paperasse. La plupart des développeurs s'accordent à dire que la documentation est cruciale pour un projet, comme le prouvent des enquêtes comme celle de l'Université de Californie à San Francisco. Enquête 2023 auprès des développeurs Stack Overflow , où 90,36 % des répondants utilisent régulièrement la documentation technique. Cependant, ils n'y trouvent souvent pas toutes les réponses et se tournent plutôt vers Stack Overflow (82,56 %) et divers blogs (76,69 %). Une autre étude, Recherche Microsoft : Le quotidien des développeurs de logiciels , montre que les développeurs consacrent 1 à 2 % de leur journée à la documentation, avec 10,3 % des répondants perdant beaucoup de temps à cause de documents de mauvaise qualité ou obsolètes.

La documentation peut prendre de nombreuses formes, depuis les descriptions de projets détaillées dans des systèmes comme Confluence jusqu'aux commentaires de code et aux sites Web de description de projets générés automatiquement ou semi-automatiquement. Il peut même s'agir d'un simple fichier README dans le répertoire racine du projet. Quel que soit le format, le processus de création de la documentation va bien au-delà de la simple transmission d'informations sur le fonctionnement du produit. Ce processus nous oblige à repenser ce que nous avons fait , ce qui peut souvent conduire à des améliorations de l'API et de l'architecture globale. J'ai souvent réalisé, en documentant les fonctionnalités que j'ai créées, qu'il pouvait être difficile de travailler avec elles, et j'ai trouvé des moyens de résoudre ce problème.

Il est important de se rappeler que la gestion de la documentation nécessite toujours des efforts considérables, surtout si le projet se trouve à un stade où il change fréquemment. Dans de tels cas, vous devez peser tous les risques et réfléchir soigneusement à la logique à documenter. Si votre projet a atteint un stade de maturité, une bonne documentation apportera plus d'avantages que de défis : les nouveaux développeurs peuvent intégrer et prendre de l'élan plus rapidement, tandis que les employés de longue date peuvent rapidement comprendre le fonctionnement de certaines fonctionnalités. De plus, une documentation avec une bonne fonctionnalité de recherche dans un grand projet avec de nombreuses équipes peut éviter la duplication des fonctionnalités.

Dire aux autres ce que vous faites n'est pas une honte

L'utilisation des clignotants est la forme la plus basique de conduite prévisible. De même, les commentaires de code sont probablement le moyen le plus simple et le plus direct de dire aux autres ce que vous faites. Et, tout comme l'utilisation des clignotants, cela ne vous rend pas moins cool. Je sais, il existe une croyance commune selon laquelle les commentaires sont inutiles car le code doit être explicite. Mais non, je ne suis pas entièrement d'accord avec cela. Un code de qualité peut souvent être compris intuitivement grâce à une bonne dénomination des variables et des fonctions, une structure claire et le respect des principes de code propre. Cependant, même dans de tels cas, des commentaires bien pensés peuvent fournir des informations inestimables.

Les commentaires jouent un rôle crucial lorsqu'il s'agit d'algorithmes ou de solutions complexes qui nécessitent un contexte supplémentaire pour être compris. Ils peuvent expliquer le « pourquoi » d'une approche, qui n'est pas toujours évident à partir du code lui-même. Cela est particulièrement important lorsque le code est optimisé pour les performances, mais que ses intentions et sa logique ne sont pas immédiatement claires. Les commentaires peuvent également aider à reconsidérer si l'algorithme choisi évolue dans la bonne direction.

Les commentaires sont une véritable bouée de sauvetage dans les logiques métier complexes ou les exigences spécifiques à un projet, qui peuvent ne pas être évidentes pour les nouveaux membres de l'équipe ou dans le cas d'un support de projet à long terme. Ils aident à conserver les connaissances au sein de l'équipe et facilitent le transfert de projets entre développeurs.

Bien entendu, il est essentiel d'éviter les commentaires excessifs, qui énoncent des évidences ou deviennent obsolètes et trompeurs. Leur but est d'assurer la clarté et de favoriser la compréhension du code, et non de l'encombrer d'informations inutiles.

Tests : un outil pour comprendre et vérifier le code

Bon, imaginons maintenant que nous apprenions enfin à piloter et que nous voulions tenter notre chance sur une vraie piste de course. Nous découvrirons bientôt que la vraie course ne consiste pas seulement à être capable de « pédaler à fond ». Elle implique de s'entraîner, de tester et de peaufiner votre machine pour l'adapter à vos habitudes et aux conditions de course. Il en va de même pour le code : il doit être minutieusement essayé, testé et corrigé si nécessaire avant de pouvoir être lancé pour un vrai tour. Il est donc essentiel d'aborder les tests de code avec un maximum de responsabilité. Les tests sont souvent considérés comme un simple outil de recherche de bugs, mais leur rôle est plus large :

• Détection des erreurs et des défauts : les tests identifient les erreurs et les comportements imprévus avant que le produit n'atteigne l'utilisateur, améliorant ainsi la qualité et réduisant les problèmes des utilisateurs.
• Compréhension du code : la création de scénarios de test nécessite une compréhension approfondie de la structure et des fonctionnalités du code, favorisant une meilleure compréhension de la logique et de l'interaction du programme.
• Supplément de documentation : les tests peuvent servir d'exemples d'utilisation pour les fonctions et les méthodes, aidant à localiser les informations sur les fonctionnalités du projet et aidant les nouveaux spécialistes en fournissant des cas d'utilisation réels.

Des tests efficaces sont essentiels pour produire un code de haute qualité, fiable et compréhensible. Cependant, tout comme la documentation, les tests peuvent nécessiter beaucoup de ressources, en particulier dans les premières étapes du projet. Il est essentiel de trouver un équilibre entre la nécessité des tests et les contraintes de temps et de ressources.

Il est également évident qu'une couverture de test absolue pour un code complexe est tout simplement impossible à atteindre. Les développeurs doivent donc prioriser les tests des fonctions clés et des sections de code critiques, en sachant quand s'arrêter pour éviter un cycle de tests sans fin.

Aimez votre code comme vous aimez votre ami et prenez-en soin

Enfin, aucune moto ne peut être fiable sans un entretien adéquat. Il y a pas mal de gens qui négligent cet aspect de la conduite, mais ils inventent des histoires (allant de drôles à effrayantes en passant par tristes) auxquelles nous ne voulons certainement pas participer. Dans le monde de la programmation, tout comme dans le motocyclisme, la maintenance du code n'est pas seulement une recommandation mais une nécessité, en particulier pour les projets à long terme. Le manque de maintenance et de mises à jour conduit à l'obsolescence des produits et à des vulnérabilités de sécurité.

Lorsque le code n'est pas mis à jour pour assurer sa compatibilité avec les derniers compilateurs et interpréteurs, sa mise à jour peut devenir de plus en plus difficile (et le deviendra effectivement). Votre produit peut cesser de fonctionner avec les nouvelles versions du système d'exploitation si vous développez une application de bureau ou mobile. Pour un site Web, il peut cesser de fonctionner en raison d'outils et de technologies obsolètes. Le problème le plus simple peut être un certificat de sécurité expiré ou un logiciel obsolète pour son renouvellement.

Des mises à jour et des refactorisations régulières sont également essentielles pour maintenir la lisibilité du code. Cela permet de garder le projet gérable, de simplifier les modifications futures et les ajouts de fonctionnalités.

En bref, aimez votre code et consacrez-lui du temps – mais pas excessivement, sinon vous finirez comme le protagoniste de « The Zero Theorem ». Bonne chance !