The law of construction--the fourth chapter

This chapter is about "Cooperation between two people", well-known-"Three Stooges equals", no disorder is engaged in what activities or work, visible cooperation is the power of 1+1>2

First, importance:

The process of software development is complex, obviously a person's wisdom is not enough, encounter problems together to solve, work together to share can make development more efficient. Later to the company team work, cooperation to a large extent to achieve complementary advantages, such as someone good interface design, some people are good at realizing the function, such cooperation can reduce the workload to improve the overall development efficiency. Some people technology is very good, but in communication this is very deficient, this is very unfavorable cooperation, in the development of the project, once the project problems or their own changes to some code functions to communicate with peers in a timely manner, otherwise it will bring a lot of unnecessary trouble for others, such as the database table field has not been agreed to modify the field, Other developers happen to use this table, but they don't know that the field is being modified, which will bring a lot of extra work.

Ii. How to Cooperate: Code specification, code review

1, cooperation is easy to say, the good cooperation is bound to increase the efficiency of quality, if only to do their own certainly lose the significance of cooperation

As a programmer, it is inevitable to read other people's code for a variety of reasons, when we tend to have countless vomit and tiredness. Although now we are writing in the school is the project and all is a person to complete, to such a scene has not been deep experience, but later go out to work, avoid to join the new project, read other people code is often, the following is how to code specification:

1.1 Remove unused class references, eclipse inside Ctrl+shilft+o

1.2 Remember format code, eclipse inside Ctrl+shilft+f

1.3 Don't skimp on obsolete old code, eclipse inside Ctrl+d

1.4 Do not write redundant and useless code

1.5 empty lines can be used to separate relatively separate blocks of code, which facilitates reading and understanding

1.6 Do not appear in two places exactly the same code, can be reused

1.7 Naming classes, methods, variables caution with shorthand, pre-development provisions, and to make sense

1.8 Put all the class variables to the front, do not mess up, find it very hard

1.9 Split large class, Big method, if the class has 10,000 rows, if the method has 1000 rows, looked very uncomfortable

1.10 Good at using annotations, can remind oneself write what content, and name of English, not necessarily others understand oneself want to express content

2, code review: In the "code specification" within the framework of the correct problem-solving (self-review, peer review, team review), the most basic means of review is peer review

Purpose of review: Identify code errors, find logic errors, discover algorithmic errors, identify potential errors and regression errors, identify possible improvements, educate transfer experience to developers

How to review:

Pre-review: The code must be compiled successfully, on all required platforms, at the same time to compile the debug Reteil version; The programmer must have tested the code

In-person review, independent review or other means

After review: Correct obvious errors, record errors that cannot be modified, and record one of your own "common mistakes" (one step closer to self-review)

The law of construction--the fourth chapter