[Practice 10] Coding

If we say that the most face-recognition thing for a man is that she is always with a beautiful lady, attracting others. The best thing programmers can do is write beautiful code, which can lead to numerous sighs. Interestingly, we always have the opportunity to see this phenomenon: although some old modules are not well designed, but the code quality is good, they are still stable, but some modules with good design concepts, but it was written in a mess. Code is the final product of design and a programmer's basic skills. If a person is fond of talking about his code, he can see whether he is a "real master" or "EMPTY homesick" at a glance ". Code management of project management is generally expected to achieve the following goals: 1. Avoid killer: "experts are neither trained nor disciplined, this is because it is rare, and the quality of achieving masters is not often possessed by all beings. However, the hidden killer in the project team can reduce its risks and dangers through management. A/B corner audit, check-in code control, and so on are all levels. 2. ensure the quality of the Code: the Code may not be as beautiful as the highly-handwritten code. If you have more points, you will be fattier, and if you have less points, you will be thinner, however, management can ensure the Logic definition and readability of your code, reduce boundary errors, and reduce low-level errors. For example, tool scanning, unit testing, and daily building. 3. Train personnel: "the red and the black of the near Ink" has a huge influence. Through interactive communication in the coding stage, some members can quickly break away from the "shanzhai". enter the "Occupation" status, especially for new employees. Project management is divided into the following five elements: 1. Stakeholder Expectations-goalsThe impact of stakeholders in the coding phase is very small. You can skip this section first. 2. Sand Table-ideas1) The Code that has been listed before the start is the same as the design. In many cases, it is not that you do not want to write good code, but that you do not know what a good code is like. Therefore, before the project team starts coding, explaining the good code will make the team members have a learning goal before they start work and make the coding work more interesting. It is better to find out the examples of excellent Code related to the project team, and get twice the result with half the effort, for example, the Code of similar businesses in the department.
2) The open read-only plan remembers that there is a story about the efficiency of research in management, and found that the workers are summoned to an experimental environment, in the case that the facilities are identical, their work efficiency and quality are greatly improved. Many influencing factors are eliminated one by one, and the reasons for increasing attention are finally found. People are expressive. When we are concerned about what we have at hand, we often want to express our best side, so we are human. This is the role of Code read-by-read. the read-by-read plan published in advance is more important than the actual read-by-read plan. Pay attention to these points when arranging the out-of-read plan. A. The out-of-read members should be deterrent and authoritative to avoid everyone's complaints. For example, if you are looking for experts, architects, supervisors, etc. B. The reading results should be published in good or bad ways, so that the project team can form a benign atmosphere. C. When there are many project team modules, we can spot check a certain percentage of modules for reading. In this way, we should not clarify the modules when publishing the reading plan, so as to avoid the failure of the module authors in the reading plan.
 
