构建之法第四章

1.结对编程是一种编程模式，从字面上理解就是两个程序员并排坐在一台电脑前，面对同一台显示器，他们一起进行需求分析、设计、编码、编写测试用例、执行单元测试和集成测试，甚至一起写文档。这么说吧，基本上软件开发流程里的所有开发环节他们都需要一起肩并肩地、平等地、互补地完成工作。两位程序员坐在同一工作台前开发软件。与两位程序员各自独立工作相比，结对编程能编写出质量更高的代码，对开发人员自身来说结对工作能带来更多的信心在企业管理层次上有效地促进交流分享知识更好的应对人员流动。

2.性格对合作的影响：个人性格对团队合作影响至关重要，因为团体合作需要互相磨合，需要熟悉对方的工作方式，要步调一致，完成项目。

3.是否需要代码规范：

1）我认为这种观点是不对的，

计算机只关心编译生成的机器码，你的程序采用哪种缩进风格，变量名有无统一的规范等，与机器码的执行无关。但是，做一个有商业价值的项目，或者在团队里工作，代码规范相当重要。“代码规范”可以分成两个部分：

代码风格规范——主要是文字上的规定，看似表面文章，实际上非常重要

代码设计规范——牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则

2）各行各业都有自己的规范，除了自身习惯，也要遵守各项规定来约束自己的行为，因为自己的判断不一定全是正确的，所以要有一定的标准来规范自己的言行。

3）但是规范也应该根据实际情况来制定，千篇一律照本宣科有时候也会起到反效果，最好的就是同一个团队商量出一套最适合自己的规范与原则。

4）在进行规则制定的时候，团队的沟通很重要，如果作为一个独裁专制者，认为所有人4都应该听自己的，那么反而会起到反效果，最好的应该是合理得了解大家的需求，然后再制定规则。

4.代码复审的讨论：

2. 代码复审

这次我复审的代码是邵楠的代码。

复审结果如下：

(1.概要部分：

　　这次的作业是编写自动生成四则运算的程序，要求包括整数及真分数。我复审的代码基本符合题目的需求，并且加入了成绩展示并做错题改正的功能，通过审查程序，代码并没有问题，可以准确运行出结果，可读性较高，并有相应的注释。但仍存在除法运算，除数为0的问题。以及真分数的判断。

(2.设计规范部分：

　　设计流程比较完整，功能齐全，整体简洁，没有存在不需要的代码。

(3.代码规范部分：

　　整体完整，功能注释齐全。

(4.具体代码部分：

　　程序中变量名称的命名没有规范，不可以使用简单的代名词，无法代码其含义，在命名上应使用具有意义的英文、拼音缩写。

(5.效能：

　　并没有明显可优化的部分。

(6.可读性：

　　代码可读性较高，不理解的地方都有足够的注释

5.阅读别人的代码有多难

每个人的写作风格不同，要想让别人能够读懂，注释是必不可少的，同时写作要规范，方便他人读懂和修改，不要按照自己的思维惯性来写。

6.结对编程中不好的习惯--你经历过吗，如何提醒同伴如何提醒同伴改进

比如不拘小节的人两人在一起近距离地工作，但是却不注意个人卫生和互相尊重。开始合作前，吃了很多大蒜就来了。

这个时候我们可以委婉地提醒别人注意个人卫生，介绍一些好的卫生习惯给他，在不破坏团队合作的情况下，保持好团队工位上的卫生，使团队在编程工作中能更好的发挥合作的精神。

比如喜欢发号施令的人总是对敲键盘的人说：到末行，加个反括号，然后......他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。这个时候我们就应该提醒下对方，加强团队的讨论，对项目的架构分层过程进行讨论，然后划分好各自的项目分工，每个人负责自己的那一块，然后这样就能更好的解决这一部分。

比如拼写纠错者坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正地进行导航。我觉得在结对编程过程中，应该需要明确小组的分工，每个人负责好自己的那一部分，尽可能避免出错。

深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码，关于改用什么办法，该选择哪种设计，领航员和实施者之间没有完全交流。我觉得这过程中，还是要加强与小组成员的沟通，防止因为没有交流而产生大方向的错误。

跳跃很大者，他们喜欢在代码中进行大范围的跳跃，这样领航员便不知道进行到哪里了。这个过程中，我觉得我们还是应该事先明确需求描述，提前解决在项目过程中，要怎么解决工程的问题，防止出现大部分的跳跃。

结对编程中，总会出现这样那样的错误。所以我们就应该多和成员加强沟通，防止因为习惯的问题而出现过程的失误。

---恢复内容结束---