preface

These days, I am discussing some twists and turns of project management with an elder brother. Talk about experience, talk about feeling, look forward to look forward to the future. This article is not suitable for PPT players, also not suitable for kneeling too long, not suitable for KPI brainwashing big guy, the above big guy please let go. # # what time to start thinking project engineering in the development of my career, has experienced many times will a small project through constant iterative upgrade heavy constitute a big project, xiao xiang purposes defined here is arguably less project function is relatively single, subsystem or a single department, and the big project definition is a complex function, with n subsystems jointly maintain project, In the middle, both small and large projects need to go through the steps of requirement definition, project development, project testing, project launching and project maintenance. At the beginning, for small projects, project management is relatively rough, why? Because the project size is small, single function, development and test maintenance are relatively simple quickly, do not need to put so much energy to do project development at first test maintenance plan, but with iterative upgrade, small projects into a big project, at this moment when a developer to get the project at hand, only the complete code, at this time, I’m sure most developers will crash, and of course it takes a long time to master the project, which brings us back to the question, when do we start thinking about engineering? Yes, engineering begins when your project completely collapses.

What are the criteria for project engineering?

We expect our project to have certain efficiency and sustainability of development, testing and maintenance, so that requirements, development, testing and operation and maintenance can perform their respective duties according to the specifications, promote the process of the project through division of labor and cooperation, and spend time in the right place. Not multiple people swimming in a pit.

What do we need to do about project engineering? How to do?

‘The criteria for buying a house is location, location, location,’ Mr. Li said. And WHAT I’m saying is, norms, norms, norms. Specification C, everything else is ancillary. Without C, support, no matter how good, is weak. At this point, I recall an incident many years ago. There was a time when I thought writing unit tests was redundant, a waste of time, and a delay in development. Why do you say so? Because at first I thought writing unit tests was mostly formalistic. It is better to write the program directly, call the interface to call it off, there is no need to whole so complicated. But the result? The developer happily mentions the test, the tester happily mentions the bug, the developer happily fixes the bug, and then begins an infinite for loop. What time is Break Ni? Until the quality is good. In fact, this result is normal and acceptable. But who? Many times due to the negligence of the development of children’s shoes, many of the same kind of bugs appear again and again. The for loop is large even before the existing functional requirements have been developed. Resulting in tight projects. Finally inexplicable began to work overtime, overtime, overtime. In fact, will be so much, nothing more than a normative problem.

What is a specification

– Git specification – Design architecture specification – Unit testing – Code writing specification – Appropriate frameworks and technologies in place – Speed up the development process through the use of automated tools. Git API specification: Git API specification: Git API specification: Git API specification: Git API specification

Submit specifications

Any code submitted to Git must be CodeReview and the submitted code must be self-tested.

Multi-branch management

When multiple people collaborate, each branch should represent a functional requirement. The advantage of this is that when the requirement changes or is eliminated, it can be discarded. In the case of multiple branches, pay particular attention to the timing of merging branches. Merge should take place after the test, and in the time of merge, there will be all kinds of strange problems, so the time of sealing the version of the general gray scale before three days. During this time, the entire iteration requirements are regression tested, and no changes other than bugs are allowed. This also reduces the online accident rate.

Multi – branch management specification

As the project progressed, the requirements increased. There are more and more branches. There are more branches and more problems, so how do we manage these branches? Believe that made the development of children’s shoes should be familiar with the subcontract in, but there is no hierarchy, git is not intuitive to establish subcontracting relationship, so you need to add/before we give the name of the branch to achieve the result that we want to be, that is can give branches all sorts of add, the answer is no, the above said irregular is lacking, so in establishing a branch, It has its own set of norms

Multi-branch naming conventions

For the main requirement branch, use the version name +/+ fature -branch, for example: v1.0.1/feature-branch For the requirement function point branch, use the version name +/+feature+ requirement name, for example: V1.0.1 /feature-exam-count If it is a bug branch, please use the version name +/+fixbig-bug name, for example: V1.0.1 /fixbug-login-fix In addition to the above version, there should be a release branch, they should be merged in the order of the bug branch or requirements function branch, merged into the requirements main branch, requirements main branch merged into the Release branch, and after the release branch is merged, It should be done once. After the version of the code can be normal version. At this point, some of you may have a question? For example, a bug is suddenly found in a version (V1.0.3), and a fix version v1.0.3/fixbug-pay-fix is urgently needed, while v2.1.1 (based on V1.0.3) is still iterating normally. So this fix, when does it merge? In order to forget, it is generally recommended to merge branch bugs after typing.

Branch dependency conflict

Multi-branch development in the project, there will always be large and small, many and a little dependence conflict, in fact, there is no good way to face such problems, only experience, to take less bay road. 1. If function A and function B are weakly dependent, develop the two functions simultaneously. 2. If function A and function B are strongly dependent, it is recommended to develop in the same branch.