构建之法阅读笔记03

读书感受：这本书不仅让知识点易懂，而且特别生动有趣。和其它“一本正经”的专业书籍不一样，这本书采用的是更高级的写作方式。这种写作方式让我感受到了作者的魅力。他一定是爱好广泛的，博学的，有趣的，而不是一个刻板印象的理工男。这本书通过丰富的案例和具体的场景，来分析一个个问题和概念。这样不仅使我有更大的阅读兴趣，也使我对内容的印象更深刻。正如作者倡导的“‘做’中‘学’’”一样，这本书本身就是“‘做’中‘学’”的示范。通过这本书，我掌握了软件工程的从头到尾的完整体系。

虽然这本书易懂，但是并不浅显。我每一次读都能体会到更多的东西，甚至过段时间就能从脑海里的记忆悟到新的东西。因为它不是刻板的把知识的概念直接摆在你目前，而是通过问答举例等各种生动形象的形式“传道授业”。看似一句冗余的啰嗦话，都可能蕴含着它的道理。所以这本书是值得看很多遍的。此外，它还留了很多思考和讨论以及链接。这些拓展常常被忽略，其实很有用。

以人为本，法为万法——这是我最大的启发。一切的需求痛点，测试体验，终将以人为本。用户是人，工程师是人。软件工程归根结底是从“人”出发，最后以“人” 为落脚点。正如这本书是通过几个虚构的“人”的角度阐述的——这无疑是最科学的阐述方式。这本书叫《构建之法》，法即为理，即为道。万法归一，随着学习越来越深入，我觉得这本书写的不仅仅是软件工程的构建之法了，而是可以拓展到其它任何领域，拓展到为人处世的构建之法。以人为本又何尝不是万法呢？

第十二章 用户体验

12.1 用户体验的要素

用户的第一印象

从用户的角度考虑问题

软件服务始终都要记住用户的选择（长期的使用只会使软件更好用）

短期刺激 长期影响

不让用户犯简单的错误

注重用户体验和质量

情感设计

12.3 评价标准

对于一个软件的用户界面，我们有没有什么评价标准呢？可以参考费茨法则（Fitts law）、Nielsen启发式评估十条原则以及其他经验。下面是邹欣老师在自身实践的基础上总结的一些原则：

1. 尽快提供可感触的反馈系统状态

2. 系统界面符合用户的现实惯例（Familiarity，Avoid Surprise）

与用户沟通，软件系统要使用用户语言而不是开发者语言，所用的概念要贴近生活实际，而不是用学术概念或开发者的概念。我们说的生活实际，最好是目标用户的实际生活体验。

3. 用户有控制权

操作失误可回退，要让用户可以退出软件（很多软件都没有退出菜单，这是导致用户反感的一大原因）。用户可以定制显示信息的多少，还可以定制常用的设置。

4. 一致性和标准化

在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有“帮助用户收集生词并且背诵生词”的功能。这个功能要有明确一致的称呼，不能混杂着叫“单词本”、“生词本”、“Word List”、“Word Book”、“单词文件”……等等。

5. 适合各种类型的用户

6. 帮助用户识别、诊断并修复错误

7. 有必要的提示和帮助文档

不需要文档，用户就能使用自如，当然更好，必要时还可以提供在线帮助。如果软件和用户的工作相关（而不是简单的游戏），那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤，并且不要太冗长。

第十三章 软件测试

13.1 名词解释

Bug ：软件的缺陷

Test Case ：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等

Test Suite ：测试用例集。即一组相关的测试用例

13.2 Bug解释与实例

①Bug可以分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）

症状：即从用户的角度看，软件出了什么问题

程序错误：即从代码的角度看，代码的什么错误导致了软件的问题

根本原因：错误根源，即导致代码错误的根本原因

②Bug例子

症状：用户报告，一个windows应用程序有时会有在启动时报错，继而不能运行

程序错误：有时候一个子窗口的handle有空，导致程序访问了非法内存地址，此为代码错误

根本原因：代码并没有确保创建子窗口，因此子窗口的handle变量有时会在访问时处于未赋值状态（为空），导致出现代码错误

