This article is contributed by Sun Sun, blog address:
https://www.cnblogs.com/flashsun/p/9450066.html
After reading this book, you will understand that although there is a certain methodology, it is absolutely impossible without hard work and patience.
For many new employees, the biggest headache is how to quickly understand the business and project structure of a new company.
Because there are few documents, no documents, or the documents are so outdated that they are impossible to read; If you run into a warm-hearted senior employee who explains everything to you and is always there to answer your questions, you’re lucky. The reality is that everyone is busy and no one is available to explain things to you.
I will go into the project to do development soon. What should I do?
When I joined the new company, I encountered a sad situation. But in more than a month, I got familiar with about ten projects on my own, summarized some methods and shared them with you.
Emphasize here, my strategy is generally understand the whole business online all of the project, touch clear is why each project, about how the relationship between them, so that later when specific projects, not to find direction, in the specific details of the business, of course, also need to spend time, but compared to the overall a scratching his head, and simpler.
The necessary conditions here are not “who is the customer for the project”, “what is the framework for the project”, but really the necessary conditions, just like a few mathematical axioms can derive the whole mathematical system. There are only two really necessary conditions that I can summarize here:
Source location (Gitlab or SVN)
Deployment Environment (dev/test/online)
A project is just a bunch of code on a bunch of machines, so that’s all it takes. Of course, in order to save more time, also need to obtain the wiki, Jenkins, page access path, database address, etc.
The reason I mention those two requirements is to say that the project is so simple in nature that you should not think too complicated.
Its business can be infinitely complex, but its essence cannot escape this, and you must not be confused. When you don’t know what to do or what to do, focus on the source code and the environment, and the rest is ancillary.
With the above prerequisites in place, we begin to understand the project. It’s not just a project, so don’t go into specific code, or you’ll get bored, doubt your life, and give up quickly.
An understanding of a particular project must be based on an understanding of the whole. In this case, we first draw a line for each project and label each node with information, as follows:
Page access path — front-end project — back-end service — database address
Here, a single front-end project might correspond to multiple back-end services, so the final diagram should look something like this:
The process of sorting out, mainly let oneself sort out, a total of which projects, which is the front-end visual, which is the background to provide services.
From the name of the back-end service and database, we can essentially understand what the line of business provides. From the front-end project and the page path, we can understand what we need to show the user.
Note that at this stage, we only know the meaning by name. Even if we click on the page and connect to the database, we should not spend too much time. The key point of this stage is to only know the overall content of this line of business.
On this basis, the diagram can be further refined, such as the machine deployed by the project, which we can annotate next to the project, or save in xshell. In addition, all non-business related, can check as far as possible to record, this is really for the future to find all kinds of things convenient too much, otherwise don’t look at you now save time, the time to find relevant things in the future add up, will be astronomical.
Here is a brief episode about the machine that organizes the project deployment, I would like to share with you. Since no one is going to give you all of this information, it’s impossible to tell you all of it. So I did it with the help of Jenkins. Jenkins is needed for project deployment. As long as you check the command of Jenkins configuration, you can sort out the deployment environment one by one, which I think is the most complete and up-to-date.
Don’t tell me to check the wiki, if the company wiki is written like this, I guess this article is nothing. At that time, Jenkins had very limited authority and could only see part of the project. Later, after a lot of effort and thinking of many ways, I was able to see the configuration of the project and sort out the deployed machine.
If you have experienced employees who would like to talk to you about this, it’s a good idea to know about it. If not, it’s ok to skip this paragraph and learn more about it later.
All of the above are the general framework of the project, without involving specific project details. This part, again, is not covered.
If you look at the nature of the whole business, a business is nothing more than a bunch of code running on a bunch of machines. So from the perspective of a single project, a project is nothing more than add, delete, change and check the database operation, or from the user’s point of view, a project is to input some parameters to get some return results.
So next we need to do two things, one is to clean up the database table, the other is to clean up all the interfaces of the Controller layer.
Here we must first choose a core project to look at, among many projects must be a core project, first look at this.
If the database table is less, then we take tools to export the table structure, one by one to see the line, this is not difficult. But if the database has a large number of tables, we first need to export all the table names to filter out those core tables.
Here to export the table name, analysis of screening at the back of the table and table field, might as well be a tool for oneself, I met some very troublesome in or feel can also general things, will make it a little tool, in a I give myself called javamate program, you will find that these small tools gradually accumulates have unexpected convenience in the future.
Anyway, how do you figure out which ones are core tables? Don’t worry, let’s eliminate some of the useless ones first. Take the system I analyzed in the company as an example, there were more than 150 tables in total, many of which ended with copy as backup, flow as flow, REL as intermediate associated table, statistics as data statistics, log as log table, and config as configuration table. And so on.
After excluding these tables that have no impact on the understanding of core business, there are only about 20 tables left. According to their names, we can see that many tables belong to one category, such as order table, there are various orders, and then divided into four or five categories, it is not difficult to analyze again. Larger architectures, of course, require constant disassembly.
One more thing to do before going into detail about these core table fields is to figure out the relationships between the tables. If table B has a field called a.id, then B and A are one-to-many. If two tables have rel intermediate tables, then they are many-to-many, at least logically. This analysis process I also made a small tool, through the program to judge.
At this point, you have an idea of the overall database structure. According to the name of the table can also understand the general content of the table, the next is for the specific table, look inside the specific field and the remarks given by predecessors, this process is no skill, to be patient, to slowly boil.
Once you’ve done the above with the database tables, you have a pretty good idea of what the system can offer. No matter what your code looks like, the service provided by the database is already pretty much there, and the business logic of the code can be roughly guessed by an experienced person.
I think of a business-relevant project code as having three parts:
1. Add, delete, modify, and check its own database through interaction
2. Add, delete, modify, and query the database using scheduled tasks or server scripts
3. Call or tell other services to do something
If it’s a single project, it’s just playing with your database in various ways, and the first two points are enough. For microservice deployments, a third point is enough. By dividing the code logic into three parts, it’s not a problem to quickly learn about a project, or even to quickly ask questions if you haven’t seen a project and suddenly have a bug to solve.
Add, delete, change and check their own database through interaction
This is nothing more than the simplest part, even if it is complicated, but the code is longer, more tables. The so-called interaction may be the interface exposed to the front-end user by the Controller, or the interface exposed to other microservices by opening an RPC port. In short, it is triggered by the third party.
Here I also made myself a little tool that scanned all the exposed service interfaces, showing method names, pathnames, argument lists, return values, etc.
As with the database, if the interface is very few, then look at one by one, if there are many, or find out the core of several methods first. Here I use Postman to save the interface access I want to explore and add examples of access successes and failures.
I recommend using Postman as well, as detailed as possible, in your own development. Not only can Postman simply access your interface, it can do batch testing, and it can generate API documentation to interact with the front end. Not only will you be testing your interface, but you will also be saving yourself some documentation. Postman also has the advantage of being able to mock your interface as a service, so that even if your interface is dead, or if your interface is not written at all, you can have the front-end access to your mock interface first, without the front-end testing and development at the same time, which is the real separation of the front and back ends.
After sorting out all the interfaces, most of the affirmation is very simple, a look to understand, a layer of point into the database layer until the SQL statement, the interface is the most essential thing out.
If it’s complex, debug it step by step. Take the time to analyze it. If it gets more complicated, you can draw a flow chart (I would prefer to use processon here). Even with several interfaces around a function, you can draw state flow diagrams. For example, when I saw our company dealing with order business, the logic was really complicated, so I drew a picture like the following:
Status flow diagram: the horizontal axis represents the status of the order_STATUS field, and the vertical axis represents what happens to the field when the interface operation is triggered when order_STATUS is in the above state.)
Interface effect on table: Here you can list all the tables involved and the key fields in the table. Then you can see the effect of calling the interface on each table field. The changes are highlighted in red
With the perspective of these two dimensions, I believe that no matter how complex the business is, I can clearly understand it and find the essence of some bugs.
It was in this way that I got a clear understanding of a project that did not belong to me in a short time and quickly and accurately fixed a lot of stubborn bugs.
Although the project was very bad and the business logic was very confused, it was this period of time that trained my ability to go deep into the code to clarify the logic and developed my own unique method.
Scheduled tasks or server scripts
This is the same as the first type, but with a different entrance. Such as a scheduled task, or some threads that start at startup.
It’s not easy to find these entrances, it’s a headache, but it’s just that the entrances are hidden. Find him, write down, specific analysis process or according to the above method to analyze, it is ok.
Call or tell other services to do something
There may be messages to other services via MQ, or interfaces that call other services directly, or interfaces that call cloud push to help send messages like MQ.
This piece of code may be more subtle, but it’s less numerous and the logic is simple, and you still just need to find it. This part also foreshadows the relationship between projects.
After studying these three types of code, they are almost sufficient for a business project.
For some basic services and middleware types of services, there is still a gradual accumulation of technical depth. Since this article is a quick look at a business project, I won’t expand on it.
Ok, at this point you have a general understanding of each project, at least the effect of the call, the services that the database can provide, even some of the essential logic of key parts, you are clear. At this point, rearrange the relationships between projects.
1. Based on the previous interface name, learn about the invocation relationship between projects. If you don’t understand what’s going on, ask an older employee, and they’ll be able to give you more information.
2. Look at the middleware used in each project, mainly MQ services, and see who is the producer and who is the consumer to understand the relationship
3. You should have had several rounds of weekly meetings by now, and you should be able to understand some of the rest of the week. According to each person’s description and the latest several groups of requirements, gradually understand the problems facing the current project, and which project is the core, which project is the auxiliary, which project is based on stability and security
By now, you will have a general understanding of the whole business line. Next, you will have to look at the specific business code based on the specific content you are responsible for and the direction arranged by the leader. Get in there and know everything.
But at this point, through your previous efforts, you can already see each project from a certain height, although you still don’t understand the details, but it is completely different.
While studying the specific business code, I constantly jumped out of the framework of the whole business line and corrected the wrong architecture due to the lack of understanding of the specific business. In the long run, you’ll be able to stand out on a project and let people know that you have a big picture, which is a way to get out of the habit of writing, adding, deleting, editing, and reviewing code.
Gradually, people will realize that your understanding of the project can always stand in the overall perspective, and many businesses that need to be done across projects will naturally come to you. Gradually, you will be exposed to more core things, become an architect, or switch to product, switch to management.
This is my summary of the understanding of the project process, I hope that leaders give more comments, ask questions, common progress.
Read the source of the triple realm
I’m a thread
About old Liu and code farmer turn over
I’m a Java Class
Object-oriented Bible
TCP/IP daming postman
CPU forrest gump
I am a network card
I’m a router
A story over HTTPs
The pinnacle of programming languages
Java: The Birth of an Empire
JavaScript: A loser’s counterattack