预防胜于治理,只有从错误根源处杜绝错误产生做到消除错误,才能写出高质量的程序。这本书是在CSDN电子书栏意外看到的一本书,一开始引起我的注意,是因为附录的试题居然和我最近一次面试题目完全一样。书中作者没有大量的专业术语,而是采用聊天的语气,应用大量生活中的类比,读来通俗易懂,丝毫不觉乏味。
软件开发本是一门艺术,就像画画一样,但它又是一种商业活动,需要各种规范去加快进度,这使得它很多时候少了艺术的那份闲情逸致。好的画有其特点,高质量的软件开发也有它的衡量标准,这些衡量标准也叫质量属性。质量属性有功能性属性,也有非功能性属性如表1,仔细一看,发现以前混淆了健壮性和可靠性、兼容性和可移植性,这里详细记录一下它们的区别。
功能性 | 正确性 | |
健壮性 | 软件在异常情况下,能够正常运行的能力。 两层含义:(1)容错能力;(2)恢复能力 | |
可靠性 | 与健壮性不同,是指程序在一定环境、一定时间里不出现错误的概率,通常用平均无故障时间来衡量,是与时间有关的属性。 | |
非功能性 | 性能 | |
易用性 | ||
清晰性 | ||
安全性 | ||
可扩展性 | ||
兼容性 | 两个或两个以上的软件相互交换信息的能力 | |
可移植性 | 软件不经修改或稍加修改就可以运行于不同软硬件环境(cpu,OS,编译器)的能力 |
矛盾是事物发展的根本动力,马克思诚不我欺也。在软件开发中,质量和成本就是一对时时刻刻存在的矛盾。要求质量,必须付出时间、人力成本;一味减少成本,质量就很难有所保证。在这一对矛盾斗得你死我活的过程中,人们意识到,若想高效开发出高质量的软件,必须有条理地组织技术开发活动和项目管理活动,于是软件过程改进方法(软件过程模型)诞生了。作者在书中介绍了他独创的一种软件过程模型——精简并行过程(Simplified parallel Process,SPP),模型要点如图1
图1 精简并行过程(SPP)模型
SPP模型将产品生命周期分为6个阶段:
(1)产品概念阶段——PH0;
(2)产品定义阶段——PH1;
(3)产品开发阶段——PH2;
(4)产品验证阶段——PH3;
(5)用户验收——PH4;
(6)产品维护——PH5;
SPP模型是将项目管理过程、技术开发过程、机构支撑过程并行开展,从PH0到PH5共经历19个过程域,其中项目管理过程包括6个过程,技术开发过程包括8个过程,机构支撑过程包括5个过程。
过程类别 | 项目管理过程 | 技术开发过程 | 机构支撑过程 |
过程域 | 立项管理 结项管理 | 需求开发 技术预研 系统设计 实现和测试 系统测试 用户验收 产品维护 | 配置管理 质量保证 采购管理 培训管理 |
当然,不同的开发过程可以按照项目特点省略以上一些过程。我发现我目前接手的一个项目就是采用SPP模型开发的,但只有这些过程域,或者确切地说,只针对这些过程域建立了相关文档:立项企划、需求开发、程序设计、项目管理、项目验收、组织过程资产。
为了高质量的开发,为了把日常的时间用在“刀刃”上,开发人员应该注意以下原则:
(1)尽可能的利用现成的东西,不重复造车轮子;
(2)分而治之,对软件模块化设计,降低模块耦合性;
(3)优化工作不是可有可无的事情,而是必须的事情,优化过程必须坚守一个原则:在保证其他质量属性不变的前提下,使得一些重要属性变得更好,避免拆东墙补西墙;
(4)开发人员也要掌握测试方法,测试只能证明软件存在缺陷,不能证明软件不存在缺陷;
(5)改错时应该首先明确错误的根源,最忌“急躁蛮干”,世界上最好的调试工具是那些有经验的人,很多时候你绞尽脑汁,想不破,而路遇高手,可能“一语道破”。
错误的根源不是很好找的,主要有以下原因:
在修改错误时,我们还有三思: