《构建之法》第4章，17章读书笔记
前言
我认为《构建之法》这两章为我们两个人的结对合作和多人的团队合作提供了很好的指导作用，也让我们更加了解了软件工程师的职业道德。分析了合作中可能遇到的各个时期和各种问题，让我们更加了解了合作的形式与如何处理各种可能发生的情况。我相信认真阅读后一定会对我们之后的项目和合作有帮助，避免一些不必要的问题影响我们的效率。同时，在阅读的过程中，我也提出了一些问题和我的一些感悟，看法。具体问题如下：
第四章
1.“注释（包括所有源代码）应该只用ASCLL字符，不要用中文或其他特殊字符，否则会极大地影响程序的可移植性”
问题：
在4.1代码规范的开头，提到了这样一句话，“程序员写的代码是给人看的，还是给机器看的？人也看，机器也看，但最终是人在看。”那注释这个问题是否也应该根据编码环境和程序员的水平来考虑是否可以使用中文呢？
我的看法：
首先我是认同注释最好应该使用ASCLL编码的，因为使用中文写注释容易出现乱码的情况。的确影响了程序的可移植性，而且频繁切换中英文加注释是很影响编程的流畅性的。但是，既然注释是为了让别人更好的理解代码，是不是可以灵活的根据实际情况决定注释使用中文还是英文呐?英语的确很重要，但对于我们现在的水平，明显阅读中文能力更好，中文注释能更好的更快的帮助我理解别人的程序，而不会因为不认识单词或者英语语法问题而影响编程的效率。结合这样的实际情况，我觉得可以根据队友或者团队人员的具体情况决定注释的语言。
2. “函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto"
问题：
（1）goto语句一般不推荐使用的原因是什么？
（2）存在即合理。虽然不推荐使用，但其仍然存在就说明它在某些情况下还是有作用的。所有高级语言中都提供goto语句吗？那么在什么语言，什么情况下可以考虑使用goto语句呐？
我的看法：
（1）根据这个问题，我也去查阅了一下相关的资料，首先得出了goto语句不建议使用的原因有：
a 在程序比较简单时用goto语句是比较灵活，但是当程序比较复杂时很容易造成程序流程的混乱。
b 利用goto语句对以后的后别人看程序是很难理解。
c 调试程序的过程也会变得很困难。
（2）刚看到“函数最好有单一的出口”，不太理解这一目的和使用goto语句的关系。根据下面的讲解我也更加深入的理解了goto语句的使用情况。“如今很多高级编程语言中，似乎是难以看见goto的身影：Java中不提供goto语句，虽然仍然保留goto为关键字，但不支持它的使用；C#中依然支持goto语句，但是一般不建议使用。其实可以很容易发现一点，这些不提倡使用goto语句的语言，大多是有自带的垃圾回收机制，也就是说不需要过多关心资源的释放的问题，因而在程序流程中没有“为资源释放设置统一出口”的需求。然而对于C++语言来说，程序员需要自己管理资源的分配和释放。倘若没有goto语句，那么我们在某个函数资源分配后的每个出错点需要释放资源并返回结果。虽然我们依然可以不使用goto语句完整地写完流程，但是代码将变得又臭又长。”（博文地址链接https://www.cnblogs.com/heartchord/p/4795337.html）阅读后产生的疑问是：原文中“函数最好有单一的出口”是指这里提到的“为资源释放设置统一出口”这个需求吗？
3. “结对编程中有两个角色，驾驶员和领航员。这两个角色是可以互换的。和现实生活中的例子类似，一个人负责具体的执行，另一人负责导航，检查，掩护等。”
问题：
阅读到这里，不太理解两个人结对编程的状态。是两个人必须针对整个项目中的同一功能一起解决，一个人负责这部分编程，另一个人负责统筹，检查吗？
我的看法：
之前我理解的结对编程是，开始时，两个人一起讨论，先统筹规划好整个项目的进度和解决各个问题的思路，然后就可以分模块分功能，一人负责一部分。这样的编程方式效率很高，完成项目的时间也会缩短。每人负责好自己那部分代码的运行调试和复审，最后合并起来就是实现完整功能的代码。可是看了书本上说，“结对编程避免了我的代码还是他的代码的问题，使得代码的责任不属于某个人，而是属于两个人。”才发现我的理解是有偏差的。但是我觉得我的理解方式也有一定的高效性，这样的结对编程方式是可取的吗？
第十七章
1.如何区别对待这个问题下：“尽管两个团队的贡献和管理水平有很大的差别，这两个团队的经理都得选出10%的成员作为最差的成员。”
问题：
对于好的团队，既然这是一个很艰难的决定。可以只分为两部分，突出的前20%和剩余的80%吗？
我的看法：
我认为对于一个好的团队，不是必须要把表现同样不错的成员归到10%中。这个划分和评价应该更灵活些。如果成员表现的都不错，我觉得可以只采用表扬奖励优等的20%的方法。在这种情况下如果非要选出差的10%，可能会影响团队的团结度，影响团队队员间的关系。同时会打击那10%成员的积极性。我认为一个真正优秀的团队，每个人对自己的定位和待遇都会呈现一个满意的状态，都是为了项目竭尽全力的付出的。所以在很多情况下，是没有必要非要选出10%不好的，进行“明显的不同待遇”的。
2.信任模块下：“敢于互相分享自己或自己团队的薄弱环节”。
我的看法：
我非常认同这句话。我认为真正的信任，不是拼尽全力掩饰自己已经察觉到的代码的缺点，以这种方式让队友肯定你的能力和实力，而应该是开诚布公的，坦诚的和队友一起探讨自己代码或思路中的不足之处，或者整个团队需要改进的地方。只有能够客观理性的分析团队面临的问题，整个团队才能进步和提高，而不是在自己的世界中自欺欺人。
以上就是阅读完后，我个人的一些感悟和想法，希望能和大家一起讨论交流，共同进步。我觉得在之后的结对编程与团队编程中，如果遇到自己觉得难以解决的问题，可以再一次阅读这两章，我相信它会告诉我们答案。
