文章归档

谈软件质量保障

这真是一个非常广阔的,难以囊括清楚的话题。我所理解的软件质量保证主要包括研发流程管理,质量控制和软件维护。稍微列一下提纲:

  • 研发流程
    • 为什么选择git而不是svn
    • 如何构建企业级的基础系统
  • 质量控制
    • 对象设计:SOLID原则和GOF模式实践
    • 模块化编程:解耦、解耦、还是解耦
    • 模块的可测试性和单元测试
    • 系统量化,让trace bug变得简明
  • 软件维护
    • 文档:wiki/PPT/man pages/docs
    • 自动化部署
    • 监控系统

一、研发流程

1)为什么选择git而不是svn

对于研发流程的选择,我比较偏向于开源社区的风格,例如linux内核。而在分布式协作的工具支持方面,git比svn更易用。

  • 每个人都应该熟悉整个系统(全栈工程师?):不用了解每一个细节,但应该知道它
  • 每个人都是code reviewer
  • 严格的代码提交和合并流程:git做了这一切事情

2)如何构建企业级的基础系统

这里有一个很重要的原则就是:动静分离。所谓动,就是代码中易变的部分,静,就是不易变的部分。将不易变化的代码剖离出来,简化系统架构。ok,举个例子,假如我们要实现一个web service,代码架构通常是这样的:

  • common/
  • core/
  • service/

当然,这是我常用的做法,首先是要完备基础库,接着实现核心模块,而service负责将这些模块组织架构起来,最终编译成一个可执行文件。也许service里就一个main.cc源文件
如果能理解这种模式的好处,我们就可以推广到整个企业系统里面去。例如,这个基础系统看起来可能是这个样子的:

  • base/
    • net/
    • data struct/
    • stat/
    • file/
    • encoding/
    • hash/
    • crypto/
    • ...
  • biz/
    • product1
    • product2
    • product3
    • ...

二、质量控制

对代码进行良好的抽象和模块化编程,是错误隔离的最佳实践。在设计模式里这其实是一个对象职责的问题。

1)对象设计:SOLID原则和GOF模式实践

推荐阅读 Object Design: Roles, Responsibilities, and Collaborations 一书

2)模块化编程:解耦、解耦、还是解耦

3)模块的可测试性和单元测试

模块的可测试性是模块设计的首要目标,如果一个模块是不可测试的或者难以测试的,那么它就不具有良好的设计。因为单元测试是软件质量保证体系里非常重要的一个环节。
单元测试应该尽可能的充分,例如达到80+%以上的覆盖率。单元测试在模块完成的时候就可以编写,基础系统的构建过程类似于积木,打地基,每一步都需要扎实。试想一下,如果某天你接手某部分代码,但是却发现无从下手,为什么?因为你甚至不确信某个API被证明过是语义清晰和完备的。

4)系统量化,让trace bug变得简明

系统能够监控得到的指标应该尽可能的多,这些信息在对问题追中时会变得非常有用。

5)编程范式

推荐如下书籍:

  • Unix编程哲学
  • Effective c++
  • C++ primer

三、软件维护

1)文档:wiki/PPT/man pages/docs

2)自动化部署

简化系统的上线流程。假想一下,假如没有运维团队,你会怎么去做这个事情?ok,这就是我们的目的。

3)监控系统

无非就是将各个系统的监控指标汇总起来,形成图状,网络拓扑状等,对整体系统的运行状态了如指掌。

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>