Greetings, colleagues. Today we're going to talk about the kind of prep work you need to do before you start coding wildly. More specifically, about planning and 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 IDEA. The idea of our project was to create a useful telegram bot with basic functionality. Let us repeat exactly what: “I, as a user, want to be able to receive notifications when new articles are published in those groups on JavaRush 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 to and someday it might actually come in handy. Yes, we will create a readable and extensible application, but this does not mean that we will create a database schema “for growth”. In order not to support this “growth”, I decided that it would be better to abandon it altogether. This will help us avoid unnecessary support during development and unnecessary testing. Later, when our project goes into production (again an Anglicism, from the abbreviation prod - production), we will be able to do something more. Once you've decided on an idea, you need to get a little naughty and 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 a user ID in the form of a chat ID in Telegram. And there is an idea of how the search for new articles will actually proceed: we will search in all groups that have subscriptions for new articles and send them to chats. Based on this, we get the following as a first approximation (here is the development without embellishment): I don’t hope that you will understand my handwriting: I want to show exactly how and where development begins. The first stage has been completed: we have somehow decided on what will happen. The models/tables in the database are described above. But this is a draft: it can and should be polished and brought into a more readable form. While I was polishing, I remembered that I also wanted to get statistics on the bot’s work. Added this. In this drawing it is more than clear what and how it will be arranged. That is, what tables and fields will be in them, what entity names will be for the tables. It was decided that there would be several of them:
User - information about the telegram user who will use our bot. As you can see, we only save the chat ID and the flag whether the user is active or not. Why? Because our goal is not to collect information about users, but to benefit them;
GroupSub - here will be information about the group to which you have a subscription and the latest article that was sent to subscribers;
Statistics - I haven’t created 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 a BPMN diagram, which I converted into a picture and got this: Everything here is more readable and understandable. We will work according to this scheme in the search. Managers really like this scheme, 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 for working with a telegram bot.
We fill in the items that are already familiar to us - the name of the repository, its brief description.
Add a license - Apache 2.0 (you can choose the license at your discretion).
To work with the project, it would be good to use GitHub tools, such as project. What it is? This is a place where you can create tasks, track their completion, and save task status. Determine who will carry them out and more. To do this, in the created project we will find the Projects button , and there we will create a new one: As you can see, here I indicated the name of the project, described it and selected the template on which we will work - Automated Kanban. For us now it is not so important what this means. The main thing is that we will have a board with tasks, divided into columns, where each column will be the status of the task:
To do - all tasks that are planned to be done;
In progress - tasks that are currently being worked on;
Done - tasks that have already been completed 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 Issues.
We write issues (issues) 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 launched easily and quickly, so that we can access the database, so that we can manage and change the database schema, so that we can make REST requests in JavaRush to obtain data on articles. Based on this, you can choose the following technologies:
SpringBoot - as a framework for our application,
Spring Data - for working with a database,
Flyway - for working with database migrations,
MySQL - as a database for the 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.
Task creation template
We will create tasks using the following template:
The task name will look like this: JRTB-{IssueNumber}:{IssueDescription} , where:
{IssueNumber} is the serial number of the issue. Let's take it one more from the last problem;
{IssueDescription} - a brief description of the issue.
In the body of the task we will make a more detailed description of it (sometimes it may 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. Using them, a reviewer (from the English reviewer - reviewer - a person who looks at how a task is completed) can understand whether the task is completely completed or not.
Using this template, we will create our first task: It is also worth noting that when creating it, I immediately determined which project this task was suitable for, who would perform it (assignee) and which label (label) this task belonged to. Next, I will simply show the names of the tasks with a small description and links to them. They are all here . We will perform the tasks in approximately the same order as indicated here:
This already looks like the beginning of the project. So to speak, we worked as a project architect and business analyst.
Filling out the repository
What else needs to be done BEFORE we start coding? - Author, how many of these paragraphs can you add, are you pulling them out of the abyss?? — No, the quality of work is shown in the 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, it needs to be filled out. What should I add? I described a complete list of what can be done in the article Optimizing work with your projects on GitHub: getting to know Github Template Repository . I highly recommend reading it. It is important for us to have clear versioning, a clear understanding of what we are doing. Therefore, I added a RELEASE_NOTES file in which changes to our project will be recorded. As an example, you can look at RELEASE_NOTES from my project (yes, why not show what I put my energy and creativity into). The changes for each new version are described there. I also added templates for creating new tasks, which have 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 manage bug fixes;
A feature request is a task to add new functionality. All the first tasks on the project are feature request tasks;
Improvement request - a task to improve the operation of the application. For example, to change test answers when working with a bot. I'm not a technical writer and I can come up with not entirely correct answers. So if you have the desire and ability, offer it :)
Question is a question for the developers about the operation of the application. A very useful thing. Let’s say there is no understanding of 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: We also currently have a document on working with the JavaRush API for working with groups.
What's next?
Well, we complete all these steps and what, the project will be closed? No, not at all. This project will continue to live. It will be developed by me and all those JavaRush students/graduates 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 JavaRush API. The developers promised to make their Swagger open access. We will also look at what a swagger is. Cool and very useful thing. Next we will integrate the JavaRush site with a telegram bot. Let's connect the user to the bot to synchronize subscriptions. Let's create statistics on course completion. And everything you want as a JavaRush Community.
conclusions
Today we talked about the behind the scenes work before the creation of the project. More precisely, about how to create a work plan, without which you can waste a lot of energy. I repeat, the beginning of the project has already been made publicly available here . As usual, I suggest you subscribe to my account on Github. This way you can receive changes to the project BEFORE the article is published. I already assume that all interested parties have registered on Github. Yes, the project is not moving as fast as we would like. However, just like real projects at work. In the next article I will describe adding the first tasks. Thanks everyone for reading and see you soon!
I don’t hope that you will understand my handwriting: I want to show exactly how and where development begins. The first stage has been completed: we have somehow decided on what will happen. The models/tables in the database are described above. But this is a draft: it can and should be polished and brought into a more readable form. While I was polishing, I remembered that I also wanted to get statistics on the bot’s work. Added this. In this drawing it is more than clear what and how it will be arranged. That is, what tables and fields will be in them, what entity names will be for the tables. It was decided that there would 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 a BPMN diagram, which I converted into a picture and got this: 
Everything here is more readable and understandable. We will work according to this scheme in the search. Managers really like this scheme, because it is understandable not only to programmers :D In general, a start has been made.
As you can see, here I indicated the name of the project, described it and selected the template on which we will work - Automated Kanban. For us now it is not so important what this means. The main thing is that we will have a board with tasks, divided into columns, where each column will be the status of the task:
It is also worth noting that when creating it, I immediately determined which project this task was suitable for, who would perform it (assignee) and which label (label) this task belonged to. Next, I will simply show the names of the tasks with a small description and links to them. They are all here . We will perform the tasks in approximately the same order as indicated here:
We also currently have a document on working with the JavaRush API for working with groups.
GO TO FULL VERSION