标签:
“构建”既是名词,也是动词,但在现实生活中,最好不要把它当作形容词,比方说“您真‘构建’的”。(Sorry,忍不住又在扯了 –_-#)
我对本章内容的概括是:在软件开发过程中,构建活动是一个程序员最最应该关注的活动。至于W-H-Y,Why,作者用了一章的篇幅来阐述这个问题。
在本章的开头(Page3的1.1什么是软件构建),可以得知研究者把软件开发过程中的各种不同的活动(acitivity)归纳为以下11种:
- 定义问题(problem definition)
- 需求分析(requirements planning)
- 规划构建(construction planning)
- 软件构架(software architecture ,或高层设计(high-level design)
- 详细设计(detailed design)
- 编码与调试(coding and debugging)
- 单元测试(unit testing)
- 集成测试(integration testing)
- 集成(integration)
- 系统测试(system testing)
- 保障维护(corrective maintenance)
在本书的Page5,作者用下面这张“本书的立体视图”来表示构建活动与上面11种活动的关系:
图中的灰色椭圆表示构建活动,由此可见:
(Page5)构建活动主要关注与编码与调试,同时也包含了详细设计、单元测试,集成测试以及其他一些活动。
我们目前还无需急于理清构建活动都包括了哪些具体任务,因为书中写得很清楚:
想要获得一份构建活动的完整列表,请看一遍目录中各章节的标题吧。
在可以选择做不做的前提下,或者说在决定要不要接受作者的观点之前,弄清楚“为什么要构建”往往比“怎么去构建”更为重要。因此本章核心的内容主要集中在“(Page6)1.2软件构建为何如此重要”。作者列举了5大原因,摘抄如下:
- 构建活动是软件开发的主要组成部分;
- 构建活动是软件开发中的核心活动;
- 把主要精力集中于构建活动,可以大大提高程序员的生产率;
- 构建活动的产物——源代码——往往是对软件的唯一精确描述;
- 构建活动是唯一一项确保会完成的工作。
针对第1点和第5点,作者使用了列数字和举例子的方式,说明了为什么构建活动比软件开发中的其它活动更重要。
第2点是无可否认的事实,当然,我们(程序员)并不需要强迫项目组的其他成员(比如产品经理和测试工程师)去接受这样的观点,强调构建活动的核心地位并非是要否定其它活动的重要性。
第3点里面提到的“不同程序员的生产率(productivity)的差异可达到10到20倍”,对于一个程序员来说,应该是一件“让我欢喜让我忧”的事情:
第4点,很容易让人联想到开发文档的问题,有人也许会说,既然大师都说了“代码是对软件的唯一精确描述”,那说明文档其实并没有那么重要。关于文档,我是有话要说的。我想读这篇文章的绝大多数人,在国内念初中上思想政治课的时候,应该都学过一些商品经济方面的东西,了解“劳动者”和“商品”的概念吧。如果“劳动者”对应于程序员,那么“商品”对应于什么呢?也许这个问题不太好回答,实际上我也不关心它的答案,我只是想通过这样的类比来说明一个观点,那就是:文档是否重要取决于你(程序员)在最终交付的时候,把不把“文档”当作“商品”看待。
以上就是我对于文档重要性的一些看法,不过话说回来,虽然我未曾因为缺少文档而沮丧,但却经常因为缺少文档而要付出额外的代价,这些经历包括:
正因为在以上这些地方吃过亏,所以在我眼中,所有程序员所撰写的文档都是有价值的,都是重要的,它们的区别只是在于哪些文档更加重要。这就正如所有女性在我心目中都是美丽的,善良的,她们的区别只是在于能体现她们美丽善良地方不尽相同……(这种敏感的两性言论还是适可而止吧)
“(Page8)1.3如何阅读本书”主要是作者对本书阅读方式的一些建议,我当然是选择“从头到尾”的阅读方式啦。
本章要点:
- 软件构建是软件开发的核心活动; 构建活动是每个项目中唯一一项必不可少的工作。
- 软件构建的主要活动包括:详细设计,编码,调试,集成,开发者测试(developer testing)(包括单元测试和集成测试)。
- 构建也常被称作“编码”和“编程”。
- 构建活动的质量对软件的质量有着实质性的影响。
- 最后,你对“如何进行构建”的理解程度,决定了你这名程序员的优秀程度——这就是本书其余部分的主题了。
标签:
原文地址:http://www.cnblogs.com/duxiuxing/p/5266745.html