Code propre et réutilisable : les bonnes pratiques pour des projets durables

Adopter une conception modulaire

Identifier les responsabilités distinctes

La première étape pour adopter une conception modulaire consiste à diviser le code en composants ou modules, chacun ayant une responsabilité unique 🛡️.

• Principe clé : Une tâche, un module. Pour éviter la confusion et réduire les dépendances.
• Exemple concret : Dans une application Angular, un composant peut être dédié à l’affichage des données, tandis qu’un autre gère leur saisie.

Avantages :

• Gains en clarté : Le code devient plus lisible et plus facile à comprendre.
• On réduit le temps de maintenance : En isolant le code, les bugs sont corrigés à un seul endroit, les évolutions aussi.
• On gagne en réutilisation : Les modules qui se concentrent sur une seule tâche sont plus facilement réutilisables dans d’autres contextes

Encourager l’encapsulation

L’encapsulation consiste à protéger les détails internes d’un module et à n’exposer que ce qui doit être utilisable au public. Il faut pour bien faire :

• Créer des interfaces claires : Les interactions avec le module ne doivent se faire qu’à travers des points d’accès📡 bien définis.
• Éviter les dépendances inutiles : Les modules doivent pouvoir fonctionner de manière la plus indépendante possible (dans la mesure du raisonnable bien entendu).

Favoriser l’approche transversale

En structurant le code en modules, il nous est plus facile de réutiliser ces blocs dans d’autres projets ou bien même au sein du projet dans lequel on est 💪.

• Création de composants génériques : Concentrez-vous sur des modules qui répondent à des besoins communs. Par exemple un module de gestion des utilisateurs.
• Centralisation des utilitaires : Les fonctions ou services récurrents (comme un service de gestion des erreurs ou d’envoi de mail) peuvent être stockés dans des bibliothèques internes pour une utilisation simplifiée et robuste.

Tout ceci est pour moi la base du travail de développeur mais en réalité la plupart des développeurs ne fonctionnent pas de cette manière.
Adopter une conception modulaire demande un investissement initial pour dégager des bénéfices à long terme. Le développeur lambda prends rarement le temps de poser une conception avant de se lancer dans les développements. C’est dommage, on obtiendrait un code plus clair, plus évolutif et facilement adaptable aux besoins futurs.

Écrire un code compréhensible et lisible

Utiliser des noms explicites

Les noms de variables, de fonctions et de classes doivent refléter leur rôle de manière claire 🔍.

• Privilégiez des noms descriptifs : Plutôt que des raccourcis (productList au lieu de pl).
• Évitez les termes ambigus : N’ayez pas peur des noms de variables à rallonge (getAllUsersWithTheirProducts au lieu de getUsersDatas).

Simplifier les structures

Un code trop complexe est difficile à lire et encore plus difficile à maintenir.

• Favorisez la simplicité (toujours !) : Découpez les fonctions longues en sous-fonctions plus petites, chacune avec un rôle clair.
• Évitez d’imbriquer trop de conditions (des if en cascade non !).
• Isolez la logique dans des variables plutôt que directement dans une condition (si un if fait appel à une méthode par exemple, stockez d’abord le résultat de la méthode dans une variable).

Éviter les commentaires inutiles ou redondants

Les commentaires doivent expliquer pourquoi une décision a été prise, pas simplement ce que fait le code. Un code bien écrit nécessite souvent peu de commentaires 💬🤏.

Tester systématiquement

J’ai appris que ne pas tester son code est l’une des erreurs les plus coûteuses que l’on puisse faire. J’ai vu des projets crouler sous le poids des bugs parce que les tests avaient été négligés. À l’inverse, j’ai participé à des projets où une stratégie de tests solide a permis de gagner un temps précieux et d’avancer sereinement, même sur des mises à jour complexes.

Tester systématiquement, ce n’est pas une contrainte, c’est une assurance, un gage de qualité et la clé de la tranquillité. Cela vous évite des reworks fastidieux, des implémentations d’évolutions risquées, et vous permet surtout de pouvoir libérer votre esprit, évitant au passage de nombreux allers-retours inutiles avec les clients ou l’équipe recette de votre logiciel.

Automatiser les tests : un passage obligé

L’automatisation des tests est un passage obligé pour garantir la livraison d’un projet selon les spécifications désirées. Il existe plusieurs sortes de tests :

• Tests unitaires :

  Ils se concentrent sur les granularités les plus fines de votre code à savoir les méthodes. Ils garantissent que chaque partie fonctionne indépendamment et vont permettre de déceler le moindre bug 🐞.

• Tests d’intégration :

  Ces tests permettent de vérifier que les différents modules ou services de votre application communiquent entre eux correctement. Par exemple, tester si une API REST renvoie les données attendues et si elles sont bien traitées par le front-end.

• Tests end-to-end (E2E) :

  Ces tests permettent de simuler le parcours utilisateur complet, pour valider tous les branchements du système pour valider le produit fini au plus haut niveau. Ce sont les tests idéals pour garantir une expérience utilisateur fluide. Les outils les plus populaires, qui fonctionnent bien, que j’ai pu testés, sont Cypress et Selenium. J’ai entendu parlé de Playwright récemment, qui semble être le futur framework à la mode.

Mettre à jour les tests au fil du projet

