合作与审核

首先是代码的规范问题。关于这个代码规范，我并没有花很多时间去阅读，可能是自己的习惯，代码风格一向都是简约而规范。就比如在写一些if语句的嵌套时，很多人都习惯了不加括号，即使加括号可能是多此一举但我还是习惯加括号，不为别的，就为自己甚至别人看上去能更加清楚，这并不是画蛇添足，我觉得更像是画龙点睛。不过这一节对变量的命名我倒是深有感触，我们习惯了教科书上的一些命名，所以有时候看到问题不假思索的就为变量命了书上常出现的名字。但是当我们之后再去复核时，我们往往不懂这些变量在这个问题中的意义，很快就忘了我们为这个问题所设的变量的作用。这是很麻烦的一件事，本来就是我们自己敲的代码，自己思考着写出来的逻辑，过了一段时间看着代码却不记得了，如果当初对一些关键变量的命名可以直截了当的点明，我们很快就可以想到以前的思路了。

其次就是注释。我们敲代码的时候都没有写注释的习惯，起码我没有。这一问题值得我去反省，写注释花不了多少时间，但是我们在敲代码的时候这些时间却显得弥足珍贵，其实注释是在帮助我们理解代码行的作用，并不是在浪费时间，跟变量的命名所起的作用相似，都是起到帮助的作用。

代码的复审有“教育”和“传播知识”的作用。重要的是，不管多么厉害的开发者都会或多或少的犯一些错，有欠考虑的地方，如果有问题的代码已签入到产品代码中，再要把所有的问题找出来就更困难了。我们学习软件工程的都知道，越是项目后期发现的问题，修复的代价就越大。代码复审正是要在早期发现并修复这些问题。除了代码复审以外，还有编程结对，在结对编程模式下，一对程序员并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起做单元测试，一起做集成测试等等，这些搭档关系就是结对编程，也就是合作关系。

合作关系有不同的阶段。1、萌芽阶段。两人刚刚认识，大家都有礼貌，一般交流不少，试图避免冲突和容易引起挑战的观点。2、磨合阶段。手足无措，显得很笨拙。3、规范阶段。一些成文或不成文的规则逐步建立起来了。4、创造阶段。5、解体阶段。散伙。那么，在两个人合作阶段，如何说服对方呢？首先双方要意识到，问题早点出现要比晚点出现要好很多，我们有机会早日解决问题。除了技术方面的考虑之外，一个成熟的工程师要琢磨对方的话语和观察对方的肢体语言，了解它们所表示的潜台词。试着从对方的角度看待问题。同时也要根据情况采取不同的方法影响别人。书上写了几种影响他人的方法：断言、桥梁、说服、吸引。

总结一下这章内容，主要讲了我们程序员该如何规范的敲代码，让我们自己甚至别人能更容易的理解，以及如何合作、如何影响他人去接受你的观点。看完这章，我明白了团队中还有更小的团队，两人为一组时，必不可少的就是观点的碰撞，这时候需要的就是观点的陈述了，这一章对合作方面讲述的很深刻，让我对团队流程有了一个更深入的了解。

《构建之法》——软工学习进度（3）