1. Cases and papers of paired projects.
http://c2.com/cgi/wiki?PairProgrammingCaseStudy
http://dwz.cn/1GOOvc
http://www.cs.utexas.edu/user/mckinley/305/pair-hcs-2006.pdf
2. The influence of personality on cooperation
3. Is there a code specification required?
1. These specifications are all things that waste everyone's programming time, affect people's development efficiency, and waste time under the bureaucracy.
refute.
Bureaucracy: an administrative power system established according to the division of functions and positions and the principle of hierarchical management.
These specifications are summarized by predecessors, and everyone can understand the code specifications by default. These code conventions are convenient for those who code frequently. In the working environment of the entire software team, it can greatly save the time required for team programming and improve the team's work efficiency. Maybe the code specification will feel constricted for new users, but after familiarity, the gain in program comprehensibility will greatly compensate for the previous loss.
2. I am an artist, a craftsman, and I have my own norms and principles.
refute
Mavericks may be fine for developers, but in the work of software teams, the industry ethic of artists is not. A person's norms are not norms, and no one's personal norms and principles can override team norms and team principles. If team work is severely affected because of one person's personal norms and principles, it is better not to have such norms and principles.
3. Norms cannot be enforced uniformly, and many exceptions should be allowed.
refute
Specifications should be as consistent as possible, and if there are exceptions, they can only be a few, not many. Personally, I think there are too many exceptions, so they can't be called exceptions.
4. I am good at formulating coding standards, just listen to me.
refute
Unity is valuable. A programmer can never work alone. Code specifications must be emphasized when working in a software team. This is the experience accumulated by the team. In team work, the benefit of fully adhering to code specifications is to reduce the cost of communication when reading the code, but norms and principles that work on one team may not necessarily work on another. If you have comments on the existing code specifications and principles, you can revise and publish new specifications in a certain way. But before the new specification is released, follow the old specification and safeguard the interests of the team.
5. How hard is it to read other people’s code?
How to make the code easier to read and maintain when writing it yourself.
induction:
1) Stick to one naming pattern
2), do not arbitrarily abbreviate English words
3), use assertions to record preconditions and postconditions
4) The design of the C language standard runtime library is not very good. don't imitate it
5) Don't write "smart" code
6), divide the source tree by functional units, not by organizational structure
6. Bad habits in pair programming - have you experienced it and how to remind your peers to improve
Pair programming is never a one-person thing, so we as team members have to abide by some norms, so that we can make our team better and our programming work can be carried out. First of all, communication is necessary. We can also formulate some code of conduct and work requirements. When communicating, we must also pay attention to our personal attitude and tone of exhortation to communicate.