Je souhaite partager mes réflexions sur l'une des qualités du logiciel: la maintenabilité.
Les projets ne prêtent pas toujours attention à la maintenabilité. En conséquence, avec le changement d'équipe, les difficultés commencent. Surtout si l'équipe change de façon inattendue et avec une grande composition.
Sur les projets, j'ai joué le rôle de QA. Entre autres qualités, il fallait s'occuper de l'accompagnement. Du côté des programmeurs, tout d'abord, il est sous-entendu que le code doit être accompagné de commentaires et d'une bonne structure. Pendant ce temps, l'accompagnement est quelque chose de plus. Une bonne maintenabilité vous permet de bénéficier au fabricant du produit logiciel. Ce n'est pas sans raison que dans les grandes entreprises, vous pouvez trouver des programmes anciens qui ont loin de l'interface la plus conviviale, mais qui ont une bonne maintenabilité. De ce fait, ils ne sont pas pressés de remplacer le développement d'entreprises concurrentes.
Vous pouvez donner une analogie avec la pose d'électricité dans un bâtiment:
- Un bon électricien vous fournira ses circuits avant de poser le câblage. Il ne sera pas nécessaire, même après de nombreuses années, de se tourner vers lui pour comprendre ce qui mène où et comment cela fonctionne. Il n'y aura aucun problème pendant le fonctionnement.
- Si l'électricien ne fait pas le schéma de câblage, la prochaine fois, il ne le contactera que parce que à part lui, personne ne sait comment tout est organisé - alors vous devriez vous demander s'il vaut la peine de faire affaire avec lui.
En tant que testeur, je peux vous proposer de prêter attention aux aspects suivants pour augmenter la maintenabilité.
Documentation sur les fonctionnalités.
La documentation est nécessaire non seulement pour les «utilisateurs quelque part là-bas», mais aussi pour que, à midi, toute personne qui ne connaît pas le produit puisse l'utiliser sans demander de l'aide aux autres. Par exemple:
- un programmeur embauché hier pourrait déboguer une fonctionnalité,
- le support technique pourrait répondre à la question de l'utilisateur
- le testeur pourrait vérifier si quelque chose dans une fonction inconnue s'est cassé.
Documentation d'infrastructure
De nombreux outils sont les plus susceptibles d'être utilisés pour créer le produit. Parmi eux:
- système d'assemblage. Il se compose peut-être de plusieurs machines, chacune ayant de nombreux paramètres;
- d'autres services d'infrastructure, tels que les serveurs de fichiers, le système de stockage de code (surtout s'il existe des dépendances de bibliothèque sur d'autres systèmes), etc.
- bancs d'essai. Leurs paramètres et leur description doivent figurer dans les plans de test.
Tout cela est lié au projet. Et ce serait bien d'avoir une description détaillée de la structure, afin que vous puissiez facilement la restaurer si le disque dur avec les machines de la structure tombe en panne. Ou pour que vous puissiez sans effort apporter des modifications à l'infrastructure sans passer du temps à étudier chaque petite chose.
Documentation des problèmes et des risques
Lors du processus de création et d'utilisation du produit, des problèmes surviendront sûrement. Ils peuvent être classés et décrits comme une base de solution.
Certains défauts peuvent avoir une solution de contournement. Si le défaut est grave, il devrait être possible de trouver un moyen de le contourner dans la base de données des problèmes. Par exemple, si des paramètres peuvent être définis uniquement dans un navigateur spécifique.
Si le développement révèle des informations selon lesquelles des problèmes pourraient survenir à l'avenir, ces informations doivent être décrites comme des risques. Par exemple, si un module est utilisé dans un système avec 100 utilisateurs, il rompra probablement avec 500 utilisateurs.
Commentaires et descriptions de code
Il peut y avoir un document avec une description technique de tous les modules, y compris tous les schémas architecturaux.
Informations sur les outils utilisés
Par exemple, quels outils et comment utiliser pour le débogage et les tests.
Parfois, un programmeur peut avoir besoin d'outils de testeur pour déboguer les fonctionnalités. Ou le testeur peut avoir besoin d'informations sur les outils du développeur pour collecter des informations lorsqu'un défaut est détecté.
Y compris cela vaut la peine de prêter attention à la prévalence des outils. Même si un outil est bien adapté à la tâche à accomplir, mais qu'il est ancien et non pris en charge, il peut être difficile.
Achèvement de la tâche
Comme le dit le principe de Pareto: il faut 80% du temps pour terminer 20% du travail.
Et si quelque chose n'est pas terminé, alors il doit y avoir une raison. Très probablement, c'était cher.