马上就要开始进行结对项目了，正需要本书第四章“两人合作”和第十七章讲到的关于团队的内容，于是我认真阅读了这两章的内容，期望能对我的结对项目有所帮助，在这期间有收获有认同也有疑惑，接下来我就谈一谈我在阅读第四章和第十七章的过程中的感想与疑惑。
这一章首先讲到了代码规范，开篇的代码清单4-1就引起了我的共鸣，这种代码就完全不具有可读性，在两人合作中这种风格的代码一定会是绊脚石。虽然我已经修过C语言和Java的课程了，但是对代码规范这一部分还是了解不是很全面，这促使我对接下来的内容进行学习。
首先引起我注意的是缩进的问题，我在平时写代码的过程中一般都是使用Tab键进行缩进，一直也没有遇到过影响阅读体验的问题，而且最主要的是我在学生工作中写文档时的缩进是被要求使用Tab键进行缩进的，在这里使用Tab键就代表着这比较规范，在代码中却建议不要使用Tab键，这与我原来的工作经验就有了一些冲突，让我有一点困惑。因为我觉得书上虽然说Tab键有时候会显示不同长度，但如果全篇都使用Tab键的话也很整齐并不太影响阅读感。但我还是决定按照老师说的来做，因为如果大家都这么做的话我最好跟大家保持一致，这样也有利于他人的复审。
在之后的“分行”部分中，有这样一条规则：
“不要把多条语句放在一行上”
这条规则我可以理解，因为在debug过程中需要一行一行执行，这种结构不利于debug的进行；但是接下来这条规则：
“不要把多个变量定义在一行上”
我就不太理解，于是我就从网上进行了相关搜索，发现有人和我有同样的疑问，内容如下：
但是定义变量出的错误我感觉都是很浅显的，写到一行并没有什么问题；这些回答虽然有道理但还是不能让我信服。
在这之后我对命名和注释的规范进一步了解，在这一部分我还是相对比较清楚，实际应用的也比较好一些。
在4.3.4节中，我接触到了一个有点陌生的名词：析构函数，我对它到底是什么不太了解，于是就进行了上网搜索，网上给出的定义是这样的：
析构函数(destructor) 与构造函数相反，当对象结束其生命周期时（例如对象所在的函数已调用完毕），系统自动执行析构函数。析构函数往往用来做“清理善后” 的工作（例如在建立对象时用new开辟了一片内存空间，delete会自动调用析构函数后释放内存）。
这里说析构函数帮助释放内存，但是释放内存不是系统自动进行的吗？为什么还要使用析构函数呢？于是我就搜索答案，得到了以下结果：
由于大部分结果都与C++有关，所以我就在想析构函数是不是C++特有的呢？但经过之后的搜索，我得知是Java中没有析构函数或是相关概念，代之以Java垃圾回收机制，而析构函数也并不是C++特有的，只是因为没有特别了解Java和C以外的语言，而且平时使用的时候也很少使用析构函数，所以才造成了这种感觉。
接下来了解了代码复审的步骤和要复审的部分，由于我以前并没有代码复审的经验，所以我学到了新东西但并没有什么疑问，在这次的结对项目中我应该会有更多的体会和想法。
对于书中的结对编程方式我感到很新奇，原来以为就是两人合作一人写一部分的代码，没想到是两个人一起工作，一个人起引导作用另一个人实际敲代码。但是从我之前的经验来看，这样真的能有很好的效率吗？我有点怀疑这种工作模式的效率。我还是觉得两个人分别专心工作，再互相交流自己不会的问题这样效率较高。不过也许两个人经过磨合之后就能发挥出1+1>2的效果，这种方式还是有待我在结对项目中体会一下。
最后的两人合作的技巧这一部分给了我不少启发，这让我第一次意识到反馈清晰地分为了三个层面，还提供了委婉地提出改进意见的放法，这也给我今后的说话方式提供了参考，不要说出太无可挽回的话，营造和谐的人际关系。
我对4.7练习与讨论里的2.性格对合作的影响有点感兴趣，于是就找了一个网站进行了测试，题不多，附上链接大家也可以测一测作为参考~
链接： https://www.16personalities.com/ch
在这一章我学到了如何当好一个领导，对不同类型的人分配到合适的岗位上，这里的对动力和能力的划分让我十分认同，这不就像是我们刚入学虽然知识量不多，但对这个专业都很好奇，有兴趣，学着学着也许遇到困难，挫折，有的人就放弃了，就像文中的“果冻”，还有虽然比较努力，学得不错，但渐渐的觉得也没什么意思，就像“九条”一样，还有一部分人学着学着发现自己更爱这个专业了，就像“荔荔”一样。
之后是团队发展的各个阶段，这对于不久之后的团队项目十分有用。在这一部分的责任板块中，有这样一句话：
加强责任感的最好机会是周期性的目标检查会议。
我对于这句话有些疑惑，我认为仅仅是检查目标的话虽然会督促大家工作，但是也有可能会使得一些人为了赶工作而降低对质量的要求，我认为这是得不偿失的，关于加强责任心，我觉得可以做一些团建活动，加强成员的归属感，重视每一个人的工作，让他们感觉自己对团队是有贡献的，我从这些年的团队经验中得到了这些体会，如有不同想法欢迎与我探讨。
在之后的猪，鸡和鹦鹉的故事还有17.5中对人的分类都让我更清晰地了解了团队中不同的人，在这里附上“汉芯事件”简介以供大家参考。
汉芯事件（Hanxin events）是指2003年2月上海交通大学微电子学院院长陈进教授发明的“汉芯一号”造假，并借助“汉芯一号”，陈进又申请了数十个科研项目，骗取了高达上亿元的科研基金。中国亟待在高新科技领域有所突破， 自主研发高性能芯片是我国科技界的一大梦想。陈进利用这种期盼，骗取了无数的资金和荣誉，使原本该给国人带来自豪感的“汉芯一号”，变成了一起让人瞠目结舌的重大科研造假事件。
之后提出了很多绩效考核的方法，每一条好像都不是特别完美，但是我很认同那句话：任何一种衡量方法都比完全不衡量要好。即使是不完美的绩效考核方法也会促使团队成员做得更好，希望有助于我们之后的团队项目。
转载于:https://www.cnblogs.com/ForeverSevrous/p/8660216.html
