《构建之法》 –读书笔记



《构建之法》 –读书笔记

lishq

为什么读这本书:

这是一本非常接地气的讲《软件工程》的书，第一次了解到这本书是从豆瓣上看到，看了下密密麻麻的正面评论，觉得内容应该不错。翻阅了几个章节，发现干货确实挺多。为方便大家了解，摘抄作者简介以及部分书评如下。

------------------------------------------------------------------------------------------

作者简介：

邹欣现任微软Windows中国工程团队首席研发总监。

1996年～2003年，邹欣在微软Outlook团队从事开发工作，2003年～2005年，他在微软内部质量工具团队和Visual Studio团队负责软件项目管理工具的开发。2005年～2012年，他担任微软亚洲研究院技术创新组研发主管，负责研究成果的产品化和创新项目。2012年～2014年，他担任微软亚洲互联网工程院首席研发总监，负责必应搜索客户端、必应输入法、必应词典等产品。加入微软前，邹欣从事过商用Unix系统、GPS/GIS软件开发及测试工作。

他在2007年出版了《移山之道》，于2008年出版了《编程之美》 （合作）。

他于1991年获北京大学计算机软件专业学士学位。1996年获美国韦恩州立大学（Wayne State University）计算机软件专业硕士学位

内容简介：

软件工程牵涉的范围很广, 同时也是一般院校的同学反映比较空洞乏味的课程。但是软件工程的技术对于投身IT 产业的学生来说是非常重要的。作者邹欣有长达20年的一线软件开发经验，他利用业余时间在数所高校进行了长达6年的软件工程教学实践，总结出了在16周的时间内让 同学们通过 “做中学 (Learning By Doing)” 掌握实用的软件工程技术的教学计划，并得到高校师生的积极反馈。在此基础上，作者对软件工程的各个知识点和技能要求进行了系统性整理，形成教材。

本书共分17章，对照美国ACM/IEEE2013年新出版的计算机科学教学指导（Computer ScienceCurricula 2013）中的软件工程相关部分，这本教材覆盖了其中大多数Core-Tier1和Core-Tier2的内容。可以说，全书对软件工程内容的覆盖不逊于任何一本现行的教材，同时讲述了业界最新实践方法。

书评就不摘抄了，大家可以仔细阅读判断，避免有做广告的嫌疑。

------------------------------------------------------------------------------------------

 

读书笔记：

本周阅读第一章《概论》和第二章《个人技术和流程》；

第一章《概论》旨在说明软件工程的概念。

几个概念：

软件 = 程序 + 软件工程

软件工程可以定义为: 把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程；软件工程包括一下领域：源代码管理+需求分析+程序设计+软件构建+软件测试+软件维护+生命周期管理等，广泛意义的软件工程，还包括用户体验、用户界面设计(UID)等； 软件工程决定了软件质量。

文中还提到软件工程和计算机科学的关系，这也是容易让人迷糊的两个概念，很多同学在高考填志愿的时候不知道他们的区别，到学校后发现学的东西差异也不是很大；而实质上这是两个侧重点差异很大的概念；从知识领域上说，计算机科学包含计算机体系结构、操作系统、图形学、人工智能等，而软件工程包含软件需求、软件设计、软件维护、软件测试等；

 

软件工程的目标：创造足够好的软件。那么什么是足够好，不仅仅是没有bug；评价软件的维度包括：用户满意度、可靠性、软件流程的质量、可维护性等。关于软件流程的质量，指的是软件团队和开发流程的问题太多，导致团队成员无法良好协作，按时交付，也可以说是软件团队的bug;  流程的质量往往是我们的研发过程中最容易忽视的地方，反思目前我们的现状，很对研发团队的研发流程实质是处于真空状态，开发人员甚至不知道怎样才是软件开啊的正确姿势。下半年结合团队运作中SM、BA、QA的角色职责梳理，特别关注下团队的研发流程质量。

总之，从三点去理解软件工程：

 1 研发出符合用户需求的软件

 2 通过一定的软件流程，在预计的时间内发布“足够好”的软件

 3 通过数据和其他方式展现所开发的软件是可以维护的继续发展的

 

第二章《个人技术和流程》，本章的实质是在说明，一个合格的软件工程师是怎样的，他应该具备哪些技能。

总结下来，一个合格的工程师在开发时需要同时考虑质量和效率，与之同时需要具备的技能包括：单元测试、效能分析、个人研发流程（PSP）；

关于单元测试的正确做法：

1 单元测试应该在最低的功能/参数上验证程序的正确性

2 单元测试必须由最熟悉代码的人(作者)来写

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

4 单元测试要快(一个测试用例的运行时间是几秒钟)

5 独立性—测试的运行/通过/失败不依赖于别的测试

6 覆盖所有代码路径

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

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

 

关于性能分析。

性能分析往往是开发人员容易忽视的步骤，这也是为什么我们一年一年的不停做性能优化的原因，大部分人对嵌入式的实时性和性能要求没有概念。 Visual Studio实际上提供了性能分析工具(Tools\PerformanceTools\Performance Wizard),其中有两种分析方法:Sampling和Instrumentation,即抽样和代码注入，抽样的原理比较简单，kprofile也类似，就是用比较短的周期去采用PC指针，看看是在哪个函数在执行，并把当前周期的时长累计为该函数的执行时长；  代码注入，相当于打点，是将检测的代码加入到每个函数中。

一般进行性能分析的做法是，先用抽样的方法找到函数热点，然后对特定的模块用代码注入进行详细分析。

这个方法，后面在我们的性能优化工作中可以多尝试下，让业务和支撑领域相关人员看看效果。

 

关于个人开发流程。

我们熟知CMM和CMMI，软件行业的国际通用标准，这两种能力成熟度模型，他们是用来衡量一个团队能力的模型，由卡内基梅隆大学(CMU)制定推出。其实CMU的专家针对软件工程师也有一套模型，叫Personal Software Process（PSP），即个人开发流程的标准；

为简单说明PSP以及它的意义，截两张图，看完你就明白了；

这张图，说明的是标准的PSP步骤；其中值得关注的一点是，代码复审是在测试之前进行的。

 

作者做了一个很有意思的统计，对两组人的PSP过程耗时进行了对比分析。一组是中科大大四的学生，一组是工作三年的软件工程师；见下图：

上图可以明显看到，工作三年后的工程师在“需求分析”和“测试”两个方面明显的要花更多的时间（60%以上），而在具体编码上，工程师比学生花更少的时间。

假设再统计一组6年工程师的数据，我相信又不太一样，但是趋势应该一样，即对质量的要求更高，成熟的工程师在需求分析、设计、测试上会花更多的心思。而普通的开发人员，把更多的精力放到了写代码上。

 

总结：个人开发流程要着眼的是整个软件开发的流程，输出高质量的产品，需要从个人开发流程上去找bug，然后不断修正，工程师才会成长，产品质量才会不断提高。

 

-----待续------