构建之法阅读笔记01
很多程序员都知道“程序=数据结构+算法”这句名言，而一个推论是：软件=程序+软件工程。和软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关内容，是软件工程的核心部分。所以，程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。
软件开发分为四个阶段：1.玩具阶段 2.业余爱好阶段 3.探索阶段 4.成熟的产业阶段。就算是很微小的事情，只要跟用户的安全联系起来，就要谨小慎微，必须要做且必须要告诉用户。
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。
软件工程的目标是创造足够好的软件，即包括用户满意度、可靠性、软件流程的质量、可维护性的评估。一、研发出符合用户需求的软件 二、通过一定的软件流程，在预计的时间内发布“足够好”的软件 三、能证明所开发的软件是可以维护和继续发展的。能做到这三点，就是初步学会了软件工程。
为了让自己负责的模块质量过关，做单元测试是个很好的解决方案。验证单元测试好坏的标准如下：1.单元测试应该在最基本的功能或参数上验证程序的正确性 2.单元测试必须由最熟悉代码的人来写 3.单元测试过后，机器状态保持不变4.单元测试要快 5.单元测试应该可以产生可重复的、一致的结果 6.单元测试的运行、通过、失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性 7.单元测试应该覆盖所有代码路径 8.单元测试应该集成到自动测试的框架上 9.单元测试必须和产品代码一起保存和维护。
个人感受部分：
读了单元测试部分，有如下感悟：
过去写代码，都是先写完一整个程序，需要的东西先都放上去，总之灵感出来就要发挥，总认为写代码的优先级高于修复bug这样看貌似没什么大问题，但是如果这个程序很长，或者前面的bug一直影响到后面，产生一系列bug，最后修复起来特别繁琐，还要照顾前后代码，看了构建之法单元测试这一章后，我了解到了单元测试的重要性，正确的方法应该写一小块便可以回头测试一下，有bug尽量早点消除，以免夜长梦多！
