第四章读后感
在经过对第四章的阅读后，我更加清晰地认识到了在项目开发中，规范二字的重要性，也新学到了除开代码规范以外，其他对于团队协作也很重要的东西，比如说构造函数的使用，模块化的编程思想，当然自己也对一些问题有着自己的思考。
其中最大的疑惑就是在于我个人对结对项目的理解上了，在经历过个人项目以后，我深刻地意识到模块化编程的重要性，因其能在很大程度上降低代码的冗杂程度，改善代码的可维护性，就像书中所说的：关于函数，最重要的原则就是只做一件事。所以我对于结对项目的理解就是：两人在相互商量以后，确定项目的大框架，包括项目下所需要的类、方法，然后进行分工，分别完成不同类的编写，最后就像拼乐高积木一样，将各自构造的零件平凑到一块。这种默认情况下自己对于结对项目的理解一直持续到了第四章快看到一半，直到看到书中所写“一对程序员肩并肩、平等地、互补地进行开发工作……”然后想法就完全被颠覆了，虽然是出于极限复审的角度来进行这种模式的结对编码，但是各自编写不同的类，方法，然后再复审不也是一样能很好的去审核么？更何况这种模式能极大程度上将两个人的作用同时发挥到极致，而书中的结对模式会让人有一种“1+1最多等于1.5”的感觉。
第二个疑惑其实也算是依附在第一个疑惑里面了，书中在说极限编程的时候提到了这样一句话“如果我们时时刻刻都处在代码复审的状态，那不是更好么？”首先，代码是一个一行一行敲下来的东西，不像人的思想，能够有一个大的框架，时时刻刻复审的极限编码就像是在别人在写文章，明明应该是看一个段落所要表述的意思、把握段落在文章中的作用，但是审核的落脚点却只停留在他每句话有没有语义通顺，字有没有写错，类似这种情况，所以在一个个零件编写完之后逐个地对方法、类进行审核不是更好么？