读构建之法-现代软件工程

  • 2019 年 10 月 8 日
  • 筆記

软件工程的定义

学生时代老师教过我们 程序=算法+数据结构, 但是程序就是一个软件了么?其实并不是,一个程序要想成为一个软件是需要经过很多的过程的,包括需求分析、设计、测试、发布等等的步骤,这些都属于软件工程的范畴,因此一个推论就是 软件= 程序+软件工程 , 一个扩展的推论是 软件企业=软件+商业模式

那软件工程具体是什么呢?软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程,这是一个比较正式的定义,用我们自己的理解来说就是开发软件过程中包含的所有活动之和就是软件工程。书上讲述软件工程包含了软件需求分析、软件设计、软件构建、软件测试和软件维护,这个范围是比较狭义的,广义的软件工程还应该包含源代码管理、构建、用户体验、用户界面等等方面。

软件的开发活动

从狭义上来将软件工程是从需求分析开始,到最后的软件维护终止,中间包含软件设计、构建、测试、发布。如果我们整体以一条线的模型来串起来,这就是我们熟悉的瀑布开发模型;如果我们每一小部分用一条线串起来,完成一小部分之后再接另一小部分,这就是迭代开发模型;在迭代开发模型的基础上,加上敏捷的项目管理方法(XP,Scrum等),我们就得到了敏捷开发(可以看到敏捷开发和迭代开发并不是一个层级的东西,放在这里可能不太合适)。

这些是我们平常比较熟悉的,不再多说。

软件质量

软件质量是我们比较关心的。软件质量高,软件的用户就会比较舒心,产品不会频繁的出问题,相反软件质量低,用户就会来投诉了。那如果实现高质量的软件呢?

要实现高质量的软件,我们就要看能在哪些方面来决定软件的质量。前面定义中写了一个等式 软件=程序+软件工程, 因此我们这里的关于质量的推论就是 软件质量=程序的质量 + 软件工程的质量,说明仅仅是程序写得好是不够的,软件开发所涉及的活动都会影响到软件的质量(跟性能很类似,上下游的组件、服务都会影响到性能)。

程序的质量可以通过短期的冲刺或特殊办法来提高,但是软件工程的质量就不是靠取巧就能办到的了,按书上所说,软件工程的质量包含以下方面:

  • 软件开发过程的可见行(Visibility)
  • 软件开发过程的风险控制(Risk Management)
  • 软件内部模块,项目中间阶段的交付质量,项目管理工具的因素
  • 软件开发成本的控制(Cost Control)
  • 内部质量指标的完成情况(Internal Benchmarks)
    • 单元测试,每日构建,自动化,文档质量等

与测试的关系

软件测试只负责软件在开发完成之后所做的测试工作,从上面来看,软件测试和软件的质量保障区别还是很大的。在此我们明确一下软件测试和软件质量保障的概念:

软件测试:运用一定的流程和工具,验证软件能实现预先设计的功能和特性,工作的流程和结果通常可量化。

软件质量保障:软件团队为了让软件达到事先定义的质量标准而进行的所有活动,包含软件测试。

很多时候线上出现了问题,开发可能会说"是测试没测出来", 这其实是不对的,软件测试只是软件工程中的一环,软件的质量是所有参与软件活动的人共同来负责的,当出现了问题,我们需要审视我们的整个软件工程流程,找出到底是哪出了问题,以后如何来预防这个问题。

团队与个人

团队有团队的开发流程,个人也有个人的开发流程。当个人处在团队中的时候,个人既要按照自己的流程来完成软件的开发,也要考虑团队的情况。

通过学习软件工程,我们知道软件质量并不是谁的事,而是所有人的事,要完成一个高质量软件,个人不仅要完成好自己负责的部分,还要考虑整个团队的工程,我们就拥有了领导力。

这让我想起了亚马逊领导力准则,不过这些领导力准则不仅让你从团队的角度出发,更要求你从企业的角度出发,这就是我们从小兵成长到leader的发展路径。

最后

《构建之法-现代软件工程》这本书对一个已经工作几年之后的人是最有帮助的,虽然它很多都讲的很浅,但是它给出了你一个索引,你可以顺着它的线去寻找更高层的领域,而且很多方面为个人打开了一扇门,让你从更高处来看待自己的工作,你也就知道了如何去做得更好。