The comprehension of the 4th chapter of the Law of construction

Fourth Chapter

After reading the fourth chapter, I understand that the fourth chapter is an introduction to the cooperation between two people.

Two people to write software first to code specifications, further elaboration is to code style specification and code design specifications. Code style specification for pairs, the first thing to do is to unify the development tools, and then pay attention to the source file format, layout, line wrapping, appropriate annotations, naming conventions. That is concise, easy to read, no ambiguity. Code design specification: for functions. That is, using simple constructors, preferably the default constructor, because simple constructors enhance ease of use, and for error handling. Include (logical and programming errors, set errors, corrupted data ...), and then add some appropriate error handling to the program, for exception handling. Not to be absolutely certain of the situation, do not swallow the anomaly. If you understand why the exception occurs in a specific environment, it is recommended that you capture specific types of exceptions. The best way to keep the call stack is to use an empty throw statement when catching and re-throwing an exception.

Next is code review, peer code review is a common practice in software development projects, and the most basic means of review is peer review. Code reviews help identify potential bugs and standardize project coding standards, which are helpful for projects and teams. Code reviews involve four areas, the developer itself, the reviewer, the learner, and the preacher. It can be said that through the entire area of technology and knowledge, peer review can improve the team's average skill level. In addition, it has the invisible pressure to encourage developers to write better code. Second, understanding the capabilities captured from code can help propagate (share) system knowledge across team members. Also, the overall quality of the project completed by the team is far higher than the total amount of work done by the developer alone. Moreover, each developer can bring different skills, realize collaborative programming, and "contribute" to the team. In short, code review not only focuses on the code, but also the growth of the entire team, which makes the whole team more cohesive.

Next is pair programming. In a nutshell, 2 programmers, the same set of devices, work together, analyze, design, write test cases, encode, unit test, write documents, work equally and complement each other. More figuratively, one person acts as an "executive" role, and is only responsible for programming. The "Observer" (or "navigator") is also responsible for detecting bugs and controlling the overall design. Pair programming often takes about half the time to write higher-quality code compared to the two-bit programmers who work independently of each other. If you are a performer, when you complete a program as quickly as you can, you tend to overlook some problems, and at this point the partner is guaranteed. If you are an observer, review each other's code carefully, consider possible errors, and how to simplify and improve the design. In addition, because of the complexity of the performer's work, switching roles helps improve capabilities. So change roles at least every half-hour, and fully invest in and adapt to different levels of work. Also, no matter who master the macro direction, who is responsible for the details, the most important thing is to work with tacit understanding and efficient completion.

The last is the different stages and techniques of the two people's cooperation. In my humble opinion, the relationship between the two sides is the strongest, the most distinguishing factor is the efficiency gap between them. Many things can affect the efficiency of programmers, including their previous: background, personality, skills, experience, cultural background, domain knowledge, language knowledge, and so on. If we combine these together, we can draw "efficiency". There may be another way to think about "efficiency", the potential strength of their output, the speed and quality of programming. When the pair of pairs start to work effectively, there are often a lot of things to consider, so talk to each other often. For me, the human factor is equally important compared to programming and technology. Because working with others to write software, it is clear that technology is necessary, but teamwork is equally important.

Finally the last hope knot pair programming happy!

The comprehension of the 4th chapter of the Law of construction