13.3测试方法

①黑箱：指的是设计测试的过程中，把软件系统当做一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是从内部结构出发来设计测试

②白箱子：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构及知识来选择测试数据及具体的测试方法。

第十四章 质量保障

14.1 软件质量

软件 = 程序 + 软件工程

软件（质量） = 程序（质量） + 软件工程（质量）

14.2 软件质量的保障与软件的测试

软件测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的

软件质量的保障工作：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作

第十五章 稳定和发布阶段

15.1 从代码完成到发布

 

第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果。开发者必须向与会者报告的是：

• Bug是什么
• 危害是什么，如果不修复，有何后果
• 用户会有什么变通办法
• 是否经过代码复审，是否经过伙伴测试

第二步：会议决定是否同意修改方案
决定哪些缺陷必须现在就进行修复，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列处理方式。

• Must——必须修复，缺陷很严重，修复方案可行，相关的测试都通过
• More Info——需要更多的信息
• No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求
• Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态“Like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“Must”，那么处于待命状态的“Like”修复就可以一起集成到代码库中。如果没有“Must”级别的修复，那么“Like”级别的修复就只能处于“待命”状态，直到以后出现了“Must”级别的修复为止

第十六章 IT行业的创新

影响产品竞争的各种因素

• 产品行业的因素
  这是影响产品发展的最重要的因素，2012年流传着一句俗话——“站在风口上，连猪都可以飞起来”，就是说明产业发展的成长期（竞争产品少，市场空间大，用户容忍度强）能给产品提供巨大的助力。相反，如果是在一个产业的衰落期进入这个产业（例如，在2008年做小灵通手机业务，在2013年进军网络团购市场，等等），那么就会面临巨大的发展阻力。
• 公司和市场因素
  公司在目前目标用户中的品牌号召力如何？公司的现有市场能力如何？现有的市场能力能帮助打开新的领域么？从传统的产品开发角度来看，“市场”总是在产品之后才出现，而且和“产品开发”似乎没有直接的联系。但是从长期来看，产品的质量就是最有效的市场能力，产品经理往往就是市场经理。
• 团队执行因素
  根据产品特性的不同（基础软件、企业管理软件、行业通用软件、办公软件、互联网服务软件、移动应用软件等），商业模式不同，团队的战略也会不一样。在正确的时间，有正确的产品，却执行了错误的策略，或者不能做出决定，那么产品也会失败。执行力的一个有效衡量标准是一个决定需要多少次会议才能达成。一些团队对市场展现的机会往往陷入过度的分析和评价，力争要弄清所有情况再动手，最后的结果是动不了手。这是“分析麻痹”（Analysis Paralysis）。
• 产品的价值因素
  产品给用户带来什么价值，这是和“软件工程”最相关的内容。考虑新产品或产品的新功能时，团队要问：我们给用户带来了什么价值，这个产品是提供了独家的价值，还是“人有我也有”的价值？这个价值足以让本产品和目前市场上已有的产品区分开么？我们怎么能进一步放大产品差异性？让我们越来越领先，或者让用户觉得我们很领先？我们是否在非差异化功能上花费了太多时间和资源？

第十七章 人、绩效和职业道德

①RASCI模型

R：Responsible，负责把具体事情做好

A：Accountable，对任务负全责，有批准的权利

S：Support，对任务提供支持，辅助任务的完成

C：Consulted，咨询，拥有完成项目所需的信息或能力的角色

I：Informed，知会者，应该事后及时通知结果的角色

②团队合作的阶段：

（1）萌芽阶段，就像小苗破土而出，柔弱但充满希望

（2）磨合阶段，就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突

（3）规范阶段，从磨合阶段毕业，进入规范阶段的团队，成员们意识到光争吵时没有用的，大家还是要协同作战

（4）创造阶段，经历了萌芽、磨合、规范阶段，现在团队终于可以创造一些有意义的东西

③不管从事哪一个职业，不管你是属于哪个岗位上的，都必须具有职业道德，软件工程师同样也需要