故事会般的快速看完《构建之法》

完成这个任务最有趣的过程莫过于读了三本《构建之法》，最开始看到需要阅读《构建之法》的相关章节的时候巧了我购买的书还没有发货，于是我借了ff的书看了一半到该还的时间了我的书还没到，但需要在两天内继续看完，于是还书之后，又借了另一位可爱的同学的书啃，然后今天我的书到了，把书还回去终于算是用自己的书结的尾看完了。实话看完这本看起来很厚的书虽然毫无记忆但是莫名我还是觉得蛮有成就。也通过这次短时间快速阅读发现自己的阅读能力很差，本应该边看书边产生疑问，然后在后续上课时带着疑问听课效率较高。但是我却是看完并没有什么印象也没有什么很明确的问题，只能重新大概的快速整理一遍问题；

以下纯属个人见解和疑问：

整本书通过风趣幽默的人物形象和故事模拟讲解了开发软件的流程事项、问题方法、团队职员等等许多知识，阅读起来很有趣像看故事，但是其中很多是经验丰富或参与项目或实际步入程序员行业的从事软件开发会遇到的问题，我个人而言，很多其中讲解的问题无法近距离更贴切的领会到深层的含义，即看到但未收到；（要是有更多我这类大学生能体会的实际例子配合，我认为我可以收获更多）

• Que 1:

单元测试到底是什么意思，有何作用？（书上C#示例配合讲解有点神秘）

• Que 2:

结对编程驾驶员和领航员不断轮换角色，具体应该如何轮换？倘若两个人敲代码速度效率有较大差异时怎么办？

• Que 3:

事后诸葛亮会议具体应该如何做到让参与者不完事后就再不再看？

• Que 4:

辅助需求的确可以是杀手功能吗？按照个人理解JetBrains的便捷性和用户体验算辅助需求吗，算杀手功能吗？

• Que 5：

倘若一个PM没有得到预期的效果，但是他确实在团队中最适合的了，该如何解决？

• Que 6:

签入、签出更具体通俗意思是什么？实例详细介绍应该是什么样过程；

• Que 7:

质量保障中测试角色之间的事先未配合好问题，在约见客户前不需要至少模拟演一遍示吗？

• Que 8:

各种测试是在开发团队中肯定是逐渐建立起来体系的，最终都需要做到如此详细完整吗？

• Que 9：

成熟阶段总会到衰退阶段，应该如何在成熟阶段平衡创新与维持核心技术之间关系？那么微软Office 算是处于成长阶段还是成熟阶段呢？（个人感觉在衰退阶段）

• Que 10:

因为确实在阅读第一遍的时候没有什么具体的问题，所以重新回顾一遍整出的几个问题算问题嘛？（个人感觉这是陈述类讲故事型，我阅读过程没有什么思考问题。）