Nous nous intéressons aujourd’hui à l’amélioration du code produit par l’équipe projet, une question qui recouvre en fait des aspects complémentaires qui méritent à mon sens d’être étudiés plus précisément. Voici donc quelques pistes pour nourrir votre réflexion à ce sujet.
Mais que peut-on donc améliorer, en fait ?
Vous connaissez bien sûr le fameux triangle de la gestion de projet, qui présente de façon visuelle le rapport qui lie le temps, les ressources et la qualité. En filant cette métaphore, nous pouvons essayer de l’appliquer au développement logiciel en la reformulant comme suit :
- la conformité : la qualité du code ;
- les ressources : l’efficacité du code produit ;
- le temps : la maintenabilité du code ;
Ainsi, comme pour la gestion de projet, vous pouvez toujours privilégier l’un ou l’autre aspect, mais cela se fera au détriment des autres côtés du triangle. Pour avancer dans la bonne direction, un travail est donc nécessaire sur les 3 côtés à la fois.
Voyons maintenant dans le détail chacun de ces points.
Améliorer la qualité du code
La qualité du code, dans ce contexte précis, c’est sa capacité à répondre aux besoins du client qui exploite la base de code. Dans un monde parfait, le code produit par l’équipe à partir des spécifications fournies par ce dernier a été testé, recetté et validé : il ne devrait donc avoir besoin d’aucune amélioration …
Nous savons bien en pratique que les choses sont souvent un peu plus complexes que cela : améliorer la qualité du code produit peut donc être une nécessité.
Pour parvenir à cet objectif, l’idée est donc de prévoir en amont des mécanismes par lesquels la conformité du travail réalisé par l’équipe pourra être vérifiée :
- pendant le développement lui-même (par le jeu de tests unitaires, de la rédaction de spécifications précises, de l’exécutions de tests de montée en charge, etc.) ;
- en exploitation (par le jeu de tests d’intégration continue, de procédures, du suivi d’indicateurs de performances, etc.).
Attention : tout ceci a un coût non-négligeable (et exponentiel) sur le projet, c’est pourquoi il faut savoir déterminer avec précision les éléments qui devront faire l’objet d’un suivi particulier. Gardons à l’esprit qu’une production «zéro-défaut» ne peut pas exister.
Améliorer l’efficacité du code
En termes de développement logiciel, l’efficacité est un rapport qui lie intimement les ressources utilisés (nombre de serveurs, de processus, quantité de mémoire vive allouée, etc.) et le temps d’exécution (le temps de réponse d’une page web, d’un logiciel, d’un calcul, etc.).
Ainsi, idéalement, si vous augmentez les ressources (et donc le coût relatif d’exploitation), vous obtiendrez un meilleur temps de réponse. Inversement, si vous pouvez attendre un peu le résultat (parce que le traitement peut s’effectuer de façon asynchrone, par exemple) vous pouvez diminuer les ressources allouées et donc faire des économies.
L’efficacité du code recouvre donc un ensemble de compromis qu’il est nécessaire de réaliser tout au long de la vie de la base de code afin de s’assurer que cette dernière répondra au mieux aux attentes.
Mais comment savoir si le code est «efficace», justement ? Vous l’avec compris, il n’y a pas de réponse définitive à apporter à cette question, car tout dépend en fait de vos moyens et de vos attentes. Améliorer l’efficacité doit donc passer par deux étapes incontournables :
- mettre en place des indicateurs qui vont permettre une évaluation de performance-clés de votre plate-forme ; dans le cas d’un site web, nous pourrions par exemple suivre le temps de réponse de la page d’accueil ainsi que la charge des serveurs Apache et MySQL.
- fixer des objectifs de résultat et étudier les moyens d’y parvenir. Par exemple : nous souhaitons que la page d’accueil du site s’affiche en moins de X millisecondes. Faut-il pour cela ajouter du cache, rajouter un serveur, changer de technologie ou revoir le code, diminuer la qualité des images, fusionner les assets, etc. ?
Améliorer la maintenabilité du code
Au-delà de l’efficacité relative du code produit et de sa conformité, éléments que nous venons de survoler, attardons nous sur le temps consacré à sa conception par l’équipe de projet : elle est un facteur qui va influer sur la maintenabilité du code.
Un code maintenable pourra faire l’objet d’un suivi de la part de l’équipe projet, que ce soit pour ajouter de nouvelles fonctionnalités ou corriger des comportements non-désirés, le tout pour un coût modéré en temps et en ressources. Inversement, s’il ne l’est pas, la moindre modification nécessitera beaucoup d’effort, voire une réécriture, le tout au risque d’introduire des régressions.
Pour parvenir à cet objectif, l’approche classique est de mener une réflexion globale dès la conception et de créer un code réutilisable, c’est-à-dire découplé, flexible, etc.
Malheureusement, comme toutes les bonnes choses, il ne faut pas en abuser car un code «trop» réutilisable et/ou générique présente à mon sens deux inconvénients :
- il est coûteux à produire, car la conception doit alors prendre en compte la potentialité d’usages qui ne sont pas encore prévus par le client lui-même (et qui peut à bon droit estimer que c’est une dépense inutile) ;
- il devient difficile à maintenir, car chaque évolution doit prendre en compte une grande richesse d’usages pour le même code.
Il faut donc agir avec discernement et déterminer rationnellement quelles sont les zones ou les fonctionnalités qui nécessitent de bénéficier d’un tel traitement.
Comme nous l’avons vu, l’amélioration du code peut s’effectuer à travers différents canaux tous complémentaires ; l’amélioration continue, que j’évoquais dans un précédent article sous un autre angle, peut constituer une bonne approche pour aborder ce sujet qui, par nature, nécessite du temps pour prendre du recul et se mène donc sur le long terme.
Et vous ? Avez-vous eu à mener ce genre de projet ? N’hésitez pas à laisser un commentaire !