第四章、两人合作
1、原文：
在变量面前加上有意义的前缀，程序员就能一眼看出变量的类型及相应的语义。这就是“匈牙利命名法”的用处。还有一些地方不适合用“匈牙利命名法”，比如，在一些强类型的语言（如C#）中，对类型有严格的要求，不同类型的值是不能做运算的，例如C#中，if（）语句只能接受bool值的表达式，这样很大程度上就杜绝了上面的问题。在这类语言中， 前缀就不是很必要，匈牙利命名法并不适用。微软的.NET框架就不主张用这样的命名法则。
问题与思考：
既然匈牙利命名法在一定程度上并不适用，那么它出现的意义是什么？
“匈牙利命名法”是由匈牙利程序员Charles Simonyi发明的一种编程语言中对变量进行命名的规范。基本原则是：变量名=属性+类型+对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。要基于容易记忆容易理解的原则，保证名字的连贯性是非常重要的。例如：nFoo，szFoo，pFoo，cpFoo分别表示整型变量，字符串型变量，指针型变量和常指针型变量。
可以看出，匈牙利命名法将变量的类型信息从单一地点(声明变量处)复制到了多个地点(使用变量处)，这是冗余法。冗余法的成本之一是要维护副本的一致性，这个成本在编写和维护代码的过程中需要改变变量的类型时付出。冗余法的成本之二是占用了额外的空间，一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位的长度以30个自然行以下为宜，如果超过50行就应该重新组织，一个变量的书写空间会给这一法则添加不必要的难度。
但是使用匈牙利命名法的好处是看代码的人知道这里发生了一个整型变量的复制动作，听起来没什么问题，可以安心了。匈牙利命名法有其优点但也有缺点，这就需要在使用中扬长避短，合理应用它。
2、原文：
结对编程不是成与开发者独到的发明，在现实生活中，也存在着类似的搭档关系：越野赛车（驾驶，领航员）；驾驶飞机（驾驶，副驾驶），这些任务都有共同点：在高速度中完成任务，任务有较高的技术要求，任务失败的代价很高。
问题与思考：
为什么说结对编程“任务失败的代价很高”？
我们都能明白越野赛车和驾驶飞机时任务失败很可能导致两个合作者的性命安全得到威胁，但是结对编程任务失败的代价以及后果到底是什么呢？在结对编程中的角色分别是：驾驶员（控制键盘输入）；领航员（起到领航、提醒的作用）。与之前提到的搭档关系不同的是，在结对编程中这两个角色是可以互换的。在结对过程中，任何一段代码都至少被两双眼睛看过，被两个脑袋思考过，代码被不断地复审，这样使得代码的责任不属于某一个人，而是两个人共同的责任。
因此，结对编程十分忌讳个人英雄主义，它需要的是建立集体拥有代码的意识。所以，如果两人由于配合不当导致代码无法融合，没人负责，就会使编程进度大大下降。并且结对编程的过程也是一个相互督促的过程，这样使得程序员除了技术之外，对心智的要求也比较高。因此，结对成员若是做不到绝对的信任与高强度的配合，就会使结队任务无法进行，并从中还能够看出程序员的“不足”。
第十七章、人，绩效和职业道德
1、原文：
有时候一个企业也会展现出“假团队”的特性：领导非常努力地让员工相信公司非常关心员工；员工也非常努力地让领导相信自己完全领会了公司的大爱。私下里双方都不相信对方说的话，也看不起对方。
问题与思考：
如何使自己的团队不变成“假团队”？如果自己在的团队是一个假团队是该力挽狂澜，还是拂袖而走？
“假团队”是指名义上有团队的组织，但是成员相互掣肘，面和心不和，有人打酱油，这样的团队的效率还不如各人单干的工作组。那么， 如何使自己的团队不变成“假团队”？就应该在这个团队组成的萌芽阶段做好预防措施，在刚刚开始组队时就应该分配好各自的职责，制定好相应的规章制度，从根源上杜绝一切“混子”行为。在团队的磨合阶段，大家应该做到坦诚相对，积极沟通与交流。不要因工作理念或者习惯的不同而产生不满甚至隔阂，这样就不会有成员因为对内冲突而抵触工作。
但是万事都有一个万一，如果自己在的团队变成了一个假团队那么应该怎么做？是该力挽狂澜，还是拂袖而走？首先，我们要清楚自己在这个团队的位置，以及自己对待这个团队的情感是什么。如果你是一个刚刚加入的新成员，那么我认为自己的去留对这个团队影响不大，那么我选择离开。但是如果我是这个团队的老成员，我为了这个团队付出了很多，那么我可能会思考问题的所在，为我们的团队的未来做一个整治以及改变。
2、原文：
有些人把团队成员分为A、B、C这样的等级，并且认为A类员工最优秀，B类员工一般，而且B类员工会把更差的C类员工招入团队，急剧降低团队质量，因此要尽量只保留A类员工。
问题与思考：
为什么B类员工愿意招入C类员工来降低团队质量呢？将员工分类对绩效管理有何作用？
在我看来人类总是愿意与比自己“低”的人作比较，从而来增强自己的自信心。B类员工会把更差的C类员工招入团队，也许是由于自己的能力实在是超不过A类员工，因此想选择C员工作为自己的最低标准。所以，如果一个团队若尽量保留A类员工，就会激发B类员工的自尊心与求胜欲，从而使得团队的工作效率得到大幅度的提升。
一个团队中的每个人都有各自的努力和作用，如何衡量个人在团队中的绩效呢？有的人说根据工作量来算，但是代码虽多，还是要看结合起来在团队中的作用。有人建议按照角色来定位，有人建议根据工作时间来衡量……但是这些都是很片面的，在评定员工绩效时，还是应该从多维的角度思考。因此，虽说员工进行了分类，但并不代表A类员工的绩效就要比B、C类的好，我们还要看每个等级的员工在该等级的贡献与能力的提升。