3) angle a/B Audit is not enough only for the read-only plan, because reading usually requires many people to participate, it is impossible to take too long, so many detailed logic reviews are not available. In addition, when the Code of this module has been or is close to completion, the time for the read-only module is too late, and it tastes like a boat. What works with the read/write plan is to review the/B angle. We can clarify the/B angle relationship of the project team at the design or earlier stage. The advantage of A/B is that the Code is reviewed in a timely manner, and the/B angle in the test phase can bear pressure on each other. The common composition of A/B is as follows: a. The project team is divided into groups. The team lead is an expert of B and some modules of the project team, these experts are responsible for the B-angle C in the corresponding field, and several persons in a module are working together. When they are A/B-angle D and the project team is not big, the Project Manager or quality manager is responsible for B-angle.
4) code checklist and tool scan code checklist are checklists that combine common error sets, such as potential deadlock risks and C ++ usage. The tool scan aims to eliminate some low-level errors, such as memory leakage. In many cases, it is difficult to troubleshoot low-level errors.
5) the core of unit testing is two points: A. Easy-to-use and time-saving unit test case compiling tools, for example: c ++ test and other B. Manage unit test cases. Instead of only one test, the unit test can be automatically executed every time the Code changes and every time the Code is re-compiled. If the unit test can only be used for the first time, the input-output ratio will be much smaller. C. The ability to execute unit test cases on the target machine, which can avoid a large number of piling and lead to a decrease in work efficiency.
6) code check-in control is usually an implementation method that forces corner a/B. That is, the code check-in permission of corner a is revoked, and only corner B can be checked in, this ensures that the review frequency of corner B can reach every package.
7) Building a daily build means that after the code starts, the daily environment will automatically obtain the code from SVN/VSS for compilation and execute the corresponding unit test cases. errors are reported every morning. The benefit of daily building is that the system is continuously benign integration, avoiding code check-in and compilation errors after joint Debugging starts. It takes a lot of time to eliminate these errors, and easy to make mistakes.
3. Plan Formulation 1) Code read/write plan the Code read/write plan, such as the second point above, requires you to reserve experts and architects in advance and publish the plan in the project team.
2) The Configuration Management Plan involves code check-in permissions, compilation environment maintenance permissions, and so on. For example, if a large project team has no control permissions in the compilation environment and no operation specifications are specified, it is easy to be confused.
3) The unit test plan is suitable for units in not all cases. For example, for a change to an old module, this module depends on a lot of external resources, and there is no unit test case before. This will lead to the compilation of the unit test case for the change, which is very costly, in this case, we need to weigh the input and output. It may be better to find experts in this module for review.
4. Risk management 1) The coding progress is not transparent. Most people are used to working in a relaxed and tight way. "I still remember that when I was in college, the teacher assigned my homework for a two-week period. The class was the deadline for handing in my homework. During the class, most of the students in the class took the borrowed homework ". The time of the encoding phase is relatively long in each phase before the transfer to integration. However, the progress at this stage is not well measured. We often see that the coding progress of a module quickly ranges from 0% to 90%, and then it takes two times to get from 90% to 100%. Failure to effectively know the progress of the project is the risk of the project. There is a good practice here for reference. The encoding schedule is exported from the estimation table, because the granularity of each Estimation item in the estimation Table generally does not exceed 2 days. In this way, when the encoding progress table is updated, the percentage can be removed and only two statuses can be updated, incomplete and complete. The calculated project progress is relatively accurate, it can also help the team members to clarify their current work progress.
2) code quality for new employees the growth of new employees requires the effort of the team. For them, we often need to have more frequent code reviews, guidance, or a more responsible B. Although new employees are inevitable, their potential is unlimited. After being patiently trained, they will always be pleasantly surprised.
3) identifying the progress of the project team of the risk module is different from that of the same team. Quality is always good or bad, in the whole process, we can find these risky modules through the above methods, and then take adjustment measures as an indispensable part of project management. 4) when there are missing tasks in demand implementation, they are often not fully implemented according to requirements. In code implementation, because everyone's thinking is already at a very detailed level, therefore, when you check the system requirements or requirement tracking matrix, you can easily find missing items.
5. Team Management 1) rewards and punishments are built on a daily basis to increase everyone's attention to this matter. Of course, the mistakes made on a daily basis are not very serious and easy to detect. For this scenario, it is inappropriate to adopt overly strict punitive measures. For example, you can take the following measures: a. The cumulative number of errors. If the overall number of project teams reaches 5, the team members may ask for fruit or drinks. B. The result of building is automatically announced by the system every day.
2) there are rewards and punishments for the read/write plan. Because of the use of external resources, the plan is more authoritative, and the punishment and reward should be heavier. For example, for a Member who has poor code reading results, he or she will be disqualified from a this quarter. The member with good code reading results will receive prizes and excellent quarterly assessments.
3) progress it is necessary for the project team to review the progress of last week and the plan for next week at least once a week on a regular basis in the project team, so that everyone can feel a sense of belonging to the entire team, in addition, you can learn the progress of other people and make a horizontal comparison so that you can adjust the progress yourself.
4) strictly implement the plan. The time points of the project plan at this stage are determined. Do not adjust the Milestones unless the project manager is sure to control the subsequent progress.