Lean Software Development, Part 3: Build Quality In

1. 一致性

作者定义了两种类型的一致性:感官一致性(Perceived Integrity)和概念一致性 (Conceptual Integrity),或者说外在一致性和内在一致性。

感官一致性就是用户对于系统的体验:它是如何宣传的,如何发布,如何安装,使用起来是否直观,是否能方便的解决问题等等。笼统的说,就是让用户觉得满意甚至开心的一切特性。有时候使用一个系统的时候,你会觉得设计这个系统的人好像知道你脑子在想什么似的,提供了方便的功能可以迅速完成你想要做的事。从某种程度上说,感官一致性具有一定的主观性。比如对我来说,Google的一些工具,浏览器Opera等都是具有感官一致性的。

概念一致性则是指产品内部的各种概念和设计所具有的一致性。对软件来说,那就是指各个模块之间是否很好的配合,整体的架构是否很好的平衡了灵活、可维护性、性能等各个要素。其实不止软件开发,任何一种伟大的产品设计,甚至是伟大的艺术品,都是具有概念一致性的。其实在人月神话中,Brooks就已经提出概念一致性了,书中介绍了外科手术式的软件开发队伍,并且提倡系统的概念一致性必须由一个人或者少数几个有默契的人来实现。就像好的产品都有一个主设计师,经典的艺术品一般都只有一个作者一样,在软件开发中,我们叫这个人为架构师(Architect)或者主程序员(Master Programmer)。

概念一致性是感官一致性的必要但不充分条件。也就是说感官一致性是以概念一致性为基础的,但只有概念一致性未必就能取得感官一致性。

取得一致性的关键就是顺畅的信息流,从用户(或者用户代表、市场等)到开发团队的信息流的顺畅保证了感官一致性,开发团队内部信息流的顺畅保证了概念一致性。要注意信息流必须是双向的,这样才能保证信息的完整和准确。

《Lean Software Development》的作者提出了一些方法保证一致性,摘录如下:

如何取得感官一致性:

  • Smaller systems should be developed by a single team that has immediate access to the people who will judge the system's integrity. The team should use short iterations and show each iteration to a broad range of people who will know integrity when they see it, so they can make course corrections based on feedback.

  • Customer tests provide excellent customer–developer communication.

  • Complex system should be represented using a language and a set of models that the customers understand and the programmers can use without intervening refinement.

  • Large systems should have a master developer who has deep customer understanding and excellent technical credentials, and whose role is to facilitate the design as it emerges, representing the customer's interests to the developers.

如何取得概念一致性:

  • First, use existing parts when possible.
  • Second, use integrated problem solving.
    • Understanding the problem and solving the problem happen at the same time, not sequentially.
    • Preliminary information is released early; information flow is not delayed until complete information is available.
    • Information is transmitted frequently in small batches, not all at once in a large batch.
    • Information flows in two directions, not just one.
    • The preferred media for transmitting information is face-to-face communication as opposed to documents and email.
  • Third, be sure there are experienced developers involved in all critical areas.

软件的架构对于一致性有很大影响,有效的使用MDA、SOA等方法可以提高系统的一致性。不过这是另外一个很大的话题了。

PS. 在《Agile Software Development》有关于一致性的两个章节,但到了后来的《Implementing Lean Software Development》中,作者没有专门讲到一致性。但我还是认为一致性是一个很重要的概念,一个有质量的系统首先必然是具有一致性的。

2. 提高代码质量的实践

1) 反馈

 前面提到取得一致性的关键是顺畅的信息流,而顺畅的信息流的关键就是反馈,只有不断的反馈才能不断的增进理解,改进系统。在瀑布模型中,因为开发的各个环节是分裂的,这一点很难得到保证;即使有反馈,也很难是有效并且快速的。敏捷开发的很多实践就是为了保证这一点。敏捷开发强调开发团队和用户的交流,甚至要求有用户代表在开发现场,从而保证从需求到软件开发之间信息流的顺畅。Lean中有一个原则是快速交付,使的用户可以尽早的得到可供使用的系统,从而提出改进系统的反馈。几乎所有敏捷方法都要求使用迭代式的开发模型,在迭代和迭代之间以及每个迭代中间,所有的信息都是双向的。甚至关于整个开发流程的信息也是双向的,在每次迭代都应该对于流程进行反思,开发人员提供反馈,从而不断改进流程。(哈弗商业评论上看到一个方法:假设到现在为之这个项目已经失败了,大家头脑风暴一下,把失败的原因都列出来……)

2) 标准

标准可以保证一致性,并且减少不必要的浪费。比如代码规范、命名规范、配置管理规范、安全规范等等都是很有用的,应该在必要的时候使用。注意的是,标准仅停留在纸上是毫无用处的,并且标准也不应该是一成不变的。标准应该是当前做某件事情的最好的方法,如果有人找到了更好的方法,那就应该使它成为新的标准。

3) 代码评审


代码评审应该是所有公司都应该有的实践,其重要性不必多说。但是在以前,我们代码评审经常用来寻找不符合代码规范的地方,后来有人帮我们评审代码,他们发现的都是程序缺陷,于是我们觉得这样才是真正的评审。但事实上,这些都不应该是评审的重点,这些应该由代码检查工具或者自动化测试去保证,评审重点关注的应该是工具无法发现的问题。比如,程序的简单性、变更容忍度(change tolerance)、安全性等等。

另外,结对编程(pair programming)可以代替代码评审。

4) 重构

 好的整体架构对软件是至关重要的,但好的设计往往不是一开始就出现的。因为随着开发的进行,需求在变化,系统的规模也在变化,系统的内部结构也应该是不断改进的。但如果每次有新的需求,就直接添加或者修改代码,时间长了,系统结构比如变得臃肿并且混乱不堪,从而使得对系统结构的变更越来越困难。因此需要对系统进行重构来保证系统架构的健康。重构就是在保证系统外部行为不变的前提下,改进系统内部的结构,保证系统结构简单、清晰、易懂以及没有重复。重构不是浪费时间,现在在重构上花时间,可以在以后节约更多的时间。关于重构有很多专门的书籍可以参考。

5) 测试

测试有很多作用:

  • 测试相当于规格说明书,告诉大家系统如何运作。(测试用例)
  • 测试提供反馈:系统是否按照它应该的方式在运作?(测试结果)
  • 测试提供了一个框架,使的开发变得容易。(接受测试、单元测试等)
  • 测试使的对系统的变更更容易更安全。(自动测试集)

6) 持续集成

越早的进行集成,可以越早的发现错误,这和单元测试的道理是一样的。具体可以参考Martin Flower这篇很有名的文章Continuous Integration 。 

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页