速读《构建之法（第三版）》总结
花了两天的时间，终于是把这本《构建之法》粗略的阅读完毕，我在阅读的过程对于感兴趣的部分进行了仔细阅读，其中也碰到了一些问题。但我认为领悟这本书所传达的思想及思维方式是非常重要的，在此提出自己阅读时所收获的一些问题，不对的地方还望大家及时指正。
问题一
在软件的开发过程中，即便我们有了很强的编程能力后，为什么我们还要必须具备软件工程的工程思维？
从以下几个主要方面进行简单分析
软件开发的变化
- 追溯到计算机刚起步的时候，软件设计只是为了个特定的应用而在指定的计算机上设计和编制，当时的语言使用还是机器代码或汇编语言，软件的规模也比较小，很少使用系统化的开发方法，软件设计几乎就是在个人编程。随着现在计算机整个行业的发展，软件的增多，高级语言的出现等，软件的规模越来越大，复杂程度也越来越高，软件的可靠性问题突显出来。在这个软件开发越发成熟的今天，从软件的立项到最后软件的发出，中间的开发过程慢慢的形成了各式各样固定的体系，当软件开发还处于幼年时期时，产品大多遵循[分析→设计→实现（制造）→销售→维护]，弊端是具有单向、不可逆性。后来，Winston Royce提出了具有相邻回溯的“瀑布模型”以及改进后的最终版本，如下图所示，后续又出现了很多“瀑布模型”的变形版，在此不再详细介绍。
图1.1 相邻回溯
图1.2 最终版
- 软件开发的模型有很多种，不同的软件可能适合不同的开发模型。
团队的重要性
- 随着现在用户的服务需求的上升，在确保软件可靠性的前提下为了提高用户的体验感，开发商也在不断的对软件进行全方面的创新，因此现在的软件大多都是非常复杂的，因此想要完成一个软件的开发，一个人的力量是不够的。在开发的过程中，整个软件开发任务将会被分为很多小模块，每个人都承担着这些模块的不同任务，他们以软件的开发需求为目标，在开发中经过反复的磨合最终完成开发任务。因此每个人的位置都是十分重要的，他们也都必须具备软件工程师的基本素质，团结合作。
必须学会需求分析
- 在我们开发软件的过程中，我们首先要确定的就是我们开发此软件的目的-为了解决用户在社会和生活中的问题，这就是需求分析。
- 首先，软件团队需要找到软件的利益相关者，了解和挖缺他们对软件的需求，另外，很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。
- 找到需求后，从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求。
- 然后，软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
- 最后，在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提高。原来认为重要的事情可能不再重要，有些功能原来技术上很难实现，现在出现了捷径，一些相关的法规会发生变化，外部的合作伙伴突然发生变化，这些都要求我不断对需求进行重新审核并做出相应的调整、量化
开发并不是只开发，也是需要合理的日常管理
- 开发效率是评价一个团队强弱的重要标准，而想要将要效率提到极致，也不单是一个人能做的，一个团队的开发时间有限，团队中每个人每天的时间也非常有限。软件开发过程中，难免有同事间任务的交错，有时候一个人也可能同时进行多项任务，而有一些工作又必须在某些任务完成之后才能进行，因此，合理的去分配任务对于一个团队来说是尤为重要，如何在有限的时间达到最好的效果，尽量的减少返工，保证质量，团队中的构建大师便这样诞生了，他将会负责团队中的日常管理。下面是移山团队关于宽严表的具体开发流程。
图1.3 移山团队关于宽严表的具体开发流程
软件测试的变化
软件工程建立之前，软件测试是为了表明程序正确而测试；20世纪80年代早期，软件测试发生了升华，测试不再只是找出错误过程，开始注重软件的质量，20世纪90年代早期，测试工具盛行起来；到了2002年，Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。至今软件测试方法已经多式多样，按测试设计的方法分类可分为黑箱和白箱测试。按功能分类如下图所示，测试范围由小到大，测试者由内到外-从程序开发人员到测试人员，到一般用户测试。
图1.4 功能测试分类软件测试的分类方法还有其他一些，在此就不一一列举了。另外，现在的测试工具也的功能变得越来越强大，测试人员在测试的过程用合理使用类似于VisualStudio2005-2012这样的辅助工具可以大大提高效率。
参见：软件测试的发展历史
问题二
软件测试如果没有专门的测试人员，会造成什么样的后果？
- 问题来源于13章软件测试
- 一般来说，程序员检查自己的代码时很难发现bug，因为他在测试时会按照自己的代码流程测试，所以很难发现问题所在，如果有条件我认为一定要有专门的测试人员，但是我们经常有一些团队就缺少测试人员，一人身兼多职，这样有时候会给项目带来未知的后果。
问题三
敏捷开发是否要把开发周期尽量缩短，性能、开发规范等选择性忽略？
- 问题来自第6章 敏捷流程
- 敏捷开发原则第一条就说到尽早并持续地交付有价值的软件以满足顾客需求，有两个词语，分别是尽早和有价值，所以在实际开发过程中，我们应该怎么把握这两个要求，我的理解是保证满足顾客功能需求的前提下，尽早地完成，性能优化这些问题可以放到后期再去处理。