软件构建(一)——软件构建基础

开发计算机软件是一个非常复杂的过程,而软件“构建”是指建设过程中“动手”的部分,其中不仅仅包括“写代码”,还包含了计划、设计、测试、集成等等其他工作。本文首先总结软件构建的含义以及其主要活动;接着列举了一个比较合理的隐喻——建造房子——来理解软件开发;最后阐述了软件构建的前期准备工作的重要性,阐述了定义问题和分析需求的重要性,以及应该准备哪些事情。

1. 软件构建的主要活动

软件构建的主要活动(阴影覆盖的部分)

如图所示,软件构建活动主要是编码与调试,但也涉及详细设计、规划构建、单元测试、集成、集成测试等其他活动。下面列出一些具体的构建活动中的任务:

  • 验证有关的基础工作已经完成,因此构建活动可以顺利地进行下去
  • 确定如何测试所写的代码
  • 设计并编写类和子程序
  • 创建并命名变量和具名常量
  • 选择控制结构,组织语句块
  • 对代码进行单元测试和集成测试,并排除其中的错误
  • 评审开发团队其他成员的底层设计和代码,并让他们评审你的工作
  • 润饰代码,仔细进行代码的格式化和注释
  • 将单独开发的多个软件组件集成为一体
  • 调整代码,让它更快、更省资源

2. 用隐喻来更充分地理解软件开发

当向一个非程序员解释什么是软件开发的时候,最好的办法就是通过某种隐喻或类比来解释。隐喻把软件开发过程与其他你熟系的活动联系在一起,帮助你更好地理解。不同的隐喻彼此并不排斥,应当使用对你最有益处的某种隐喻组合。

使用建造房子是一个很好的隐喻,此处做个引用摘录:

首先你要决定准备建一个什么类型的房子一一在软件开发里的类似事项称为问题定义。接下来,你必须和某个建筑师探讨这一总体设计,并得到批准。这跟软件架构设计十分相似。然后你画出详细的蓝图,雇一个承包人,就像软件的详细设计。再然后,你要准备好建造地点,打好地基,搭建房屋框架,砌好边墙,盖好房顶,通好水、电、煤气等。这就如同是软件的构建一样。在房子大部分完成之后,庭院设计师、油漆匠和装修工还要来把你新盖的家以及里面的家什美化一番。这就好比软件的优化过程。在整个过程中,还会有各种监查人员来检查工地、地基、框架、布线以及其他需要检查的地方。这相当于软件复查评审。

建造一个房子的时候,你不会去试着建造那些能买得到的现成的东西。你会买洗衣机、烘干机、洗碗机、电冰箱以及冷藏柜……当开发软件时,你会大量使用高级语言所提供的功能,而不会自己去编写操作系统层次的代码。你可能还要用些现成的程序库,比如说一些容器类、科学计算函数、用户界面组件、数据库访问组件,等等。

3. 前期准备

3.1 前期准备的重要性

就像修建建筑物一样,项目的成败很大程度上在构建活动开始之前就已经注定了。建造住宅小区的施工人员,在开始建造第一栋房子之前,并不需要知道小区里面每一栋房子的每一个细节。但他会调查施工场所,制定下水道和电线的走向等。如果施工人员准备不充分,那么建造过程很可能会因为“需要在某所已经造好的房子的地下挖一条下水道”而延误。

准备工作的中心目标就是降低风险:一个好的项目规划者能够尽可能早地将主要的风险清除掉,以便项目的大部分工作能够尽可能平稳地进行。有时候用户在一开始并不完全确定自己想要的是什么,因此值得花费比理想情况下更多的力气,找出他们真正想要的东西。但这至少比“先做一个错误的东西出来,然后扔掉,并从头来过”的成本要低廉。

3.2 准备工作和构建活动的平衡

真实项目大致可以分为“商业系统”(Web站点、游戏、信息管理系统等),“使命攸关的系统”(软件工具、盒装软件、Web服务等)和“使命攸关的嵌入式系统”(航空软件、医疗设备、操作系统等)三大类。不同种类的软件项目,需要在“准备工作”和“构建活动”之间做出不同的平衡。你应该首先确定哪些前期准备活动适合你的项目。有些项目在前期准备土面花的时间太少了,结果使得在构建活动中遇到大量不必要的反复修改,同时阻碍了项目的稳步前进。有些项目则预先做了太多的事情,固执地坚持原有的需求和计划,后来事实证明这些需求和计划是无效的,这同样阻止了构建活动的顺利进展。此外,项目的实际情况也决定了哪一种开发方法更加合适,下表给出了参考。

需求 设计 领域熟悉程度 项目风险 后期改动代价
序列式开发 稳定 直截了当 熟悉 昂贵
迭代式开发 不稳定 复杂,有挑战性 不熟悉 较低

3.3 明确问题和需求

在开始构建之前,必须对这个系统要解决的问题做出清楚的描述。“问题定义”只定义了“问题是什么”,应该从客户的角度用客户的语言来描述问题,而不应该用计算机的专业术语叙述(除非需要解决的就是与计算机本身相关的问题)。

需求 详细描述软件系统应该做什么。明确的需求有助于确保是用户(而不是程序员〉驾驭系统的功能,有助于减少开始编程开发之后的系统变更情况,有助于避免争论。但是在构建期间,需求通常会有25%的变化,要更好地应对需求变更,可以采用以下方式:

  • 使用需求核对表来评估你的需求的质量
  • 确保每一个人都知道需求变更的代价
  • 建立一套变更控制程序
  • 使用能适应变更的开发方法(如演进原型、演进交付)
  • 考虑项目的商业价值

3.4 花费在前期准备上的时间

一般说来,一个运作良好的项目会在需求、架构以及其他前期计划方面投入10%~20%的工作量和20%~30%的时间。如果需求不稳定,同时你从事的是一个大型正式项目,那你就很可能需要为“与需求分析师协商”预留一些时间,以解决构建活动早期指出的需求问题;如果从事的是小型非正式项目,要预留足够的时间,将需求定义足够清晰,让需求的不稳定性对构建活动的负面影响降至最低。

这就好比你是一名承包商,有人请你建一栋房子。客户问你:“完成这项工作要花多少钱?”你会合理地询间:“你想要我做什么?”客户说:“我不能告诉你,不过我想知道需要花费多少钱?”你该明智地感谢他浪费了你的时间,然后转身回家。

参考文献:电子工业出版社《代码大全(第2版)》第1-4章

当前网速较慢或者你使用的浏览器不支持博客特定功能,请尝试刷新或换用Chrome、Firefox等现代浏览器