Salutations, chers collègues. Aujourd'hui, nous allons parler du type de travail de préparation que vous devez effectuer avant de commencer à coder de manière extravagante. Plus précisément, sur la planification et la création d'une architecture d'application. Mais par où commencer ? Comment construire cette architecture ? Comme pour tout, vous devez commencer depuis le début. À savoir - avec IDEA. L'idée de notre projet était de créer un robot télégramme utile avec des fonctionnalités de base. Répétons exactement ce qui suit : "En tant qu'utilisateur, je souhaite pouvoir recevoir des notifications lorsque de nouveaux articles sont publiés dans les groupes sur JavaRush qui m'intéressent." En suivant le principe YAGNI, nous construirons notre application. Cela signifie que nous ne prendrons que ce dont nous avons besoin. Nous ne créerons pas de fonctionnalités à l’avance et en réserve simplement parce que nous le souhaitons et qu’un jour, cela pourrait s’avérer utile. Oui, nous allons créer une application lisible et extensible, mais cela ne signifie pas que nous allons créer un schéma de base de données « pour la croissance ». Afin de ne pas soutenir cette « croissance », j’ai décidé qu’il valait mieux l’abandonner complètement. Cela nous aidera à éviter une assistance inutile pendant le développement et des tests inutiles. Plus tard, lorsque notre projet entrera en production (encore un anglicisme, de l'abréviation prod - production), nous pourrons faire quelque chose de plus. Une fois que vous avez choisi une idée, vous devez devenir un peu méchant et dessiner. Que dessiner ? Nous aurons besoin de pouvoir sauvegarder les données sur les abonnements à des groupes d'utilisateurs différents. Je sais que vous pouvez utiliser un identifiant utilisateur sous la forme d'un identifiant de chat dans Telegram. Et il y a une idée de la façon dont se déroulera réellement la recherche de nouveaux articles : nous rechercherons dans tous les groupes qui ont des abonnements de nouveaux articles et les enverrons aux chats. Sur cette base, nous obtenons ce qui suit en première approximation (voici le développement sans fioriture) : Je n'espère pas que vous comprendrez mon écriture : je veux montrer exactement comment et où commence le développement. La première étape est franchie : nous avons en quelque sorte décidé de ce qui va se passer. Les modèles/tables de la base de données sont décrits ci-dessus. Mais il s’agit ici d’une ébauche : elle peut et doit être peaufinée et présentée sous une forme plus lisible. Pendant que je peaufinais, je me suis rappelé que je voulais aussi obtenir des statistiques sur le travail du bot. J'ai ajouté ceci. Dans ce dessin, il est plus que clair quoi et comment cela sera disposé. Autrement dit, quels seront les tables et les champs, quels seront les noms d'entités pour les tables. Il a été décidé qu'il y en aurait plusieurs :
Utilisateur - informations sur l'utilisateur du télégramme qui utilisera notre bot. Comme vous pouvez le voir, nous enregistrons uniquement l'ID de chat et l'indicateur si l'utilisateur est actif ou non. Pourquoi? Parce que notre objectif n’est pas de collecter des informations sur les utilisateurs, mais de leur en faire bénéficier ;
GroupSub - voici des informations sur le groupe auquel vous êtes abonné et le dernier article envoyé aux abonnés ;
Statistiques - je n'ai pas créé de schéma pour cela - nous le ferons plus tard. Ce n'est pas l'objectif principal du MVP du projet.
Après cela, j'ai voulu montrer plus en détail la manière de rechercher de nouveaux articles. Pour ce faire, j'ai utilisé un diagramme BPMN, que j'ai converti en image et j'ai obtenu ceci : Tout ici est plus lisible et compréhensible. Nous travaillerons selon ce schéma dans la recherche. Les managers aiment beaucoup ce schéma, car il n'est pas seulement compréhensible pour les programmeurs :D En général, un début a été fait.
Créer un référentiel pour le travail
Enfin, vous pouvez créer un référentiel pour travailler avec un robot Telegram.
Nous remplissons les éléments qui nous sont déjà familiers - le nom du référentiel, sa brève description.
Ajoutez une licence - Apache 2.0 (vous pouvez choisir la licence à votre discrétion).
Notre projet est maintenant disponible - voici le lien vers celui-ci : JavaRush Telegrambot .
Créer un projet dans le référentiel
Pour travailler avec le projet, il serait bon d'utiliser les outils GitHub, tels que project. Ce que c'est? Il s'agit d'un endroit où vous pouvez créer des tâches, suivre leur achèvement et enregistrer l'état des tâches. Déterminez qui les réalisera et plus encore. Pour ce faire, dans le projet créé, nous trouverons le bouton Projets , et là nous en créerons un nouveau : Comme vous pouvez le voir, ici j'ai indiqué le nom du projet, je l'ai décrit et sélectionné le modèle sur lequel nous allons travailler - Kanban automatisé. Pour nous, ce que cela signifie n’est plus si important. L'essentiel est que nous aurons un tableau avec des tâches, divisées en colonnes, où chaque colonne sera le statut de la tâche :
À faire - toutes les tâches qu'il est prévu d'effectuer ;
En cours : tâches en cours d'exécution ;
Terminé : tâches déjà terminées dans le cadre de ce projet.
De cette façon, nous connaîtrons l’état de nos tâches. Lesquels sont en cours, lesquels sont terminés. De plus, cela est important et pratique non seulement dans les cas où il y a une équipe, mais aussi lorsque vous travaillez seul. Pour que quelque chose apparaisse sur le tableau, vous devez créer des problèmes.
Nous écrivons des problèmes (problèmes) pour le projet
Pour comprendre quelles tâches écrire, décidons de ce que nous aurons dans le projet. Nous avons besoin d'une application qui puisse être lancée facilement et rapidement, pour pouvoir accéder à la base de données, pour pouvoir gérer et modifier le schéma de la base de données, pour pouvoir faire des requêtes REST dans JavaRush pour obtenir des données sur les articles. Sur cette base, vous pouvez choisir les technologies suivantes :
SpringBoot - en tant que framework pour notre application,
Spring Data - pour travailler avec une base de données,
Flyway - pour travailler avec des migrations de bases de données,
MySQL - comme base de données pour le projet,
Telegrambot StringBoot starter - une bibliothèque pour travailler avec un robot télégramme,
Unirest est une bibliothèque pour travailler avec des requêtes REST.
À partir de tout ce qui précède, commençons par créer des tâches.
Modèle de création de tâches
Nous allons créer des tâches en utilisant le modèle suivant :
Le nom de la tâche ressemblera à ceci : JRTB-{IssueNumber}:{IssueDescription} , où :
{IssueNumber} est le numéro de série du problème. Reprenons encore une fois le dernier problème ;
{IssueDescription} : une brève description du problème.
Dans le corps de la tâche, nous en ferons une description plus détaillée (elle peut parfois coïncider avec la description dans le nom de la tâche).
Les critères d'acceptation sont une liste d'exigences, après quoi la tâche peut être considérée comme terminée. Pour ainsi dire, les critères d'acceptation de la tâche. En les utilisant, un réviseur (de l'anglais reviewer - reviewer - une personne qui regarde comment une tâche est accomplie) peut comprendre si la tâche est complètement terminée ou non.
À l'aide de ce modèle, nous allons créer notre première tâche : il convient également de noter que lors de sa création, j'ai immédiatement déterminé à quel projet cette tâche convenait, qui l'exécuterait (destinataire) et à quelle étiquette (étiquette) appartenait cette tâche. Ensuite, je montrerai simplement les noms des tâches avec une petite description et des liens vers celles-ci. Ils sont tous là . Nous effectuerons les tâches à peu près dans le même ordre qu'indiqué ici :
Cela ressemble déjà au début du projet. Pour ainsi dire, nous avons travaillé comme architecte de projet et analyste commercial.
Remplir le référentiel
Que faut-il faire d'autre AVANT de commencer à coder ? - Auteur, combien de ces paragraphes peux-tu ajouter, est-ce que tu les sors du gouffre ?? — Non, la qualité du travail se voit dans les détails. Et ce sont eux qui ont du sens. Ajoutons donc un détail supplémentaire. Pour que le projet devienne populaire et compréhensible pour les autres développeurs, il doit être rempli. Que dois-je ajouter ? J'ai décrit une liste complète de ce qui peut être fait dans l'article Optimiser le travail avec vos projets sur GitHub : découvrir le référentiel de modèles Github . Je recommande fortement de le lire. Il est important pour nous d’avoir un versioning clair, une compréhension claire de ce que nous faisons. Par conséquent, j'ai ajouté un fichier RELEASE_NOTES dans lequel les modifications apportées à notre projet seront enregistrées. A titre d'exemple, vous pouvez regarder RELEASE_NOTES de mon projet (oui, pourquoi ne pas montrer dans quoi je mets mon énergie et ma créativité). Les changements pour chaque nouvelle version y sont décrits. J'ai également ajouté des modèles pour créer de nouvelles tâches, qui proposent 4 options :
Le rapport de bug est une tâche créée par les utilisateurs/testeurs qui trouvent un bug dans leur travail. C'est une chose très importante : cela aide à gérer les corrections de bugs ;
Une demande de fonctionnalité est une tâche visant à ajouter une nouvelle fonctionnalité. Toutes les premières tâches du projet sont des tâches de demande de fonctionnalités ;
Demande d'amélioration - une tâche pour améliorer le fonctionnement de l'application. Par exemple, pour modifier les réponses aux tests lorsque vous travaillez avec un bot. Je ne suis pas un rédacteur technique et je peux trouver des réponses pas tout à fait correctes. Alors si vous en avez l'envie et la capacité, proposez-le :)
La question est une question destinée aux développeurs sur le fonctionnement de l'application. Une chose très utile. Disons qu'il n'y a aucune compréhension du travail ou qu'il y a des doutes sur une question - vous pouvez poser une question de cette manière et obtenir une réponse de première main.
Si vous regardez GitHub, cela ressemblera exactement à ceci : Nous avons également actuellement un document sur l'utilisation de l'API JavaRush pour travailler avec des groupes.
Et après?
Bon, on termine toutes ces étapes et quoi, le projet sera clôturé ? Non pas du tout. Ce projet continuera à vivre. Il sera développé par moi et tous les étudiants/diplômés JavaRush qui souhaitent y participer. Quels sont vos plans pour l'avenir? Beaucoup d'entre eux. Le tout premier plan consiste à créer un client Java pour l'API JavaRush. Les développeurs ont promis de rendre leur Swagger en libre accès. Nous verrons également ce qu'est un fanfaronnade. Chose cool et très utile. Ensuite, nous intégrerons le site JavaRush avec un bot télégramme. Connectons l'utilisateur au bot pour synchroniser les abonnements. Créons des statistiques sur l'achèvement des cours. Et tout ce que vous voulez en tant que communauté JavaRush.
conclusions
Aujourd'hui, nous avons parlé du travail en coulisses avant la création du projet. Plus précisément, sur la façon de créer un plan de travail, sans lequel on peut gaspiller beaucoup d'énergie. Je le répète, le début du projet a déjà été rendu public ici . Comme d'habitude, je vous propose de vous abonner à mon compte sur Github. De cette façon, vous pouvez recevoir les modifications apportées au projet AVANT la publication de l'article. Je suppose déjà que toutes les parties intéressées se sont inscrites sur Github. Oui, le projet n’avance pas aussi vite que nous le souhaiterions. Cependant, tout comme les vrais projets au travail. Dans le prochain article, je décrirai l'ajout des premières tâches. Merci à tous d'avoir lu et à bientôt !
Je n'espère pas que vous comprendrez mon écriture : je veux montrer exactement comment et où commence le développement. La première étape est franchie : nous avons en quelque sorte décidé de ce qui va se passer. Les modèles/tables de la base de données sont décrits ci-dessus. Mais il s’agit ici d’une ébauche : elle peut et doit être peaufinée et présentée sous une forme plus lisible. Pendant que je peaufinais, je me suis rappelé que je voulais aussi obtenir des statistiques sur le travail du bot. J'ai ajouté ceci. Dans ce dessin, il est plus que clair quoi et comment cela sera disposé. Autrement dit, quels seront les tables et les champs, quels seront les noms d'entités pour les tables. Il a été décidé qu'il y en aurait plusieurs :
Après cela, j'ai voulu montrer plus en détail la manière de rechercher de nouveaux articles. Pour ce faire, j'ai utilisé un diagramme BPMN, que j'ai converti en image et j'ai obtenu ceci : 
Tout ici est plus lisible et compréhensible. Nous travaillerons selon ce schéma dans la recherche. Les managers aiment beaucoup ce schéma, car il n'est pas seulement compréhensible pour les programmeurs :D En général, un début a été fait.
Comme vous pouvez le voir, ici j'ai indiqué le nom du projet, je l'ai décrit et sélectionné le modèle sur lequel nous allons travailler - Kanban automatisé. Pour nous, ce que cela signifie n’est plus si important. L'essentiel est que nous aurons un tableau avec des tâches, divisées en colonnes, où chaque colonne sera le statut de la tâche :
il convient également de noter que lors de sa création, j'ai immédiatement déterminé à quel projet cette tâche convenait, qui l'exécuterait (destinataire) et à quelle étiquette (étiquette) appartenait cette tâche. Ensuite, je montrerai simplement les noms des tâches avec une petite description et des liens vers celles-ci. Ils sont tous là . Nous effectuerons les tâches à peu près dans le même ordre qu'indiqué ici :
Nous avons également actuellement un document sur l'utilisation de l'API JavaRush pour travailler avec des groupes.
GO TO FULL VERSION