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

时间 2019-12-20

标签故事快速看完构建之法繁體版

原文原文链接

完成这个任务最有趣的过程莫过于读了三本《构建之法》，最开始看到须要阅读《构建之法》的相关章节的时候巧了我购买的书尚未发货，因而我借了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:

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

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

如下纯属我的看法和疑问：

Que 1:

Que 2:

Que 3:

Que 4:

Que 5：

Que 6:

Que 7:

Que 8:

Que 9：

Que 10: