作者：非妃是公主
专栏：《软件工程》
个性签：顺境不惰，逆境不馁，以心制境，万事可成。——曾国藩
专栏地址
专栏系列文章
1.了解代码复审的三种形式
2.掌握“代码复审核查表”的“概要部分”
概要部分：
1） 代码符合需求和规格说明么？
2） 代码设计是否考虑周全？
3） 代码可读性如何？
4） 代码容易维护么？
5） 代码的每一行都执行并检查过了吗？
3.理解好的复审者的“更高要求”
- “这么修改之后，有没有别的功能会受影响?”
- “项目中还有别的地方需要类似的修改么?”
- “有没有留下足够的说明，让将来维护代码时不会出现问题？对于这样的修改，有没有别的成员需要告知?”
- “导致问题的根本原因是什么？我们以后如何能自动避免这样的情况再次出现?”
4.理解结对编程，其优缺点，以及合适和不合适的场景
结对编程（Pair Programming）
- 驾驶员/领航员，两人共享一个键盘，电脑，屏幕
- 驾驶员：写设计文档，进行编码和单元测试等开发流程。
- 领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率，写测试用例；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。
- 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。 领航员要控制时间。
- 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。
只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
- 设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好。
结对编程的优点：
- 提高设计质量
- 更好的设计，避免愚蠢的bug，
- 降低成本,分享知识，更少的debug时间
- 提高解决问题的信心 结对经常能解决 “不可能的任务（1987 ，Intuit） “很多有经验的工程师觉得结对编程效率不高” 他们单独编程了 10 年，结对了1 小时，就觉得效率不高，很正常。 结对100 小时之后再评价。
- 提高士气 觉得自己的工作有另一人认可. 减轻风险 在团队中有一些 “知识的冗余”，降低了成员离开的负面影响 提高效率
- 两人在一起不好意思偷懒或开小差上网
结对编程的缺点：
- 工作方式的不同
大多数人觉得喜欢一个人工作- 让人感觉到威胁
新手 vs. 老手- 时间可能花在培训上面 （也有价值）
老手vs. 新手- 对个人情绪，自尊的影响
“my code” vs. “your code”
结对编程适合的场景：
- 降低容易犯的错误
- 新手 + 新手， 或者双方各有明显弱点 探索一个新的领域
- 传播知识和技能 老手 + 新手 也可以
结对编程不适合的场景：
- 需要深入地研究的项目，需要一个人长时间的独立钻研； 在做后期维护的时候，如果维护的技术含量不高，只需要做有效的复审即可；
- 如果验证测试需要运行很长时间，那么两个人在那里等待结果是有点浪费时间；
- 如果团队的人员要在多个项目中工作，不能充分保证足够的结对编程时间，那么成员要经常处于等待的状态，反而影响效率；
- 关键是如何最大限度地发挥“领航员”的作用，如果用处不大，也就无需结对
扫一扫
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
