第四章读后感
在经过对第四章的阅读后，我更加清晰地认识到了在项目开发中，规范二字的重要性，也新学到了除开代码规范以外，其他对于团队协作也很重要的东西，比如说构造函数的使用，模块化的编程思想，当然自己也对一些问题有着自己的思考。
其中最大的疑惑就是在于我个人对结对项目的理解上了，在经历过个人项目以后，我深刻地意识到模块化编程的重要性，因其能在很大程度上降低代码的冗杂程度，改善代码的可维护性，就像书中所说的：关于函数，最重要的原则就是只做一件事。所以我对于结对项目的理解就是：两人在相互商量以后，确定项目的大框架，包括项目下所需要的类、方法，然后进行分工，分别完成不同类的编写，最后就像拼乐高积木一样，将各自构造的零件平凑到一块。这种默认情况下自己对于结对项目的理解一直持续到了第四章快看到一半，直到看到书中所写“一对程序员肩并肩、平等地、互补地进行开发工作……”然后想法就完全被颠覆了，虽然是出于极限复审的角度来进行这种模式的结对编码，但是各自编写不同的类，方法，然后再复审不也是一样能很好的去审核么？更何况这种模式能极大程度上将两个人的作用同时发挥到极致，而书中的结对模式会让人有一种“1+1最多等于1.5”的感觉。
第二个疑惑其实也算是依附在第一个疑惑里面了，书中在说极限编程的时候提到了这样一句话“如果我们时时刻刻都处在代码复审的状态，那不是更好么？”首先，代码是一个一行一行敲下来的东西，不像人的思想，能够有一个大的框架，时时刻刻复审的极限编码就像是在别人在写文章，明明应该是看一个段落所要表述的意思、把握段落在文章中的作用，但是审核的落脚点却只停留在他每句话有没有语义通顺，字有没有写错，类似这种情况，所以在一个个零件编写完之后逐个地对方法、类进行审核不是更好么？
第十七章读后感
在阅读到书中对于绩效管理这一块的相关阐述时，也是引起了自己不小的共鸣，因为自己最近也是在学生组织内也是有需要出一份类似绩效考核、自评互评的方案，因为很多方面都无法考虑周全，所以一直是没有想到很好的解决方案，看完书中的阐述之后，虽然不能说是恍然大悟，但确实是受到了不小的启发，特别是看到书中对于清华园两颗树的比喻，读来真觉是神来之笔，放在代码的评判上再恰当不过。
而我的疑问则是有关书中对于团队贡献维度的阐述，“假设NBA球星科比布莱恩特到中国某俱乐部打球，由于种种原因，他没有打出巅峰时期的水平，低于自己和俱乐部的期望，但与俱乐部其他所有球员相比还是高人一筹，他应该得【差，20%】的评价。”
在这一段阐述中，科比薪酬低的原因仅仅在于没有达到俱乐部的预期值，就得到差的评价，但是在综合实力上，文中也是阐述到仍旧是比其他队友技高一筹，那么这就相当于一个外企海归程序员回国来到一家企业敲代码，技术水平超前，承担团队中的核心C位，只是因为相对于自己原来的状态来比较有所下滑，所以团队给出的评价是差，但是团队去评测一个人的贡献不是应该站在团队的立场上，看的不应该是他对于团队的贡献么？因为实力超出了团队的平均水平，或者说是超出了团队其他所有的人，那么无论是在球场、还是组队编码上，他们的核心地位都是不可撼动的，在很大程度上带起了团队的节奏，这个时候要是再把落脚点放在个人状态上去给出差评，不会有些不妥当么？