《构建之法》 读书笔记（6）

      软件设计与实现

分析和设计方法，以文字为主的文档，如Word、PowerPoint文档。用图形为主构造的模型，如MindMap，ERD，DFD，UML的各种图，甚至包括Flow Chart流程图用数学语言的描述，如ViennaDevelopment Metho用类自然语言+代码构造的描述，源代码加注释也能描述

图形建模和分析方法，表达实体和实体之间的关系，表达数据的流动，表达控制流，统一的表达方式，

从Spec到实现，估计开发任务所需的时间，参考以前同类任务所需花费的实际时间，以及其他的时间估计。试着写一些快速原型的代码，看看效果会怎样。期间发现了若干问题，与PM沟通后，最终达成一致意见。在看到初始效果和了解了实现的细节后，开始写设计文档，写好之后，可以请他人一起来复审设计文档。设计文档写好后，就会按照设计文档写代码。在实现过程中，如果发现了一些意想不到的问题，与PM沟通后写好代码后，对照设计文档和代码指南进行自我复审，重构代码。创建或更新单元测试。进行单元测试得到一个可以测试的版本，交给相关的测试人员进行测试，或者在网上进行某种公开测试等。修复测试人员或用户发现的问题，等到问题都解决得差不多了，请他人进行代码复审。根据代码复审的意见修改代码，完善单元测试和其他相关文档，然后把代码嵌入到代码库中。

开发阶段的日常管理，闭门造车、每日构建、构建大师、宽严皆误、小强地狱。

      用户体验

用户体验的要素

用户的第一印象，1.谁会是我们的目标用户？他们是什么样的人？他们的使用方式是什么样的？用户是从哪里进入到这个软件或网站？他们知道这个产品是做什么的吗？用户想达到什么目的？怎样让他们尽快找到相应的功能入口，完成任务？我们的软件可能比较难用，怎样才能让用户尽快掌握基本功能？
2.用户和软件的第一次使用，很大程度上决定了用户对软件的评价。怎样让用户在第一次使用的时候，少花时间在对用户没有价值的部分而把大部分时间花在有实际价值的功能上？

从用户的角度考虑问题，软件服务始终都要记住用户的选择，不让用户犯简单的错误，对于用户的体验和质量我们要进行妥协

用户体验设计的步骤包括，概要设计、行为（交互）设计、界面设计

       软件测试

介绍了一些基本名词解释及分类。测试设计有两类方法：黑箱和白箱。测试的目的分类可以分为功能测试和非功能测试。

各种测试方法
1 单元测试
2 代码覆盖率测试
3 构建验证测试
顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。
4 验收测试
在MSF敏捷建模中，我们建议还是采用场景来规划测试工作。
5 “探索式”的测试
就是指为了某一个特定目的而进行的测试，且就这一次，以后一般也不会重复测试。在软件工程的实践中，“Ad hoc”大多是指随机进行的、探索性的测试。
6 回归测试
回归测试不仅仅包括单元测试，也包括其他类型的测试。
7 场景/集成/系统测试
在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，各方面均能满足用户的要求。这类测试叫系统/集成测试。
8 伙伴测试
伙伴测试是指开发人员可以找一个测试人员作为伙伴，在签入新代码之前，开发人员做一个包含新模块的私人构建（Private Build），测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。
9 效能测试
1. 设计负载
2. 令用户满意的服务质量
10 压力测试
压力测试要验证的问题是：软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。
11 内部/外部公开测试
12 易用性测试
13 “小强”大扫荡

 

个人感受

以前认为软件编写好以后就大功告成了，就可以发布了。也不需要做别的工作了。

但在书中我知道，首先软件编写以前一些必要的贮准备工作，设计和开发文档，我们需要一些自然语言加代码的方式简单的介绍一下程序编写的思路，预测程序编写所需要的时间等等。软件编写成功以后还要必要的用户体验，因为用户和软件的第一次使用，很大程度上决定了用户对软件的评价。

怎样让用户在第一次使用的时候，少花时间在对用户没有价值的部分而把大部分时间花在有实际价值的功能上？

这就告诉我们今后编写的软件一定要，从用户的角度考虑问题，软件服务始终都要记住用户的选择，不让用户犯简单的错误，对于用户的体验和质量我们要进行妥协。。还需要设计一些必要的文档