我读《构建之法》四、十七章

       这几天我都在读《构建之法》第四章和第十七章，看的比较缓慢也比较认真。根据精读的要求和个人看书的习惯，我总共读了三遍，第一遍是大致浏览了一遍内容，第二遍是静下心来圈画、标注疑惑内容，第三遍是重新浏览了一遍并解决了一些疑惑。这次作业是让大家精读教材后提出问题，具体请看以下内容。

---

 

第四章

 问题一：第一小节是讲“代码规范”，在“4.2.4断行与空白的{ }行”这一部分，最后作者选择的格式是“每个'{'和'}'都独占一行，即格式D”。其实我个人对这个做法是不认同的。

       我觉得“格式C”好，既有“{”和“}”来判断程序结构，又很清晰。“格式D”相较于“格式C”而言，“{”和“}”各自独占了一行而且“if”和“else”单独也成一行，在我看来这样占行数太多，浪费行数且不说并且会增加程序运行的时间，这也是其他开源网站代码为何代码行数尽量少的原因之一。我认为“格式C”已经很完美了，没有必要再写成“格式D”。

问题二：书中P66页提到了“匈牙利命名法”，也举了两个例子，但是没有具体说明概念，所以究竟什么是“匈牙利命名法”呢？

       为此，我特地百度了一下，百度百科的定义是：匈牙利命名法是一种编程时的命名规范。基本原则是：变量名=属性+类型+对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。

问题三：在“4.2.9注释”这一部分，作者说“不要注释程序是怎么工作的（how）”。其实我个人对这个做法是不认同的。

      我认为还是要解释how，不管是对于代码“小白”还是“大佬”来说，其实一定程度上还是有这个必要的。因为对于“小白”来说，写代码本身是有困难的，更多的还是借鉴他人，所以如果不解释how，有可能自己也理解不了；而对于“大佬”来说，也许写的时候很熟练，可等一段时间后可能自己也会记不清了。所以我觉得还是需要解释how的，但是太过于简易的代码可以不需要。

问题四：在“4.3.2 goto”这一部分，书中说“函数最好有单一的出口，为了达到这一目的，可以使用goto。”，可是我记得很清楚C语言老师说少用goto，为什么书中强调用goto呢？

      为此，我上网找了一下，网上风评不一，我截图如下：

        其实，看了之后，也不是特别理解。

第十七章

问题一：书中P402页提到“划分等级和公开刺激的做法”不是有效的，书中只说了三种内部驱动因素，那么我想问的是什么是有效的呢？另外，书中评判了“体力劳动（奖金越多，结果越好）”而“创造性思维活动（奖金越多，效果相反）”，这一点我是不赞同的。

        对于什么是有效的做法，我没什么资历，自然也回答不上来。对于“体力劳动（奖金越多，结果越好）”而“创造性思维活动（奖金越多，效果相反）”这一点，我想说的话很多，我觉得软件工程师做的是创造性思维活动需要内部驱动因素来讨论效绩没有错，可是关于金钱报酬这一块我不是很认同作者的说法。我觉得软件工程师需要一定的奖金作为报酬，同时为了个人利益或者个人动力以及公司效益或者公司发展，一定程度上增加奖金数我认为起到的是促进作用而不是消极的。

问题二：书中P408练习与讨论“2.在团队中会不会出现'劣币驱逐良币'或者'不敢犯错误'的现象”中举的例子是“NBA球星科比投篮次数不中次数是世界第一......问应不应该惩罚？”，可能大家各有所思所想，但我认为是不必惩罚的。

        我换了一下这个问题的问法，应该大概意思是“在一个项目中，一个很厉害的人犯了很多基本知识点的错误，要不要接受团队的惩罚？”。其实在我看来，是没必要惩罚的。首先，这个人是技术大牛，缺他不可。其次，倘若少了这样的厉害人物，团队如何出彩？再就是是人都会犯错，怎么能够因为一些小失误就严加惩戒呢？最后我觉得只要不是什么大bug出了什么大事件，不管团队中是大佬还是一般成员犯了错，我们都应该予以谅解，不要过于严苛。