Saudações, colegas. Hoje vamos falar sobre o tipo de trabalho de preparação que você precisa fazer antes de começar a programar descontroladamente. Mais especificamente, sobre planejamento e criação de uma arquitetura de aplicação. Mas por onde começar? Como construir essa arquitetura? Como em tudo, você precisa começar do início. Ou seja - com IDEA. A ideia do nosso projeto era criar um bot de telegrama útil com funcionalidades básicas. Repitamos exatamente o que: “Eu, como usuário, quero poder receber notificações quando novos artigos forem publicados nos grupos do JavaRush que me interessam”. Seguindo o princípio YAGNI, construiremos nossa aplicação. Isso significa que levaremos apenas o que precisamos. Não criaremos funcionalidades antecipadamente e de reserva só porque queremos e algum dia isso pode realmente ser útil. Sim, criaremos uma aplicação legível e extensível, mas isso não significa que criaremos um esquema de banco de dados “para crescimento”. Para não apoiar este “crescimento”, decidi que seria melhor abandoná-lo de vez. Isso nos ajudará a evitar suporte desnecessário durante o desenvolvimento e testes desnecessários. Mais tarde, quando o nosso projeto entrar em produção (novamente um anglicismo, da abreviatura prod - produção), poderemos fazer algo mais. Depois de decidir sobre uma ideia, você precisa ser um pouco travesso e desenhar. O que desenhar? Precisaremos da capacidade de salvar dados em assinaturas de grupos de diferentes usuários. Eu sei que você pode usar um ID de usuário na forma de ID de chat no Telegram. E há uma ideia de como realmente será a busca por novos artigos: vamos pesquisar em todos os grupos que possuem assinaturas de novos artigos e enviá-los para chats. Com base nisso, obtemos o seguinte como primeira aproximação (aqui está o desenvolvimento sem embelezamento): Não espero que você entenda minha caligrafia: quero mostrar exatamente como e onde o desenvolvimento começa. A primeira etapa foi concluída: de alguma forma decidimos o que vai acontecer. Os modelos/tabelas no banco de dados são descritos acima. Mas isto é um rascunho: pode e deve ser polido e tornado mais legível. Enquanto polia, lembrei que também queria obter estatísticas sobre o trabalho do bot. Adicionado isso. Neste desenho fica mais do que claro o que e como será organizado. Ou seja, quais tabelas e campos estarão neles, quais serão os nomes das entidades para as tabelas. Foi decidido que haveria vários deles:
Usuário - informações sobre o usuário do telegrama que utilizará nosso bot. Como você pode ver, salvamos apenas o ID do chat e o sinalizador se o usuário está ativo ou não. Por que? Porque nosso objetivo não é coletar informações sobre os usuários, mas sim beneficiá-los;
GroupSub - aqui estarão informações sobre o grupo ao qual você está inscrito e o último artigo que foi enviado aos assinantes;
Estatísticas - não criei um esquema para isso - faremos isso mais tarde. Este não é o objetivo principal do MVP do projeto.
Depois disso, quis mostrar com mais detalhes a forma de busca de novos artigos. Para isso usei um diagrama BPMN, que converti em uma imagem e consegui o seguinte: Tudo aqui é mais legível e compreensível. Trabalharemos de acordo com este esquema na pesquisa. Os gerentes gostam muito desse esquema, porque não é compreensível apenas para os programadores :D Em geral, já foi dado um começo.
Crie um repositório para trabalho
Finalmente, você pode criar um repositório para trabalhar com um bot de telegrama.
Preenchemos os itens que já nos são familiares - o nome do repositório, sua breve descrição.
Adicione uma licença - Apache 2.0 (você pode escolher a licença a seu critério).
Nosso projeto já está disponível - aqui está o link para ele: JavaRush Telegrambot .
Crie um projeto no repositório
Para trabalhar com o projeto, seria bom usar ferramentas do GitHub, como project. O que é isso? Este é um lugar onde você pode criar tarefas, acompanhar sua conclusão e salvar o status da tarefa. Determine quem irá realizá-los e muito mais. Para isso, no projeto criado encontraremos o botão Projetos , e lá criaremos um novo: Como vocês podem ver, aqui indiquei o nome do projeto, descrevi-o e selecionei o template no qual trabalharemos - Kanban automatizado. Para nós agora não é tão importante o que isso significa. O principal é que teremos um quadro com tarefas, dividido em colunas, onde cada coluna será o status da tarefa:
To do – todas as tarefas que estão planejadas para serem realizadas;
Em andamento - tarefas que estão sendo trabalhadas no momento;
Concluído - tarefas que já foram concluídas neste projeto.
Desta forma saberemos o estado das nossas tarefas. Quais estão em andamento, quais estão concluídos. Além disso, isso é importante e conveniente não só nos casos em que há equipe, mas também quando você trabalha por conta própria. Para que algo apareça no quadro, você precisa criar Problemas.
Escrevendo questões (problemas) para o projeto
Para entender quais tarefas escrever, vamos decidir o que teremos no projeto. Precisamos de uma aplicação que possa ser iniciada de forma fácil e rápida, para que possamos acessar o banco de dados, para que possamos gerenciar e alterar o esquema do banco de dados, para que possamos fazer solicitações REST em JavaRush para obter dados de artigos. Com base nisso, você pode escolher as seguintes tecnologias:
SpringBoot - como estrutura para nosso aplicativo,
Spring Data - para trabalhar com um banco de dados,
Flyway - para trabalhar com migrações de banco de dados,
MySQL - como banco de dados para o projeto,
Telegrambot StringBoot starter - uma biblioteca para trabalhar com um bot de telegrama,
Unirest é uma biblioteca para trabalhar com solicitações REST.
De tudo isso, vamos começar a criar tarefas.
Modelo de criação de tarefa
Criaremos tarefas usando o seguinte modelo:
O nome da tarefa será semelhante a este: JRTB-{IssueNumber}:{IssueDescription} , onde:
{IssueNumber} é o número de série do problema. Vamos dar mais uma olhada no último problema;
{IssueDescription} – uma breve descrição do problema.
No corpo da tarefa faremos uma descrição mais detalhada da mesma (às vezes pode coincidir com a descrição no nome da tarefa).
Os Critérios de Aceitação são uma lista de requisitos, após os quais a tarefa pode ser considerada concluída. Por assim dizer, os critérios para aceitar a tarefa. Usando-os, um revisor (do inglês revisor - revisor - uma pessoa que observa como uma tarefa é concluída) pode entender se a tarefa está completamente concluída ou não.
Usando este modelo, criaremos nossa primeira tarefa: Vale ressaltar também que ao criá-lo, determinei imediatamente para qual projeto essa tarefa era adequada, quem a executaria (responsável) e a qual rótulo (rótulo) essa tarefa pertencia. A seguir, mostrarei simplesmente os nomes das tarefas com uma pequena descrição e links para elas. Eles estão todos aqui . Realizaremos as tarefas aproximadamente na mesma ordem indicada aqui:
Isso já parece o início do projeto. Por assim dizer, trabalhamos como arquiteto de projetos e analista de negócios.
Preenchendo o repositório
O que mais precisa ser feito ANTES de começarmos a codificar? - Autor, quantos desses parágrafos você consegue acrescentar, você os está tirando do abismo?? — Não, a qualidade do trabalho se mostra nos detalhes. E são eles que fazem sentido. Então, vamos adicionar mais um detalhe. Para que o projeto se torne popular e compreensível para outros desenvolvedores, ele precisa ser preenchido. O que devo adicionar? Descrevi uma lista completa do que pode ser feito no artigo Otimizando o trabalho com seus projetos no GitHub: conhecendo o Github Template Repository . Eu recomendo a leitura. É importante para nós termos um controle de versão claro, uma compreensão clara do que estamos fazendo. Portanto, adicionei um arquivo RELEASE_NOTES no qual serão registradas as alterações em nosso projeto. Por exemplo, você pode ver RELEASE_NOTES do meu projeto (sim, por que não mostrar no que coloco minha energia e criatividade). As alterações para cada nova versão estão descritas lá. Também adicionei modelos para criação de novas tarefas, que possuem 4 opções:
Bug Report é uma tarefa criada por usuários/testadores que encontram um bug em seu trabalho. Isso é muito importante: ajuda a gerenciar correções de bugs;
Uma solicitação de recurso é uma tarefa para adicionar novas funcionalidades. Todas as primeiras tarefas do projeto são tarefas de solicitação de recurso;
Solicitação de melhoria - uma tarefa para melhorar o funcionamento do aplicativo. Por exemplo, para alterar as respostas dos testes ao trabalhar com um bot. Não sou um redator técnico e posso encontrar respostas não totalmente corretas. Então, se você tem desejo e habilidade, ofereça :)
Pergunta é uma pergunta para os desenvolvedores sobre o funcionamento do aplicativo. Uma coisa muito útil. Digamos que não haja compreensão do trabalho ou que haja dúvidas sobre alguma questão – você pode fazer uma pergunta desta forma e obter uma resposta em primeira mão.
Se você olhar o GitHub, verá exatamente assim: Atualmente também temos um documento sobre como trabalhar com a API JavaRush para trabalhar com grupos.
Qual é o próximo?
Bom, completamos todas essas etapas e o que, o projeto será encerrado? Não, de jeito nenhum. Este projeto continuará vivo. Será desenvolvido por mim e por todos os alunos/graduados do JavaRush que queiram participar. Quais são seus planos para o futuro? Muitos deles. O primeiro plano é criar um cliente Java para a API JavaRush. Os desenvolvedores prometeram tornar seu Swagger de acesso aberto. Também veremos o que é uma arrogância. Coisa legal e muito útil. A seguir iremos integrar o site JavaRush com um bot de telegrama. Vamos conectar o usuário ao bot para sincronizar as assinaturas. Vamos criar estatísticas sobre a conclusão do curso. E tudo o que você deseja como comunidade JavaRush.
conclusões
Hoje falamos sobre o trabalho de bastidores antes da criação do projeto. Ou mais precisamente, sobre como criar um plano de trabalho, sem o qual você pode desperdiçar muita energia. Repito, o início do projeto já foi divulgado publicamente aqui . Como sempre, sugiro que você assine minha conta no Github. Desta forma você poderá receber alterações no projeto ANTES da publicação do artigo. Já presumo que todos os interessados tenham se cadastrado no Github. Sim, o projeto não está avançando tão rápido quanto gostaríamos. No entanto, assim como projetos reais em ação. No próximo artigo descreverei a adição das primeiras tarefas. Obrigado a todos pela leitura e até breve!
Não espero que você entenda minha caligrafia: quero mostrar exatamente como e onde o desenvolvimento começa. A primeira etapa foi concluída: de alguma forma decidimos o que vai acontecer. Os modelos/tabelas no banco de dados são descritos acima. Mas isto é um rascunho: pode e deve ser polido e tornado mais legível. Enquanto polia, lembrei que também queria obter estatísticas sobre o trabalho do bot. Adicionado isso. Neste desenho fica mais do que claro o que e como será organizado. Ou seja, quais tabelas e campos estarão neles, quais serão os nomes das entidades para as tabelas. Foi decidido que haveria vários deles:
Depois disso, quis mostrar com mais detalhes a forma de busca de novos artigos. Para isso usei um diagrama BPMN, que converti em uma imagem e consegui o seguinte: 
Tudo aqui é mais legível e compreensível. Trabalharemos de acordo com este esquema na pesquisa. Os gerentes gostam muito desse esquema, porque não é compreensível apenas para os programadores :D Em geral, já foi dado um começo.
Como vocês podem ver, aqui indiquei o nome do projeto, descrevi-o e selecionei o template no qual trabalharemos - Kanban automatizado. Para nós agora não é tão importante o que isso significa. O principal é que teremos um quadro com tarefas, dividido em colunas, onde cada coluna será o status da tarefa:
Vale ressaltar também que ao criá-lo, determinei imediatamente para qual projeto essa tarefa era adequada, quem a executaria (responsável) e a qual rótulo (rótulo) essa tarefa pertencia. A seguir, mostrarei simplesmente os nomes das tarefas com uma pequena descrição e links para elas. Eles estão todos aqui . Realizaremos as tarefas aproximadamente na mesma ordem indicada aqui:
Atualmente também temos um documento sobre como trabalhar com a API JavaRush para trabalhar com grupos.
GO TO FULL VERSION