Hello, I'm Chen, today we talk about Zendo'sCode Submission Specification~
contexts
exist"Programmers who don't yet know this principle, beware.article, I mentioned Zendo's code commit specification.Simply put, we integrate tools into the Zendo team's daily code submission process, using tools to standardize and constrain processes and behaviors.
Next, I will briefly share with you the code submission specification of Zendo team from coding specification, testing specification and other aspects. In order to facilitate your understanding and learning, you can scan the code to send the[Code Submission Specification], get the Zendo team's code submission specification for free.
I. Coding norms
The Zendo team specifies that developers cannot change more than 20 lines per local commit.As a result, people generally take a small batch, multi-frequency approach to committing. We hope to gradually raise the team's awareness of code submission specifications through this incremental code change.
However, in practice, relying on the self-motivation of team members is not enough. Therefore, it becomes especially important to introduce tools, which we use in theSelf-developed DevOps platform. We added gating to the DevOps platform. Whenever a team member does a commit operation locally, a hook is triggered that will diff the current code.
If more than 20 lines of code are changed, a team member's code cannot be committed, but if a developer changes 30 lines and then deletes 10 lines, the change counts as 20 lines. With the hard limitations of tools like DevOps Platform, the Zendo team can do a good job of monitoring and disciplining.
In addition.When a team member pushes code, the Zendo team requires that no more than 60 lines be pushed at a time, which, combined with the commit constraints mentioned earlier, means that no more than 3 commits can be pushed at a time. After the code is pushed, it is not stored in the repository, but rather initiates a code review (similar to Gerrit).. Only after the manual review is passed can the code be saved to the code repository and merged with other people's code. This approach is suitable for master developers, or teams that have strict requirements for code quality.
In fact, the Zendo team's approach is somewhat different from the process of GitHub and GitLab.GitHub is to PR (Pull Request) way to ensure the quality of the code, but this way does not meet the requirements of the actual process of the enterprise, involving too many libraries too much will cost more energy. GitLab is a multi-branch merge to realize the code review, and we will force to do the pre-code review, the code review does not pass will not enter the library.
In the subsequent R&D management, we will also consider adding code coverage and other requirements to continuously improve and cover the R&D management process.
II. Test-driven development
The Zendo team also did TDD (Test-Driven Development), and for quite some time, the team had a massive unit test replenishment. Although all of them were eventually added, the team still didn't form a spontaneous and conscious habit in the process.
The Book of Diligent Discipline reads, "There is no such thing as a man's common feeling of evil labor and good contentment."From the perspective of human nature, people are inert. In this case, we have to use tools to enforce the standardization of everyone's behavior to achieve the purpose of improving effectiveness.
Currently, we enforce unit testing through tools: code can only be committed if it passes unit tests. This includes small batch commits, mandatory manual code reviews, mandatory calls to local test code checks, etc.
Take Zendo project management software as an example:
1. Integration of Git, Subversion, GitFox code repository, the team can directly browse and review the code and submit tasks or bugs against the code, directly from the code level to follow up the progress of the requirements;
2. Integrated GitLab service, GitLab users associated with Zendo users, associated issue to requirements, tasks, bugs, commit merge requests.
3. Integration of the Jenkins service , create Jenkins build tasks , through the pipeline for automated builds to achieve continuous integration ;
4. Support the maintenance and management of SonarQube projects. You can create build tasks and view inspection reports in Zendo to make code inspection and problem management more efficient and convenient.
In addition, we will also make processes such as design reviews mandatory. Design reviews are conducted through guided forms, and we may also add pipelines at a later date.
Zendo Code Submission Specifications
In the previous development environment, Zendo team has been using share+vim. However, vim's support for competitor is relatively weak, e.g. it only supports writing code, and does not have a chat function. In view of this, our custom development department has switched to Visual Studio Code with WAM mode, and after a period of trial, we found that it works quite well.
Subsequently, we'll be preparing to switch the entire company to Visual Studio Code, using the WAM model to fully utilize the capabilities of the Big Model. Also, we will integrate these into the DevOps pipeline and try to utilize the big model for initial code reviews.
To summarize, the Zendo team's code commit process specification: perform mandatory small batch commits, along with check-in of local unit test results, and mandatory manual code reviews. In fact, before that, we have a mandatory design and design review session.
concreteRemote Branch Specification, Git Repository Local Branch Specification, Tag Naming Specificationetc., I've organized it in a document for you, so you can make notes[Code Submission Specification]You can get it for free.
I hope my sharing can help you and feel free to leave me a comment to discuss with me.