Foreword:
As a person in charge of technology, we cannot just define the technical selection of a project without paying attention to the development details.
Before the development, if the specifications are not defined in advance, the project will be a mess. Everyone is self-contained, and looking at everyone's module seems to be no big problem, but together, it obviously feels that multiple people have developed it. At this time, if you find a problem and let some people correct it, on the one hand, it will easily cause opposition from the coder, and on the other hand, it will reduce the prestige of the technical person in charge. Because this situation generally occurs, most of the reason is that the technical person in charge of the project is not qualified, and did not think about things in advance, which is called inexperience.
So, how can one be a qualified technical person in charge? How to make these rules?
1.Git specification
Now, for version control, development is at most git, so take git as an example and talk about the general rules.
Generally, the online branch is the master, and the code for the master branch must be deployed on the line.
The main development branch is the dev branch.
The common development branch is generally dev_business content, which is actually not so limited.
1. After the new code development is completed, the local environment self-tests and passes.
2. After closing to dev, go to the test environment and pass.
3. Final code review, and then the technical person in charge or a designated gangster will integrate the dev code into the master.
4. The master branch goes online. Test and verify again after going online.
For ordinary developers:
All operations on the master are prohibited.
After the development is completed and the self-test passes, you only need to merge the code of your own development branch to the dev branch, and then deploy the devf branch to the test environment. The test can be passed.
All new branches are pulled from the dev branch. Never pull code from the master branch.
The dev branch does not allow ordinary developers to submit directly.
For the technical person in charge or the development person designated by the technical person in charge
Responsible for the code review of the dev code.
Responsible for integrating the dev code to the master. (There is a merge request in gitlab, direct approval is also possible)
2. Database specification
Database-related, some things need to be standardized in advance. For example:
1. Each table must have create_time and update_time fields, time type.
2. In each table, there must be a self-increasing id field, bigint type.
3. English translation of commonly used words in specific business needs to be defined in advance. For example, enterprise employees, some people use users, some people use staff, its practical can be any, focus on unity, we must say in advance, for example, use users.
4. SQL specifications, such as query prohibiting the use of select *, prohibiting table connection and so on.
5. The deletion of data is all logical deletion, del = 1 means deleted, del = 0 means not deleted, and it is forbidden to delete data physically using delete statement.
6. The library table of complex business must be designed first and then developed. The person in charge of technology should go through all the designs and avoid rework.
3. Specification of package structure
1. For example, the project entity is placed under the entity package, and the dao layer is placed under the dao package. The same applies to service and controller.
2. For example, service uses interface-oriented programming, define the interface first, and then implement the interface. Such as userService interface and userServiceImpl implementation class.
3. Explain to the students in advance the meaning of dto, vo and other objects in the project and the usage scenarios.
4. According to the project requirements, provide some public utils in advance, such as file upload and download, excel import and export, verification, etc. This is not mandatory. If the developers in the project are generally of high technical level, they can be written by the development students themselves, but Need to set a unified set of util to avoid repeated development. For example, excel import and export, some people may use easyexcel, or some people directly use poi, so that the poi package version may conflict with the version of the poi package referenced in easyexcel.
4. Code quality inspection tool
If the amount of code is too large and there is no manpower to codereview, then some code inspection tools are needed. For example, the unified use of the CheckStyle plug-in can also customize some check specifications.
This is also the ultimate code specification. But don't rely on it completely, it's just that some obvious mistakes can be dug out, and some business pits still need codereview.
Personal experience basically looks at a person writing code, and seeing that he writes 100 lines of core code, knowing the approximate quality of the person's code.
