Greetings, colleagues. Today we're going to talk about the prep work you need to do before you start coding rampantly. More specifically, about planning, creating an application architecture. But where to start? How to build this architecture? As with everything, you need to start from the beginning. Namely, with IDEAS. The idea of our project was to create a useful telegram bot with basic functionality. Let's repeat exactly how: “I, as a user, want to be able to receive notifications when new articles are published in those groups on CodeGym that interest me.” Following the YAGNI principle, we will build our application. This means that we will only take what we need. We will not create functionality in advance and in reserve just because we want it so much and someday it can really come in handy. Yes, we will create a readable and extensible application, but this does not mean that we will make the database schema “growth”. In order not to support this “growth”, I decided that it would be better to completely abandon it. This will help us avoid unnecessary support during development and unnecessary testing. Later, when our project goes into production (again, anglicism, from the abbreviation prod - production), we will already be able to do something more. Once you have an idea, you need to play around a little.draw. What to draw? We will need the ability to save data on subscriptions to groups of different users. I know that you can use the user ID in the form of a chat ID in the telegram. And there is an idea how the search for new articles will actually take place: we will search in all groups that have subscriptions for new articles and send them to chats. Based on this, we get, as a first approximation, this (here is the development without embellishment):I do not hope that you will understand my handwriting: I want to show exactly how and where development begins. The first stage has been passed: we have somehow decided what will happen. The models/tables in the database are described above. But this is a draft version: it can and should be polished and brought into a more readable form. While grinding, I remembered that I still want to get statistics on the work of the bot. Added this. In this figure, it is more than clear what and how will be arranged. That is, what will be the tables and fields in them, what will be the names of the entities for the tables. It was decided that there will be several of them:
User - information about the telegram user who will use our bot. As you can see, we save only the chat ID and flag, active user or not. Why? Because our goal is not to collect information about users, but to benefit them;
GroupSub - there will be information about the group that is subscribed to and the last article that was sent to subscribers;
Statistics - I didn't create a schema for it - we'll do that later. This is not the main goal in the MVP of the project.
After that, I wanted to show in more detail the way to search for new articles. To do this, I used the BPMN scheme, which I translated into a picture and got this: Everything is more readable and understandable here. According to this scheme, we will work in the search. Such a scheme is very fond of managers, because it is understandable not only to programmers :D In general, a start has been made.
Create a repository for work
Finally, you can create a repository already for working with the telegram bot.
We fill in the items already familiar to us - the name of the repository, its brief description.
Add a license - Apache 2.0 (you can choose a license at your discretion).
It would be nice to use GitHub's tools, such as the project, to work with the project. What it is? This is a place within which you can create tasks, track their implementation, save the status of the task. Determine who will perform them and more. To do this, in the created project, we will find the Projects button , and we will already create a new one there: As you can see, here I specified the name of the project, described it and chose the template we will work on - Automated Kanban. For us now it is not so important what it means. The main thing is that we will have a board with tasks, divided into columns, where each of the columns will be the status of the task:
To do - all tasks that are planned to be done;
In progress — tasks that are being worked on at the moment;
Done - tasks that have already been done within this project.
This way we will know about the status of our tasks. Which ones are in progress, which ones are done. Moreover, this is important and convenient not only in cases where there is a team, but also when you work on your own. In order for something to appear on the board, you need to create tasks (Issue).
We write tasks (issue) for the project
To understand what tasks to write, let's decide what we will have in the project. We need an application that can be run easily and quickly, so that we can access the database, so that we can manage the database schema and change it, so that we can make REST requests in CodeGym to get data on articles. Based on this, you can choose the following technologies:
SpringBoot - as a framework for our application,
Spring Data - for working with the database,
Flyway - for working with database migrations,
MySQL - like a database for a project,
Telegrambot StringBoot starter - a library for working with a telegram bot,
Unirest is a library for working with REST requests.
From all of the above, let's start creating tasks.
Issue Creation Template
We will create tasks according to the following template:
The task name will look like this: JRTB-{IssueNumber}:{IssueDescription} , where:
{IssueNumber} is the ordinal number of the issue. We take it one more from the last task;
{IssueDescription} - a brief description of the issue.
In the body of the task, we will make a more detailed description of it (sometimes it can coincide with the description in the task name).
Acceptance Criteria is a list of requirements after which the task can be considered completed. So to speak, the criteria for accepting the task. According to them, the reviewer (from the English reviewer - a reviewer - a person who looks at how the task is completed) can understand whether the task has been completed or not.
Let's create our first task according to this template: It is also worth noting that when creating, I immediately determined which project this task is suitable for, who will perform it (assignee) and which label (label) this task belongs to. Next, I'll just show the names of the tasks with a little description and links to them. All of them are here . We will perform the tasks in approximately the same order as indicated here:
[FEATURE] JRTB-1: Add repository layer - this is one of the biggest tasks - everything that needs to be done to work with the database is combined here.
Now that looks like the start of a project. So to say, we worked as a project architect and business analyst.
Populating the repository
What else needs to be done BEFORE we start coding? - Author, how many of these paragraphs can you add, are you getting them out of the abyss ?? — No, the quality of work is shown in details. And they are the ones that make sense. So let's add one more detail. In order for the project to become popular and understandable for other developers, you need to fill it. What needs to be added? For a complete list of what can be done, I described in the article Optimizing work with your projects on GitHub: getting to know the Github Template Repository . I highly recommend reading. It is important for us to have a clear versioning, a clear understanding of what we are doing. Therefore, I added a RELEASE_NOTES file, which will record changes to our project. As an example, you can look at RELEASE_NOTES from my project(yes, why not show what I put my strength and creativity into). It describes the changes for each new version. I also added templates for creating new tasks, in which there are 4 options:
Bug Report is a task created by users/testers who find a bug in their work. This is a very important thing: it helps to manage error correction;
A feature request is a task to add new functionality. All the first tasks on the project are tasks on the feature request;
Improvement request - a task to improve the performance of the application. For example, to change test answers while working with a bot. I'm not a technical writer and can come up with answers that aren't quite right. So if there is a desire and ability - offer :)
Question is a question for developers about how the application works. A very useful thing. Suppose there is no understanding in the work or there are doubts about some question - you can ask a question in this way and get an answer first hand.
If you look at the github, it will look exactly like this: Also, at the moment we have a document on working with the CodeGym API for working with groups.
What's next?
Well, we will complete all these steps and what, the project will be closed? No, not at all. This project will live on. It will be developed by me and all those students / graduates of CodeGym who want to take part. What are your plans for the future? A lot of them. The very first plan is to create a Java client for the CodeGym API. The developers promised to make open access to their Swagger. What is a swagger, we will also analyze. Nice and very useful item. Next, we will integrate the CodeGym website with the telegram bot. Connect the user to the bot to synchronize subscriptions. Let's create statistics on the passage of the course. And whatever you want as CodeGym Community.
conclusions
Today we talked about behind the scenes work before the creation of the project. More specifically, about how to create a work plan, without which you can waste a lot of energy for nothing. I repeat, the beginning of the project has already been made publicly available here . Traditionally, I propose to subscribe to my account on github. This way you can get changes to the draft BEFORE the article is published. I already assume that all interested persons have registered on the github. Yes, the project is not moving as fast as we would like. However, like real projects at work. In the next article, I will describe adding the first tasks. Thank you all for reading and see you soon!
But where to start? How to build this architecture? As with everything, you need to start from the beginning. Namely, with IDEAS. The idea of our project was to create a useful telegram bot with basic functionality. Let's repeat exactly how: “I, as a user, want to be able to receive notifications when new articles are published in those groups on CodeGym that interest me.” Following the YAGNI principle, we will build our application. This means that we will only take what we need. We will not create functionality in advance and in reserve just because we want it so much and someday it can really come in handy. Yes, we will create a readable and extensible application, but this does not mean that we will make the database schema “growth”. In order not to support this “growth”, I decided that it would be better to completely abandon it. This will help us avoid unnecessary support during development and unnecessary testing. Later, when our project goes into production (again, anglicism, from the abbreviation prod - production), we will already be able to do something more. Once you have an idea, you need to 
I do not hope that you will understand my handwriting: I want to show exactly how and where development begins. The first stage has been passed: we have somehow decided what will happen. The models/tables in the database are described above. But this is a draft version: it can and should be polished and brought into a more readable form. While grinding, I remembered that I still want to get statistics on the work of the bot. Added this. In this figure, it is more than clear what and how will be arranged. That is, what will be the tables and fields in them, what will be the names of the entities for the tables. It was decided that there will be several of them:
After that, I wanted to show in more detail the way to search for new articles. To do this, I used the BPMN scheme, which I translated into a picture and got this: 
Everything is more readable and understandable here. According to this scheme, we will work in the search. Such a scheme is very fond of managers, because it is understandable not only to programmers :D In general, a start has been made.
As you can see, here I specified the name of the project, described it and chose the template we will work on - Automated Kanban. For us now it is not so important what it means. The main thing is that we will have a board with tasks, divided into columns, where each of the columns will be the status of the task:
It is also worth noting that when creating, I immediately determined which project this task is suitable for, who will perform it (assignee) and which label (label) this task belongs to. Next, I'll just show the names of the tasks with a little description and links to them. All of them are here . We will perform the tasks in approximately the same order as indicated here:
Also, at the moment we have a document on working with the CodeGym API for working with groups.
GO TO FULL VERSION