第四章

　1、原文；“函数最好有单一的出口，为了达到这个目的，可以使用goto.只要有助于程序逻辑的清晰体现，什么方法都可以使用。——P69”

　　 问题：关于goto，我记得老师讲过，这个在编程中是尽力避免的，所以我在之前并没有了解过它。本书却建议用，这让我产生了困惑。

　　 我的看法：goto语句它可以不受限制的灵活跳转，这样程序员在使用goto语句的时候就很容易因为跳转而略过了一些关键语句。但是它能从多重循环体中跳出，用不着写很多次的break语句。我查了一些资料，发现自从提倡结构化设计以来，goto 就成了有争议的语句。我阅读了一些同学的博客，他们对goto的作用及利弊条理清晰的列了出来，在这里我就不详细的列出来了。但是在我查资料的过程中，发现所有的资料最后都写了建议慎用，少用，但没有一个回答是不要用。我又仔细地读了书中的这段话，发现是我误会了作者的意思，其实他的这句话也不是我之前所理解的提倡我们用goto.而是为了程序逻辑的清晰体现可以用。这和我们所提倡的慎用是没有矛盾的。

 

　2、原文：“在结对编程中，程序各方面的质量取决于一对程序员中各方面水平较高的一位。这样对编程有如下好处：...... 。结对编程恶意取得更高的投入产出比。——P79”

    　　“结对编程让代码不断地处于复审的过程，程序员能够不断地审核，及时发现问题，避免吧问题带到后面的阶段去。”

　　 问题：结对编程真的利大于弊吗？

　　 我的看法：在结对编程中，程序各方面的质量取决于一对程序员中各方面水平较高的一位，这个我也深以为然，但是对应的水平高的那位同时也承担了更多的编程任务，同时还可能要去教伙伴编码，在项目中付出大量的精力。所以我觉得可能在团队中产生矛盾，避免矛盾的方式大概就是在选择伙伴时找水平差不多的，最好技术和个性能互补，还要合得来。这又产生了另一个问题，这样多要求的伙伴找得到吗？我觉得是比较难得。而且要求技术水平不要差太大，那么水平高的那位对程序质量的决定性就不是那么强，那这样岂不是违背了结对的初衷？有浪费时间的嫌疑。而且结对编程不能替代代码评审。虽然结对编程对代码的审核程度比代码评审细致的多。但两个结对的人有明显的思维趋同性，从而忽略同样的问题或者犯下同样的错误。据我了解，在国内很少有人做结对项目，认为在别人的注视下工作是一种打扰，管理者怀疑结对编程会让团队效率降低等等。

第十七章

 

　1、原文：“关于代码量，作者在上课的时候给同学讲了这个故事：......代码量等于树叶量，当作如是观。——P398”

      “萝卜与白菜——P403”

 

　　 问题：代码量难道就是毫无用处的树叶吗？。

 

　　 我的看法：这个我是有疑惑的，因为我认为，代码量是程序员的基础，不管是评定效率还是代码的有机结合解决客户需求，都要有大量的代码作为基础。当然我说的是认真敲出的代码。我觉得一个高效的程序员、一个大牛。他的成长过程肯定有大量的代码做基础。可能是因为我还在学习阶段，在成长的阶段，身边厉害的同学都是比别的人敲过更多的代码。所以我认为一个程序员他敲的代码多收获和经验自然会更多、bug会更少。就像17.7萝卜与白菜所说的萝卜，我不懂为什么作者会认为他未来每天都忙忙碌碌敲很多代码，做很多工作，然后没有一点进步，还是会继续让自己的代码有那么多缺陷。我恰恰认为他会在缺陷在汲取教训，进行改正。而且他勤劳又热心，在团队中很有价值。