Vous avez sûrement tous, à différentes étapes de votre carrière, été confrontés à un tel problème: vous avez vu la tâche, il semble qu'elle est simple et les exigences sont claires, puis il s'avère que vous deviez la mettre en œuvre différemment. Le temps de mise en œuvre a été écoulé, la date limite est déjà en train de se faufiler, et la tâche n'est en fait pas prête. Nous devons réécrire à la volée, probablement en violation du délai. Les heures de travail sont perdues et coûtent de l'argent.Si ce problème ne concerne pas un seul développeur, mais l'ensemble de l'entreprise, alors une masse de tâches en retard augmente, le coût du développement augmente, l'entreprise ne peut pas mettre en œuvre la stratégie et l'entreprise subit des pertes.
Quel est le problème?
Ce problème est dû à une immersion insuffisante dans la tâche. Il peut y avoir plusieurs raisons, en voici quelques-unes:
- manque de documentation à jour;
- incompréhension du processus commercial;
- l'élaboration des exigences n'est pas entièrement;
- le facteur humain (la source du savoir et l'interprète parlent de la même chose, mais ils la comprennent différemment);
- la négligence personnelle des artistes et des clients;
- et d'autres (chacun a marché sur le râteau à sa manière).
En raison d'une immersion insuffisante dans la tâche, les développeurs font la mauvaise chose ou pas complètement, les testeurs font la mauvaise chose, les devops font la mauvaise chose et le SRE surveille les mauvais paramètres.
Comment cela peut-il être résolu?
Dans les précédents lieux de travail, j'ai vu l'algorithme de travail suivant:
- collecte d'informations et formation des besoins;
- l'équipe prépare et réfléchit à une solution commune;
- un exécuteur testamentaire est nommé qui exécute la tâche;
- révision du code;
- fixe;
- essai;
- plus de correctifs;
...
- plus de correctifs;
- achèvement tant attendu de la tâche.
, , ?
, , , , . 
La description de la solution technique est faite avant même le début du développement puis revue par toute l'équipe. Pour plus de clarté et d'amélioration de la perception, nous avons décidé de diluer le texte avec des schémas graphiques. Le but de cette action est d'identifier les pièges, de choisir les bons outils, d'interagir correctement avec les autres nœuds du système et de pouvoir plonger toute l'équipe dans la solution. Le résultat que nous attendions était une diminution des coûts de main-d'œuvre et des erreurs dans les processus métier (pour l'avenir, je dirai que les erreurs de logique métier ont pratiquement disparu, de nombreuses erreurs techniques ont été évitées, les correctifs ont été réduits et le temps moyen pour terminer une tâche a assez bien diminué). Il s'est également avéré qu'il est beaucoup plus facile et plus rapide de modifier une description textuelle ou un diagramme que du code déjà écrit.
Ensuite, l'algorithme de travail sera le suivant:
- collecte d'informations et formation d'une exigence;
- l'équipe prépare et réfléchit à une solution;
- un développeur responsable est nommé;
- le développeur décrit la solution technique ;
- puis cette solution technique est revue par l'équipe et d'autres plongés dans le domaine ;
- et seulement après que la décision a été convenue, le développeur écrit le code ;
- révision du code;
- essai.
Pourquoi est-il si important de décrire la solution technique avant la mise en œuvre réelle:
- la logique de la solution est revue, les erreurs sont corrigées au stade de la conception;
- le développeur plonge plus profondément dans le domaine avant l'implémentation, ce qui permet de réfléchir à l'architecture à l'avance;
- les départements adjacents peuvent immédiatement comprendre ce que sera l'API et sont prêts à commencer le développement parallèle;
- clarifie les besoins des collègues en fonction de votre implémentation;
- ( , , ).
Exness?
Arrivé chez Exness, je voulais m'habituer rapidement à l'équipe, étudier l'infrastructure et commencer à résoudre des missions de combat. Dans la première tâche volumineuse, j'ai décidé d'utiliser l'expérience accumulée et de minimiser le risque de résoudre incorrectement le problème. Pour décrire l'interaction des services, j'ai décidé d'utiliser des diagrammes de séquence, des diagrammes de blocs pour décrire le fonctionnement des algorithmes et des diagrammes ER pour décrire le schéma de la base de données.
En dessinant un diagramme, j'ai appris de mes collègues quels services pourraient être nécessaires pour résoudre mon problème, j'ai vérifié les demandes et les données de la base de données, donc j'ai déjà compris quoi et comment cela fonctionne. Le développement du diagramme n'a pas pris beaucoup de temps, et en examinant le diagramme, j'ai reçu des commentaires utiles:
- le développeur front-end voulait savoir dans quels cas, quelles données et quels statuts il recevrait du back-end;
- Le contrôle qualité doit comprendre d'où proviennent les données du service afin de couvrir autant de cas que possible.
Dans le diagramme, j'ai détaillé les exceptions et comment elles sortent, et les sources de données utilisées. Cela a permis de montrer visuellement aux collègues comment fonctionne la fonctionnalité et à quoi en attendre, respectivement, les collègues pouvaient commencer à implémenter leurs parties sans attendre ma mise en œuvre. Le développeur front-end savait comment le service réagirait et pouvait commencer à écrire des intégrations, le QA avait des informations sur la façon dont le service répondait à différentes situations et comment reproduire ces situations. En conséquence, le développement et l'immersion dans la tâche se sont avérés assez rapides, et le schéma dessiné a complété la documentation du service en cours de développement.
Exemple
L'exemple décrit ci-dessous est un composite de diverses situations.
Le nouveau développeur a reçu une tâche avec le libellé " Ecrire un nouveau microservice pour rejeter les demandes en retard. Informer les clients du changement de statut. "
Après avoir clarifié les détails techniques, vous pouvez comprendre le problème comme suit:
- construire un microservice, y créer un POST - une méthode d'API nommée rejet_old_requests;
- dans cette méthode API, vous devez obtenir des données de la base de données, spécifier des filtres par utilisateur, statut et date dans la demande;
- pour chaque demande, changez le statut du service qui gère les demandes;
- envoyez ensuite une demande au service de notification pour informer les utilisateurs du changement de statut de l'application.
Le diagramme de séquence de cette tâche peut ressembler à ceci:
et quelles erreurs vous pourriez rencontrer:
- API , ( , API, );
- , , , , ;
- , , . ;
- — , . , .
Au total, il s'avère qu'une telle solution devra être réécrite à partir de zéro, car la présence de telles erreurs peut rendre l'implémentation non viable.
Si vous écrivez une solution technique avant le développement et utilisez un diagramme de séquence pour plus de clarté, alors lors de sa révision, des collègues plus immergés dans le domaine pourront voir les erreurs et les signaler. Et probablement le développeur lui-même sera en mesure de voir certains problèmes et de les résoudre avant l'examen.
Je vous assure que le simple fait de parler de la solution d'un problème ne signifie pas résoudre le problème correctement, l'un ne l'exprimera pas correctement, l'autre ne comprendra pas correctement et la tâche ne sera pas exécutée correctement. Le diagramme de séquence n'est pas une solution miracle, mais dans de nombreux cas, il aidera à clarifier certains détails.
À quoi ressemblerait le diagramme après les corrections:
?
Tout le monde n'est pas capable de bien transférer une pensée sur papier, il est donc préférable parfois de diluer le texte avec une description graphique. Une description plus claire de la tâche sera utile non seulement pour les développeurs, mais aussi pour les testeurs, car ils sont confrontés au même problème d'immersion que les développeurs. Les testeurs doivent non seulement vérifier les résultats positifs, mais aussi s'assurer que le système répond correctement et de manière prévisible dans n'importe quelle situation; pour émuler de tels cas, il faut bien comprendre ce qui a changé dans le système. Pour l'équipe dans son ensemble, il peut être plus pratique de stocker la documentation sous forme de diagrammes ou de schémas divers, car ils sont laconiques, avec de grands changements, ils prennent moins de temps à éditer qu'une description textuelle. Dans une refactorisation majeure, les graphiques sont indispensables car ils vous permettent de comprendre rapidement qui et comment travaille avec un nœud particulier du système.Pour les chefs d'équipe, la chose sera utile dans la mesure où vous pourrez réduire votre temps et le temps des collègues juniors pour l'immersion, et en conséquence, planifier plus précisément les tâches. Lors du transfert de cas d'un développeur à un autre, les coûts de temps sont réduits, respectivement, la situation avec le facteur de bus s'améliore.
Quelles conclusions peut-on tirer?
Les diagrammes de séquence sont un outil très puissant et utile qui vous fait gagner du temps, à vous et à vos collègues. La description visuelle simplifie la perception et vous permet de vous concentrer sur la solution elle-même sans approfondir la mise en œuvre technique. Mais ne dites en aucun cas qu'une telle description visuelle est un salut de tous les problèmes, mais elle aidera à en résoudre une partie significative.
Les diagrammes aideront certainement à:
- la qualité et la rapidité de l'immersion dans le projet / la tâche;
- améliorer la situation avec le facteur bus;
- réduire les coûts de main-d'œuvre pour maintenir la documentation technique
- simplifier le transfert des affaires entre collègues;
- réduisez les coûts de main-d'œuvre pour la mise en œuvre, les tests et la révision du code, car la logique de la solution du problème est examinée avant même le début de la mise en œuvre - vous éviterez de nombreuses erreurs.
Personnellement, dans ma pratique, les schémas ont été et restent un outil indispensable.
Je vous souhaite également de trouver des outils qui optimiseront votre travail. Merci d'avoir lu jusqu'au bout.
PS Écrivez dans les commentaires si vous utilisez cette pratique, quels outils utilisez-vous?