前言
这个星期我仔细阅读了《构建之法》的第四章与第十七章，感触颇深，学习了很多，在此提出自己的问题和部分看法。
第四章 两人合作
P74 注释
注释（包括所有源代码）应该只有ASCII字符，不要用中文或其他特殊字符，否则会极大地影响程序的可移植性。
我觉得是否使用中文应该视情况而定。
像我们，英语毕竟不是母语，有很多词并没有掌握甚至使用。在团队合作中，成员间的英语水平也不同。注释，是为了方便程序员了解部分程序的功能便于测试修改的，他十分的重要，一旦有歧义，便会造成问题。难道编程时要为了一句注释应该如何表达去搜索之后再继续编程？如果因为注释为英语而看不懂，反而增大结对时编写代码的难度，浪费了去翻译单词的时间。
再者，程序如果是编写给国人使用的，使用过程全为英文会加大国人阅读的难度，许多不曾学过英语的人更无法使用，如计算器中如果希望使用者输入题数，源代码应有输出语句：
1 System.out.println(“请输入题数：”);
若所有源代码为ASCII字符，则无法使用中文，语句则为：
1 System.out.println(“Please enter the number of questions：”);
但不懂英语的人可能就无法了解这句话的意思，也许以为是出现了什么故障（在我没学英语甚至初学英语时，看到别人的电脑里出现一大串的英文都觉得是电脑坏了）。所以，给国人使用的程序，各种提示，我觉得应该使用中文，若要推广，则有译文版。
使用中文最大的问题是编码乱码，我觉得从一开始便设置为UTF-8编码，并在编程过程中注意编码不弄错，一般不会出现什么问题，也更方便于了解修改。
P75 goto
函数最好由单一的出口，为了达到这一目的，可以使用goto。
这一观点与我初学C语言时老师的教导不同，老师说，最好不要使用goto，或者说不要用，普遍的做法是用if-then-else这种结构来代替goto。goto语句为无条件转移语句，在Dijkstra的《go to statement considered harmful》提到它的弊端：
The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful. In such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus one!
In Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.[1]
概括主要为降低代码的可读性。在结构化程序语言中使用goto语句， 容易造成程序流程的混乱，使理解和调试程序都产生困难。另外，因为java语言讲究简单、方便，在java语言中，goto这个词只是作为了保留字，还没有使用。
P77 析构函数
书中提到了析构函数，但我对析构函数并不熟悉，在室友晓真的博客[2]中看到了她的搜索结果，让我较为清晰的理解了析构函数，我将在文章尾附上她的博客地址。
P85 为什么要结对编程
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
在结对编程中，因为有随时的复审和交流，程序分方面的质量取决于一堆程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。
我对于两个人公用一台电脑表示不理解，在我的理解中，结对合作是两人先分析需求，将所有需求分析完毕，在讨论如何实现，把具体的实现方法择优做好计划，之后两人分工选择自己更有能力的方面分开编程，最后合在一起复审、测试。我觉得每个人都有擅长的地方，而不是很擅长的也有灵机一动的可能，既然结对，我们应该相信对方能做好各自的部分，并且经过一开始的讨论，方法基本确定，代码的初始质量并不会因为分开打而受到消极的影响，反而能因每人选择自己擅长的方面而提高质量与效率。
再联系前面P79代码复审表4-1 代码复审形式中的自我复审：
不一定最有效，因为开发者对自己总是过于自信。
那么两人同时对一台电脑编程，就有可能因为觉得是在自己眼皮底下打好的自己的代码而过于自信，两人都过于大意，反而忽略了很多缺陷，以后修改、测试的时间真的会少很多吗？分开编程则有自我复审与同伴复审的两次复审，并且思想的碰撞能够更好的优化程序，做出的程序难道不会更成功吗？
第十七章 人，绩效和职业道德
P400 猪、鸡和鹦鹉的故事
影评家不拍电影，也没有演技，但是他们对电影的一切都可以指手画脚，而且不必承担任何责任，最高领导往往还挺容易受影评家的影响！
虽然影评家不拍电影，也没有演技，但是影评家真的不重要吗？或者说他的存在没有意义甚至是属于挑刺的呢？
电影评论的目的在于分析、鉴定和评价蕴含在银幕中的审美价值、认识价值、社会意义、镜头语言等方面，达到拍摄影片的目的，解释影片中所表达的主题，既能通过分析影片的成败得失，帮助导演开阔视野，提高创作水平，以促进电影艺术的繁荣和发展；又能通过分析和评价，影响观众对影片的理解和鉴赏，提高观众的欣赏水平，从而间接促进电影艺术的发展。
影评是一种科学的活动，是电影艺术与观众的桥梁，是实现电影三重价值（艺术的、社会的、经济的）的重要手段。国外影评主要作用于票房价值，中国影评侧重于社会性，形成中国特有的、最广泛的群众影评浪潮，形成中国文艺评论独特景观。[3]
可见，影评是有存在的必要的，好的影评能够带动电影往更好的方向发展。最高领导实时关注影评，做出正确的判断，才能进步。左恒、索亚斌、梁文道、贾磊磊等，都是较为有名的影评者，专门研究电影学，评论各类影片，对电影的分析与品论独到而深刻。如果最高领导不关心，固执己见，一直随心所欲拍自己的影片，作品能够一只获得成功吗？
P401 猪、鸡和鹦鹉的故事中提到
R:Responsible，负责把具体事情做好。
每个环节有且只有一个R。
看到这里时，我有些不理解，很多任务一个人并无法完成，为什么R只能有一个呢？接着我查阅了RACI的资料，在一篇博客中了解到：
每一个流程最好有且只有一个“R”角色，这是RACI的一般原则。 当一个流程找不到“R”角色时，则出现缺口。 当一个流程有多个“R”角色时，则出现交叠。
- 解决缺口问题：如果某个流程找不到“R”角色，这时对流程负全责的权威人士则应该在现有角色中（或者发现新人选）挑选、任命一人担任“R”。更新RACI表，对各个角色及其相关责任进行阐述。
- 解决交叠问题：如果不止一个“R”存在，那么就要对该流程进行再分解，然而再对“R”进行分配。[4]
从这里，我了解到，它是把所有的任务细分到只需一个人去完成，各担一职，各司其所，使任务完整的被无缝完成。
P408 用动物来比喻体系
如果业绩很好，但价值观不太对路（不太听话？），则是一条野狗。要坚决清除，不然功高震主。
一开始我觉得绩效好的人应该能挽留便挽留，作为领导不应该担心下属功高震主，能为公司做贡献才是重要的，价值观不同可以在不伤大雅的情况下求同存异。而后，我在《给马云一个团队，他会怎么管？》中了解到：
杰出企业必须为社会创造价值，同时也要有良好的业绩支持。不仅要讲理想，同时也要有很好的收入，否则都是空话。也就是说，业绩和价值观要平衡，不能极左不能极右，必须共同前进。
马云对于员工的考核，主要有两个标准，一个是业绩，一个是价值观。他用野狗和小白兔这两个十分生动的形象，对员工在两大标准的表现上给予了评判。对于野狗，他给予的定义是：一个人的业绩很好，但没有价值观。而马云对于野狗的态度，是坚决地踢出去。那么小白兔呢，则是业绩不怎么好，但拥有非常好的价值观。对于小白兔，也得毫不留情地坚决杀掉。因为作为一个拥有百年企业的阿里巴巴，它的员工必须是业绩、价值观都好的人。
对于“野狗”和“小白兔”，为什么要杀掉呢？马云通过十分形象地举出实例，给予了解释：在阿里巴巴公司的平时考核中，业绩很好，价值观特别差，即每年销售可以卖得特别高，但根本不讲究团队精神，不讲究质量服务，这种人我们称之为“野狗”，我们的态度非常坚决：杀！毫不手软的杀掉他。因为这类人对团队造成的伤害是极大的。而对那些价值观很好，人特别热情、特别善良、特别友好，但业绩却总是好不起来，我们称之为“小白兔”的这类人，我们也要杀。我们毕竟是公司，而非救济中心，不能给企业创造效益，当然也不能在企业。不过，对于“小白兔”，却可以向领导申请一次“免死金牌”，由主管领导决定是否留用。而“野狗”就没有这个机会。无论他的职位有多高，能力有多强，一旦违背了团队的原则，马云就会毫不手软地将其扫地出门。“卫哲离职事件”，就是一个鲜明的例子。
每个成员必须首先对团队整体保持忠诚。[5]
通过这，我了解到，是我过于天真，一个企业，每一个员工的价值观都会影响到公司，一旦价值观出现问题，其带来的后果往往是难以挽回的，并不是简单的业绩能够衡量的。
参考：
[1]《go to statement considered harmful》,http://ce.sharif.edu/courses/90-91/1/ce364-1/resources/root/GoTo/Dijkstra.pdf
[2]《构建之法》第四章 第十七章阅读笔记,http://www.cnblogs.com/ForeverSevrous/p/8660216.html
[3] 百度百科，https://baike.baidu.com/item/电影评论/1202687?fr=aladdin&fromid=10364061&fromtitle=%E5%BD%B1%E8%AF%84
[4] RACI 职责分配矩阵 模型使用详解及案例分析，https://blog.csdn.net/buding_pmp/article/details/54881486
[5]《给马云一个团队，他会怎么管？》，https://read.douban.com/ebook/34756995/?from=book