Les tests doivent évoluer avec le code. Si une fonctionnalité change ou qu’une nouvelle fonctionnalité est ajoutée, les tests doivent être ajustés pour refléter ces évolutions et couvrir les nouveaux cas. Même si cela peut sembler chronophage à écrire, il faut se forcer à le faire pour le bien du projet et de vous même : Les tests travaillent 🛠️ pour vous ensuite !

Prévoir l’évolutivité dès la conception

Dans la majorité des contextes, il est important que le développeur puisse être capable de concevoir un système capable de s’adapter à des futurs besoins de manière systématique. Cela implique d’anticiper les changements potentiels et de structurer l’application pour qu’elle puisse évoluer sans compromettre sa stabilité, sa performance ou même ses fonctionnalités primaires.

Penser à long terme : analyse des besoins

Plus facile à dire qu’a faire, mais avant même de commencer à coder, il est essentiel de bien comprendre les besoins actuels tout en anticipant les évolutions possibles.

• Questions à se poser :
  • Quels nouveaux modules ou fonctionnalités vont être ajoutées dans les mois à venir 📅 ?
  • Quel volume de données et d’utilisateurs vais-je avoir aujourd’hui et demain ?
  • Mon code devra (ou pourra) t’il être utilisé dans d’autre contextes ou projets ?

De manière générale, écrire son code le plus abstrait et générique possible permet de palier aux besoins futurs facilement et de manière modulaire.

Utiliser des architectures flexibles

Proposer une architecture flexible pour palier les besoins de demain que nous ne connaissons pas est tout à fait atteignable.
Voici quelques principes et approches qui facilitent l’adaptation pour le futur :

• Séparation des couches :
  • Adoptez une architecture multicouches en séparant à minima la présentation, le métier et les données pour isoler les responsabilités et minimiser les impacts des changements.
• Adopter une architecture modulaire :
  • Chaque module ou fonctionnalité doit être indépendant des autres. Un module doit pouvoir être ajouté, remplacé ou retiré sans perturber l’ensemble.
• Favoriser les microservices pour les projets complexes :
  • Découper l’application en services indépendants permet de les faire évoluer séparément. Par exemple, un service dédié à l’authentification peut être amélioré sans impacter les autres parties du système.

Gérer les dépendances intelligemment

Tout projet logiciel à des dépendances et il faut les sélectionner avec parcimonie pour maîtriser votre application. Mal maîtrisées, elles peuvent rapidement transformer une application avec des dépendances dans tous les sens, provoquant parfois au fil du temps des incompatiblités voir des freins sur les évolutions à venir (mises à jour impossibles ou obligatoires selon certaines montées de version). Il faut bien analyser les dépendances que vous ajoutez pour minimiser les risques, mais aussi assurer la stabilité et l’évolutivité de vos projets ⚖️.

Choisir ses dépendances avec précaution

Toutes les bibliothèques ou frameworks ne se valent pas, et intégrer une dépendance doit toujours être un choix calculé. Avant d’ajouter une nouvelle librairie à votre projet, posez-vous les bonnes questions :

• Est-ce vraiment nécessaire  ? Peut-on atteindre le même objectif avec du code maison ou une bibliothèque déjà utilisée ?
• Quelle est la pérennité de la dépendance ? Vérifiez la fréquence des mises à jour, la communauté qui la soutient, les retours d’expérience, le nombre de téléchargements, les pull requests en cours et les bugs ouverts.
• Est-elle compatible avec votre stack technique ? Certaines dépendances peuvent entraîner des conflits avec vos outils existants ou limiter vos futures évolutions.

Parfois, pour vous éviter une dépendance qui semble compliquée à intégrer, vous pouvez aller lire son code et vous en inspirez fortement en le reproduisant vous même dans votre projet 😉.

Limiter le couplage avec les dépendances

Un couplage excessif à des dépendances externes peut rendre votre projet fragile. Si une bibliothèque devient obsolète ou change radicalement, cela peut entraîner des mises à jour coûteuses 🤕.

• Adoptez un design basé sur des abstractions :

  Utilisez des interfaces pour encapsuler l’utilisation des bibliothèques. Cela permet de remplacer facilement une dépendance sans impacter tout le projet

• Minimisez l’étendue d’utilisation avec wrappers :

  Limitez l’utilisation d’une bibliothèque à des modules ou des services spécifiques, plutôt que de la disperser dans toute l’application

En conclusion : une gestion intelligente des dépendances, c’est éviter d’alourdir vos projets inutilement, tout en maximisant leur stabilité et leur maintenabilité. Cela demande de la vigilance, mais les gains en termes de qualité et de sérénité sont considérables !

Conclusion

Développer un code durable et réutilisable est bien plus qu’une question de technique : c’est une philosophie de développement et une démarche réfléchie qui vise à allier efficacité, pérennité et maintenabilité. En adoptant des pratiques telles que la modularité, la documentation claire, des tests rigoureux et une gestion intelligente des dépendances, vous posez les bases d’un projet robuste, capable de s’adapter aux défis futurs.

En travaillant ainsi, vous libérez votre esprit et vous vous évitez les nuits blanches à tenter de corriger des bugs sans risquer d’arracher la moitié de l’application. Que vous soyez développeur, lead dev ou chef de projet, investir dans un code propre et réutilisable est un choix stratégique qui profite à tous, aujourd’hui comme demain.