C’est la fin de l’année, c’est donc le moment idéal pour rafraîchir les connaissances de base. Cet article passe en revue les cinq étapes d’un logiciel parfait que vous ne devriez jamais omettre.
Pour clarifier, je vais faire un zoom sur le « niveau de l’unité » car la plupart d’entre vous ne seront pas responsables des décisions d’architecture de haut niveau ou de la dynamique d’équipe.
Recherche
Je trouve que c’est la phase la plus souvent sautée de nos jours. Et j’en attribue la responsabilité aux pratiques d’embauche actuelles. Bien que la vitesse ait une valeur absolue, courir vite dans la mauvaise direction est pire que de rester immobile.
La phase de recherche consiste à ralentir et à prendre le temps de réfléchir au problème.
- Comprenez-vous le problème ? Est-il bien spécifié ?
- Disposez-vous de toutes les ressources dont vous avez besoin pour le résoudre (connaissances ou outils) ?
- Existe-t-il des ressources internes pour vous aider à résoudre cette tâche (personnes ou outils) ?
- Existe-t-il des ressources externes que vous pouvez utiliser (personnes ou outils) ?
- Qui sont les parties prenantes ? Sont-ils toujours intéressés par cette tâche ? Leurs exigences ont-elles changé ?
Une phase de recherche doit répondre à toutes les questions ouvertes ou incertitudes qui pourraient potentiellement changer la nature de la tâche. De tels changements obligeraient à dupliquer le travail s’ils étaient découverts plus tard dans le processus.
Mes tâches sont si simples que je n’ai pas besoin de faire de recherche. Je sais exactement ce qu’il faut faire et comment le faire !
Si c’est le cas pour vous et que vous aimez votre travail, alors c’est excellent. Sachez simplement que vous êtes très susceptible d’être remplacé par l’automatisation.
C’est une perte de temps !
La recherche ne doit pas nécessairement être une activité longue et complexe. Selon l’ampleur de la tâche, la recherche peut se résumer à une conversation de cinq minutes avec votre responsable technique.
Prototype
Une fois que nous avons compris ce que nous faisons, il est temps de déterminer comment. L’objectif principal est de définir les interfaces et les structures de données pour passer à la phase suivante.
Concentrez-vous sur la fonctionnalité de base sans tenir compte des modes de défaillance pour le moment. La simplicité doit être le principal objectif à ce stade. Gardez le minimum.
C’est notre architecte qui se charge de la conception.
Vous pouvez sauter cette phase si vous n’avez pas besoin de la phase de prototype et si vous avez tout ce dont vous avez besoin pour commencer à écrire des tests.
Test
Pour être précis, la boucle test/implémentation. Nous avons maintenant établi ce que nous implémentons et comment nous l’implémentons (au niveau de l’interface au moins).
Si nous itérons maintenant en écrivant des tests et en implémentant la fonctionnalité pour que les tests réussissent, nous garantissons que nous nous retrouvons avec une solution minimale réalisable.
Je ne vais pas vous expliquer pourquoi et comment écrire des tests unitaires, car cela représente un livre à lui seul. Mais voici quelques conseils rapides :
- Utilisez la structure
given-when-then. - Si ce composant a un état, considérez le diagramme d’état. Chaque transition doit avoir un cas de test correspondant.
- Si ce composant est sans état, considérez les conditions limites. À chacune des conditions limites doit correspondre un scénario de test.
- La testabilité est une propriété du code, vous devrez donc peut-être ajuster votre conception si vous avez du mal à écrire un scénario de test.
- Visez une couverture élevée des branches. Cependant, n’oubliez pas que parfois, ce n’est pas le manque de tests qui est en cause, mais l’implémentation (c’est-à-dire un code mort).
L’écriture de tests me ralentit !
Oui. L’écriture de tests vous ralentira lorsque vous travaillerez sur une seule tâche. Cependant, le fait d’avoir des tests accélérera tous les travaux futurs sur ce projet. Les gens surestiment le ralentissement et sous-estiment l’accélération que vous obtenez d’une base de code bien testée.
Mais les tests unitaires ne garantissent pas que mon code est correct !
Ils ne le garantissent pas. Cependant, cela n’a jamais été le but. Les tests unitaires sont avant tout de la documentation, et par là, j’entends spécifiquement la documentation des spécifications et des hypothèses. Au fur et à mesure que votre projet évolue, les anciennes spécifications et hypothèses seront violées tout le temps, et les tests unitaires seront là pour vous en informer.
En outre, si vous vous souciez de l’exactitude de votre code, vous devrez vous appuyer sur des outils tels que les vérificateurs de sécurité des ressources, les testeurs fuzz, les testeurs de mutation, etc. La majorité de ces outils fonctionnent au-dessus des tests unitaires.
Polissage
Nous avons maintenant une implémentation bien testée. Que peut-on faire de plus ? Le polissage vise à s’assurer que nous n’aurons pas d’échardes lorsqu’un coéquipier ou nous-mêmes reprendrons plus tard ce morceau de code.
Cette phase correspondra au processus de révision du code si votre équipe en a établi un. Si ce n’est pas le cas, il est toujours utile de demander à quelqu’un d’autre de lire rapidement votre code. Sinon, vous pouvez également compter sur des outils et des vérificateurs stylistiques automatisés pour signaler les parties problématiques de votre code.
Quelques conseils généraux pour le code avec des échardes :
- Les noms de vos variables et fonctions représentent-ils leur objectif ?
- Avez-vous des structures profondément imbriquées ?
- Certaines fonctions/classes ne peuvent-elles être décrites qu’au moyen d’une phrase contenant « AND »/ »OR » ?
Handoff (passé au suivant)
Enfin, c’est le moment du transfert. Ne pas effectuer un transfert correct est une erreur courante et potentiellement dommageable.
Cependant, ce que cela signifie précisément variera radicalement en fonction de votre organisation :
- D’abord, fermez ou modifiez l’état de la tâche concernée.
- Informez toutes les parties prenantes. Si votre projet comporte des versions périodiques, mentionnez également l’heure de sortie prévue.
- Enfin, partagez ce que vous avez appris lors de la mise en œuvre de votre tâche (outils ou bibliothèques utiles, erreurs faciles à commettre).
Merci de votre lecture
Merci d’avoir lu cet article. Suivez-vous déjà ces cinq étapes ? Pensez-vous que j’ai oublié une étape ? Faites-le-moi savoir !
