两人合作
本章介绍一些非常实用的编程技巧以及两人合作的技巧。我觉得这几节的内容非常实用，遵守这些规范很关键，学会两人合作非常重要。
4.1 代码规范
如果你写的代码自己都看不懂，那别人更看不懂。你的同事看到你的代码只会想把你暴打一顿。因此，遵守代码规范，写出好的代码才符合共同利益！代码规范可以概括为两个部分：
-
风格规范
一些表面规定，但实际很重要。 -
设计规范
程序设计、模块之间的关系、设计模式等通用原则。
4.2 代码风格规范
简明、易读、无二义性
4.2.1 缩进
Tab or 空格？可以将Tab设置为4个空格，因为Tab在不同的情况下显示不同的长度，干扰阅读体验。
4.2.2 行宽
以前的打字机行宽为80字符，现在偏小，可以限定为100字符。
4.2.3 括号
在复杂的条件表达式中，用括号清楚地表示逻辑优先级。
4.2.4 断行与空白的{ }行
if (condition)
{
DoSomething();
}
else
{
DoSomethingElse();
}
4.2.5 分行
不要把多条语句放在一行上，更严格地说，不要把多个变量定义在一行上。
4.2.6 命名
不同的编程语言命名建议均不同。总的来说，考虑以下建议：
- 不要提及变量类型。例如：不用写arraylistOfHolidays，直接写holidays。
- 避免过多描述。例如：游戏的终极boss。不要写 theFinalBattleMostDangerousMonster，可以直接写 boss。
- 如果信息包含在上下文中，不必重复写在变量名上。例如，有一类EmployeeHealthRecord，有员工姓名变量，直接写name，而不用写employeeName。
- 避免可要可不要的修饰词。例如，state，data，value，engine，entity，instance，object，manager，，，如果不要这些词，程序会变得难读懂吗？
4.2.7 下划线
下划线用来分隔变量名字中的作用域标注和变量的语义。
4.2.8 大小写
Pascal——所有单词的第一个字母都大写。
Camel——第一个单词全部小写，随后单词随Pas-cal形式。
一个通用的做法是：所有的类型/类/函数名都用Pascal形式，所有的变量都用Camel形式。类/类型/变量：名词或组合名词，如Member、ProductInfo等。函数则用动词或动宾组合词来表示，如get/set、RenderPage()。
4.2.9 注释
注释是为了解释程序做什么（What），为什么这样做（Why），以及要特别注意的地方。一个误导的（Misleading）注释往往比没有注释更糟糕。
4.3 代码设计规范
设计规范.png
4.4 代码复审
在代码规范的框架内正确地解决问题
复审.png
4.5 结对编程
两个人一起合作编程
一个是驾驶员，负责实施代码；一个是领航员，负责指引方向。
如何结对编程？
1. 驾驶员：写设计文档，进行编码和单元测试等XP开发流程。
2. 领航员：审阅驾驶员的文档、驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。
3. 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。
4. 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。没有“我的代码”、“你的代码”或“他/她的代码”，只有“我们的代码”。
5. 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
6. 设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好。
4.6 两人合作的不同阶段和技巧
不同阶段和技巧.png
附录
- 结对编程中不好的习惯—你经历过么，如何提醒同伴改进？
1. 不拘小节的人
两人在一起近距离地工作，但是却不注意个人卫生和互相尊重。开始合作前，吃了很多大蒜就来了。
2. 喜欢发号施令的人
总是对敲键盘的人说：“到末行，加个反括号，然后……”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。
3. 拼写纠错者
坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正地进行导航。
4. 深藏不露者
仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。
5. 跳跃很大的人
他们喜欢在代码中进行大范围的跳跃，这样领航员便不知道进行到哪里了。
网友评论