读书笔记——《构建之法》第四、十七章
第四章
笔记：
1. 第四章的两人合作给了我很大的收获。我发现了我存在的不足，在此之前都没有考虑过的问题和无意识保留下来的坏习惯（如P77中，我也会怕以后会用到而保留之前的老代码把他们注释掉，这导致我的代码经常十分地冗杂）等等，这些在合格的软件开发中都是不能允许存在的，我以后还是要多多注意。“三明治”式的反馈方法也让我大有启发，我会在结对项目中留心这些问题的。
2. 其中的对结对编程的描述让我很感兴趣。在一开始老师让我们找结对的队友时，我以为是类似原来写web项目那样一个写前端页面一个写后台代码那样的分开合作，没想到结对编程是“一对程序员肩并肩、平等地、互补地进行开发工作”。看了书上的详细解释，也在网上找了相关的资料（http://www.infoq.com/cn/articles/talk-about-pair-programming 这个是我觉得写得还不错的一个关于结对编程的博客，分享给大家）。个人感觉结对编程虽然好，但是对于项目和参与的人员都有较高的要求，这也可能是结对编程不流行的原因
问题：
1.在书中P69页，提到goto语句：函数最好有单一的出口，为了达到这一目的，可以使用goto.只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto.
这让我很是疑惑，因为在我的认知中，goto是竭力避免甚至说千万不要用的，因为他会让程序结构难以理解。于是我去查了资料：
在60年代末和70年代初，关于GOTO语句的用法的争论比较激烈。主张从高级程序语言中去掉GOTO语句的人认为，GOTO语句是对程序结构影响最大的一种有害的语句，他们的主要理由是：GOTO语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉GOTO语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。
持反对意见的人认为，GOTO语句使用起来比较灵活，而且有些情形能提高程序的效率。若完全删去GOTO语句，有些情形反而会使程序过于复杂，增加一些不必要的计算量。
关于goto语句的解决方法：
1974年，D·E·克努斯对于GOTO语句争论作了全面公正的评述，其基本观点是：不加限制地使用GOTO语句，特别是使用往回跳的GOTO语句，会使程序结构难于理解，在这种情形，应尽量避免使用GOTO语句。但在另外一些情况下，为了提高程序的效率，同时又不至于破坏程序的良好结构，有控制地使用一些GOTO语句也是必要的。用他的话来说就是：“在有些情形，我主张删掉GOTO语句；在另外一些情形，则主张引进GOTO语句。”从此，使这场长达10年之久的争论得以平息。
后来，G·加科皮尼和C·波姆从理论上证明了：任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明，从高级程序语言中去掉GOTO语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。
goto语句的结果：
在C/C++等高级编程语言中保留了goto语句，但被建议不用或少用。在一些更新的高级编程语言，如Java不提供goto语句，它虽然指定goto作为关键字，但不支持它的使 用，使程序简洁易读；尽管如此后来的c#还是支持goto语句的，goto语句一个好处就是可以保证程序存在唯一的出口，避免了过于庞大的if嵌套。
这样看来，goto语句可以让函数有单一的出口，从庞大的if嵌套中跳出来。可是避免写过长的函数和过深的if嵌套也是代码设计规范的内容啊，为什么不从一开始就规避过甚的if嵌套而到后来用goto来“亡羊补牢”呢？我认为这是不值得提倡的。这是我的看法，欢迎各位老师同学批评指正。
2. 书P68中关于注释那里提到：注释应该只用ASCII字符，不要用中文或其他特殊字符。
疑问：以前我写的全是中文注释，但一次错误也没出现过啊？于是我去网上搜了资料，发现大家对这个问题的看法各有千秋：
我认为注释的本意是让注释的本意，就是让不清楚代码的人清楚代码。这个不清楚代码的人包括自己和他人。如果写了别人读起来很费劲的注释，那么就失去了注释的本意。所以综合来看，没有很大移植性需求的国内公司的代码可以用中文注释，只要注意UTF-8格式就可以了。假如是外企的代码，用英文就更合适。
第十七章
笔记：
本章又提到了在第四章看到的反馈机制：“我信任我的同事帮助我，但不会指责我的动机，或其他内在属性”。真的给我很大启发。让我反思自己平时言行是否做到了这一点？原来王超学姐和我们说的学这门课不仅学知识还学做人，此言不虚。
问题：
1. P394“加入一个团队时，要弄清楚自己在团队中投入的级别是什么，别人的期望值是什么。不要拿着卖白菜的钱，操那卖白粉的心”，与P385领导要带领团队弄清五个奠定团队基础的问题，第一个就是目的：我们为何存在？我们交付什么样的产品？我们将来会成为什么样子？
问题：这两点要如何平衡和取舍呢？
比如在课程中，我们会在个别通选课如马原毛概里组过队做一些任务作业。一开始组队的时候大家都很积极，把自己宣扬成“猪”或者是“鸡”，没有人承认自己是只说不做的“鹦鹉”。
但定好队后有个别人就开始推诿，想着蹭别人的结果混个及格就可以。这时假如在他人无法替代他完成作业的前提下，自己是要降低对这个团队的期望值把成绩的要求也改为80呢，还是挑起领导的担子燃起大家做作业的积极性呢（也有可能其他人觉得这个作业无关紧要你在大题小做）？在项目中也是如此，假如在人手紧缺的情况下还遇到了p383所列出的“第二象限：不爽的贡献者”的话，该怎么办呢？
2. P406中提到了软件工程师的职业道德：原则一，软件工程师的行为应与公众利益一致。原则二，软件工程师应以其客户和雇主利益最大化的方式做事，与公众利益保持一致。
问题：我们要以什么方式来保证其被遵守呢？假如靠这个公司决策者的良知的话，显然靠不住，Facebook泄露个人隐私，大数据“杀熟”时代等例子已经说明了这一点：假如能赚两份钱而且赚得还算安稳的话为什么要赚一份钱；靠程序员的道德？大多数情况下，直接发你工资和可以吵你鱿鱼的是你的老板而不是“公众”，假如老板有违背公众利益的需求且这个需求不是杀人放火那个级别的话，我想大部分程序员都会满足老板的需求（可以判断用户行为悄悄抬高价格这样的复杂算法不可能是老板自己偷偷写出来加进去的）；靠法律？各国对互联网行业的法律条文都很不完善，尤其是这种很隐蔽的每个用户都不一样的功能。靠社会舆论吗？万一永远都没人发现怎么办？
可以说一颗老鼠屎坏了一锅粥。但假如没有有效的方法来解决这种道德问题，公众对所有新兴技术和由此催生出来的软件都会很容易想起曾经的教训，犹豫且质疑着。
而这，显然不是我们想看到的一个健康的软件市场。