*第四章 两人合作
问题一：4.2.9注释
“另外，注释（包括所有源代码）应该只用ASCII字符，不要用中文或其他特殊字符，否则会极大地影响程序的可移植性。”
我的问题是：
自己写的注释自己可以理解，但如果别人要维护你的代码，怎么才能确保别人也一定能看懂呢？我现在注释总是要用中文，很不习惯用ASCII字符；但是我还是不太懂，自己注释的自己感觉大家都能看懂，但有人或许就是看不懂怎么办？还有就是我感觉中文注释便于理解，如果非要用ASCII码的话，是不是更加不便于理解呢？
问题二：goto
“函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。”
我的问题是：
因为以前的C语言老师告诉过我们一般情况下不可以用goto语句，说那样子很容易造成程序混乱，然后在这本书里头老师写道只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto，我不是很理解。
于是，我上网百度了一下，林锐在<<高质量c/c++编程>>里面是这样说的:
“首先，由于goto 语句可以灵活跳转，如果不加限制，它的确会破坏结构化设计风格。其次，goto 语句经常带来错误或隐患。它可能跳过了某些对象的构造、变量的初始化、重要的计算等语句，例如：goto state;
String s1, s2; // 被goto 跳过
int sum = 0; // 被goto 跳过
?
state:
?
如果编译器不能发觉此类错误，每用一次goto 语句都可能留下隐患。很多人建议废除C++/C 的goto 语句，以绝后患。但实事求是地说，错误是程序员自己造成的，不是goto 的过错。goto 语句至少有一处可显神通，它能从多重循环体中咻地一下子跳到外面，用不着写很多次的break 语句。就象楼房着火了，来不及从楼梯一级一级往下走，可从窗口跳出火坑。”
我懂得了邹欣老师的意思是：并不是主张多用goto，而是该用的时候用好goto语句。
摘抄很喜欢的一段话：
结对编程是个渐进的过程，有效率的结对编程不是一天就能做到的。结对编程是一个相互学习、相互磨合的渐进过程。开发人员需要时间来适应这种新的开发模式。一开始，结对编程很可能不比单独开发效率更高，但是在度过了学习阶段后，结对编程小组的开发质量、开发时间通常比两个人单独开发有明显的改善。
我觉得老师说的很对，没有哪一次合作是一蹴而就，一下就可以达到最高效率最高境界的，只有慢慢磨合慢慢适应才可以逐渐将这种模式的优势体现出来，同时也要注意很多情况下是不需要用到结对编程的，这也很考验团队的判断力。
*第十七章 人，绩效和职业道德
“例如，在大家做任务估计的时候，那些给出非常乐观估计的成员会不会产生无形的压力，让一些实事求是的团队成员不得不调整他们原来比较靠谱的估计，最后导致整个团队的估计都是过于乐观，客观（包括比较保守和悲观）的估计都消失了？或者，在工作中太看重失误，惩罚失误，导致无人敢冒险？请看这个例子：NBA球星科比的投篮不中次数已经是历史第一，超越了大部分NBA球员的所有投篮数，这么多投篮不中，应该惩罚么？如果要严厉惩罚的话，科比，或者球队会有更好的成绩么？” 这是老师在书中向我们提出的问题，以下是我对这个问题的看法：
书中第十七章前面提到一个团队需要的是信任，并且这种信任是指：“我信任大家做事的出发点都是为了团队的共同目标，每个人的水平、经历、性格特点都不同，我不是完美的，当我犯错误，或者展现我性格中不成熟的地方的时候，我信任我的同事会帮助我，但不会指责我的动机，或其他内在属性。”我觉得一个团队能真正信任内部成员的话，应该会很愿意提出自己的意见，因为大家都是在为整个团队考虑，即使有不同的意见，大家都可以各抒己见，从而讨论出最优解，就不会存在怕说错话而不愿意提出自己中肯的意见。并且，领导团队应该创建一个和谐进取的工作氛围，允许大家犯错误，毕竟人无完人，领导者应该鼓励支持每个人表达自己的意见，这样就不会出现不敢犯错误的现象。科比虽然是不中次数最多的人，但他是NBA最好的得分手之一，生涯赢得无数奖项，突破、投篮、罚球、三分球他都驾轻就熟，几乎没有进攻盲区，单场比赛81分的个人纪录就有力地证明了这一点。除了疯狂的得分外，科比的组织能力也很出众，经常担任球队进攻的第一发起人。另外科比还是联盟中最好的防守人之一，贴身防守非常具有压迫性。由此可见，光凭一点是无法对一个人做出准确评价的，因为一点太片面了，这也告诉我们对团队成员的绩效评估应该从多方面考虑，而不只凭单方面对人下定义。
以上便是我读《构建之法》第四、十七章的看法，谢谢老师的耐心阅读~
