《构建之法》11~13章读后感

第十一章，软件设计与实现：

典型的开发流程；开发阶段的一些管理方法：每日构建，小强地狱，构建大师。

从Spec到实现，拿到文档后要做的基本流程，就像是做某道题的过程一样。

从功能需求到提交签入大部分步骤都有Bug，如果Bug可修复还要再从详细设计这一步往下走，最后的自动测试和功能全面测试发现Bug了还得从开始一步步做，开发人员的标准工作流程步骤多，较繁琐重复，

但按这个来做出来的软件确实完美。开发阶段的日常管理中闭门造车算是基础，给员工时间，让其“沉浸”在自己领域的世界里，安心开发；每日构建，每天或至少每周完成构建，来提升团队积极性；构建大师，

看名字以为是构建强者，原来是导致构建失败的成员，授予“构建大师”称号；小强地狱，让Bug过多的小强“入狱”，解决到一定程度后再出狱。

 

第十二章，用户体验：

 考虑用户体验的各种角度，认知阻力，用户体验的衡量标准

短期刺激和长期影响对用户算是直观上的体验，短时间不断让客户感到新鲜感，长时间也可以让客户不厌倦。某银行反假币电子邮件的超长电子邮件的例子，一方面算是考验投诉人的耐心，另一方面算是做的较

差，没有从用户的角度出发。

在用户使用一段时间后可以让用户填写相应的问卷，询问其中做的不太使人满意的地方和做的较为出色的方面，从用户本身给出评价标准。

 

第十三章，软件测试：

各种测试方法

所谓的黑箱/白象，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

无论哪种方法，都是找出软件中的错误地方，这一般是开发人员自己的工作，以前对测试投入较少，基本是代码写完之后。随着科技的发展，现在的软件更多功能，更加复杂，更加大型，不仅要测试错误的地

方，还要保证质量好，安全性高等。将整个过程结构化，程序结构化，测试结构化，可以一步步进行检测，先单元式测试，再集中起来测试，再系统测试，最后对测试做评估，对软件的各方面可以以打分等的方

式给出，再进行二次检测，直到大家都满意。这个过程需要各个部门一起做，多讨论，多沟通，达到都满意的效果。