今天阅读了《构建之法》从67页到139页的部分，思考和体会如下。
1.第四章
这章讲的是两人合作。主要的点有代码规范、极限编程和结对编程，也讲到了与别人交流的一些技巧。
代码是给机器看的，也是给人看的，但我觉得代码更多是给人看的。因为我一直觉得不论何种科学或者技术发展到了什么程度，人都是最根本的。书中对代码规范方面讲的比较细致，形式上的包括我比较熟悉的缩进、括号、分行、命名、注释、大小写等问题和以前没考虑过的行宽、下划线等问题。我在平时写代码时，关于形式上的规范，首先考虑的是风格的一致性和代码结构的清晰性。在大一刚写代码的时候，总是最求紧凑，以为代码的行数越少越精简越好，所以运算符和标识符和操作数间是不加空格的，缩进使用的是Tab而不是空格(没有设置编辑器把Tab自动替换成四个空格)，在if等语句中的大括号能省则省，起头的大括号不独占一行。但随着代码量的逐渐增加，现在的代码风格和书上建议的已经几乎没有差别了。在代码的设计规范上，以c++为例，讲了goto函数的使用，错误处理，以及一些面向对象方面的问题。类似这种的规范性建议我还是第一次看到。在看C++Primer的时候，书中设计到了c++语言的许许多多的当面，也讲了一些设计的原则，比如什么内容放头文件，什么内容放源文件。关于类的构造、析构、继承、多态等，讲了应该怎么实现，但没有讲这些技术应该在什么样的情形下使用。
书中提到，仅在必要时，才使用类；仅在很必要时，才使用虚函数；仅在很必要时，才使用类型继承。这些提法我都是第一次听到。我的理解是：与类相关的很多技术，功能上很强大，也能通过比较简约的方式解决一些问题，但在使用上的难度还是有的，要求开发者对c++的诸多细节非常的了解，否则很容易出错。这就像c语言中的指针，用好了威力无穷，用不好会给调试带来极大的困难。在大一C语言课的时候，因为我们都还是小白，老师建议我们能用数组替代指针的时候就用数组，这样可以减少出错的几率。在这学期开的C2(c语言进阶)课上，听选的同学说，老师的思想是尽量用指针，因为效率非常高。比如传参的时候，传一个结构指针显然要比传结构快得多。
代码复审方面，书上说的很细致，给出了具体的复审步骤和核查表。如果能坚持对自己的程序做复审，我想时间长了能力一定会有很大的提高。很多道理的适用性是很广的，对自己的代码做复审，就是对自己做阶段性总结的特例，和"吾日三省吾身"是同样的思想。
在软工课上，我也进行也结对编程的实践，结果还是挺不错的，原因是多方面的。首先，我们两个人的编码能力都不差，其次，我们没有太心急写代码，而是先把助教提供的简单调度看懂了再写自己的，最后，我们俩都不是懒人，时间上还是有保证的。但是在复审方面，我现在的印象已经不深了。可能正是因为结对编程出的代码第一遍的质量就比较高，涉及到的debug比较少，印象才不深吧。
2.第五章
这章讲团队和流程。在软工的团队项目中，我们的队伍应该能算做团队的，我们有一致的目标，也有各自的分工。但在团队模式上，我们应该只能算是一窝蜂模式。而开发模式大概也只是写了再改模式。组建一个好的团队这件事，已经不是计算机科学的事情了，也不仅仅是软件工程的事情，考验的是队伍负责人的组织领导能力和组员们的交流合作能力。
3.第六章+第七章
这部分讲敏捷流程和团队开发，内容和我们的软工课实践相关度挺高的。里面讲到的开发流程，和老师对我们项目各个阶段的时间规划也比较相似。
书中讲到的很多方法和原则，都很有道理，如果能真正运用到我们的团队项目实践中，我想我们一定会有很大的提高。
对比书上讲的，我觉得我们的团队算是一个比较失败的团队。组织比较松散，对每个人的跟进工作不足，每日汇报几乎没有，开发基本上是波浪式的(比如本来定的7天的工作量，第一天就完成了，然后闲了十几天...)。原因可能有如下几点：1.不够重视；2.没有强有力的或者说对这件事上心的领头人。完美符合拖延症的特征：知道该做，但就是不想做。如果能重头来一遍的话，我想我可能会自己做PM(其实当初就很想做PM，但是队友希望我写代码)，并且使所有人都参与进来，充分发挥每个人的作用，而不是现在的只有几个人在写代码。但就算按我的想法重头来了一遍，一定还会遇到各种新的问题。不管怎么样，已经积累到了一份宝贵的经验。