构建之法阅读笔记01

第一章 概论

在这一章中，作者为我们介绍了一些关于软件工程的基本知识。

①软件=程序+软件工程：正是因为对软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容的完成，才能完成把整个程序转化成为一个可用的软件的过程。

扩展的推论:软件企业=软件+商业模式

②软件开发的不同阶段：玩具阶段→业余爱好阶段→探索阶段→成熟的产业阶段

③软件所具有的特殊性：复杂性、不可见性、易变性、服从性、非连续性（由软件的本质所决定的）

软件还有其他特性：

·有许多不同的程序设计语言、软件工具和软件开发平台

·存在许多不同的软件开发流程

·软件团队中存在许多不同的角色

·软件通常既可以存储在磁带上，也可以存储在CD/DVD上

④作者邹欣总结的自己做过的项目的各自特点：

• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。

• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。

• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。

• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。

第二章 个人技术和流程

2.1 单元测试

①重要的单元测试：有效解决程序员对模块功能的误解、疏忽或不了解模块的变化之类的问题，使自己负责的模块功能定义尽量明确，模块的质量得到稳定的、量化的保证。

②好的单元测试的标准：

在最基本的功能/参数上验证程序的正确性

单元测试必须由最熟悉代码的人（程序的作者来写）

单元测试过后，机器的状态保持不变

单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）

单元测试应该产生可重复、一致的结果

独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性

单元测试应该覆盖所有代码路径

单元测试应该集成到自动测试的框架中

单元测试必须和产品代码一起保存和维护

③单元测试的基础上能够建立关于这一模块的回归测试，目的是：

（1）验证新的代码的确改正了缺陷

（2）同时验证新的代码有没有破坏模块的现有功能，有没有Regression

2.2 效能分析工具

效能分析方法：抽样和代码注入

2.3 个人开发流程

个人开发流程PSP（Personal Software Process）

特点：（1）不局限于某一种软件技术，而是着眼于软件开发的流程，这样，开发不同应用的软件工程师可以互相比较。

（2）不依赖于考试，而主要靠工程师自己收集数据，然后分析、提高。

（3）在小型、初创的团队中，很难找到高质量的项目需求，这意味着给程序员的输入质量不高。在这种情况下，程序员的输出（程序/软件）往往质量也不高，然而这并不能全部由程序员负责。

（4）PSP依赖于数据（工程师输入数据的时间代价、数据可能遗失或者不准确的风险、可能会出现一些数据不利于工程师本人的情况）

（5）PSP目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度，工程师有可能很高效地开发出一个顾客不喜欢的软件。

在过去的时候，我常常没有做单元测试的代码习惯，后来发现在代码功能逐渐增加之后，系统整体上总会出现各种错误，导致后期找错误的时候非常困难。后来在这本书中，我逐渐了解了单元测试的重要性。单元测试能有效解决程序员对模块功能的误解、疏忽或不了解模块的变化之类的问题，使自己负责的模块功能定义尽量明确，模块的质量得到稳定的、量化的保证。同时也学习了解了很多单元测试要注意要了解的地方。在后面的代码学习里逐渐增加了单元测试对自己内容的练习，极大的提高了我的工作效率