您当前的位置:首页 > 计算机 > 编程开发 > 编程箴言

谈谈编程(2) 软件开发中的方法论

时间:08-28来源:作者:点击数:

1 项目管理的方法论

1.1 方法论

方法论的英文为Methodology,编程的方法论应该是指软件开发的一整套方法、过程、规则、实践、技术。不过我们一般提到的方法论都偏重于项目、过程和人员的管理。

《Agile Software Development》的作者Alistair Cockburn提出方法论具有以下要素:角色、个性、技能、团队、技术、活动、过程、产品、里程碑、标准、质量、工具、团队价值,它们的关系可以用一幅图来表示:

虽然将这幅图贴在这里,事实上我不了解这些要素及其关系的确切定义,对于这些不能精确描述的东西,我接受起来比较困难。

其实,项目管理的核心是沟通和反馈。只要能够保证良好的沟通和即时的反馈,开发团队即使并没有采用先进的方法论,一样可以成功。从另一个角度说,过程和工件能辅助,但不能保证开发人员、项目经理和客户的良好交流。

1.2 重型方法

有的方法论规定了大量的中间文档和复杂的过程管理。那些中间文档被称为artifact,或工件。需要大量artifact和软件开发方法被称作重型(Heavy Weight)方法。

这些复杂的方法来源于恐惧。

在中大型的项目中,项目经理往往远离代码,他们无法有效的了解目前的工程的进度、质量、成本等因素。为了克服未知的恐惧感,项目经理制定了大量的中间管理方法,希望能够控制整个项目,最典型的莫过于要求开发人员频繁地递交各种报告。重型方法中的基本假设是过程(及各种artifact)比个人可靠。

虽然很多轻型方法都将重型方法作为反面例子,但对于大多数大型项目,重型方法是管理所必需的。

1.3 轻型方法

为了解决重型方法存在的问题,业界出现了很多轻型(Light Weight)方法论。提出这些方法论的部分作者结成了一个联盟:敏捷软件开发。他们还有一个宣言:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

在这些宣言后面还有很多原则。概括起来主要是:尊重个人,强调沟通和反馈,与客户紧密合作,保持设计的简单性等等。敏捷方法在重型方法论和无管理状态之间寻求一个平衡点,希望用低成本的管理活动带来最大的产出。

2 编程的方法论

作为程序员,我更感兴趣的是可以指导编程的方法论。

2.1 测试驱动开发

2.1.1 未谋进,先谋退

开始一件事情之前,必须先明确什么时候可以停止。什么“止于至善”,在编程工作中可以一脚踢开。我们必须明确要做什么,做到什么样子就算完成了。

怎样才算明确呢?最理想的方法是先写一个测试程序,然后再编写代码,让测试通过。测试程序规定了停止的必要条件。

测试程序是针对接口编写的。要写出测试程序,必须先定义好接口,然后针对接口编程。测试程序同时示范了接口的使用。

如果有一个运行很方便的测试程序,我们在维护代码时,就放心得多。可以经常跑一跑,测试一下,以保证测试要求的功能还没有被破坏。相反,如果没有测试程序,我在修改代码的bug时,心里就很不踏实,因为我不清楚我的修改是否会引入新的bug。

2.1.2 保持可运行,可调试的状态

“先写测试程序”适合没有UI,功能相对简单的模块。对于功能复杂的软件系统,需要测试的方面很多,测试时间很长,在开发前就建立一个比较全面的测试,并且随时使用,有时是不可能的。

但我们至少应该保证:写任何程序,都要尽量保持在可运行、可调试的状态。即使要为此写一些额外的程序,都是值得的。在不能运行的情况下,编写大量代码是不可思议的事情。

2.1.3 可测试性

IC设计上有一个“Design For Test”的说法,即IC的设计中必须要考虑到如何测试,留好测试的接口。软件开发也是一样的,我们写每段代码,都要考虑一下这段代码是否可以测试,为了保证可测试性,必要的时候可以修改设计。

2.2 重构

《重构》这本书内容朴实、但对我个人影响很大。在了解“两顶帽子”和“小步前进”的方法后,我敢于修改任何代码,甚至是我不熟悉底层逻辑的代码。

2.2.1 两顶帽子

我们有两顶帽子:一顶是不改变功能的前提下,改善现有现有程序的设计;另一顶是增加新的功能,以适应需求变化。我们在任意阶段,应该只戴一顶帽子,绝对不能同时戴两顶帽子。

在增加新功能的时候,往往需要先改进现有的代码结构,使之能更好地适应变化。如果功能有较大变动,我们应该将这变动分解成尽可能小的步骤,并让改进代码和新增功能的小步骤交替进行。将原有代码平滑地演变到新代码,既增加了功能,又改善原有代码的设计。

重构的正式定义应该是“在代码写好之后改进它的设计”。但对我而言,重构的思想已经融入了我的开发过程。在开发中,我同样按照“两顶帽子”和“小步前进”的方针平滑地演变代码,从无到有,逐步完善。

2.2.2 代码的坏味道

重构的对象是消除“代码的坏味道”,保持新鲜、健康的代码。《重构》中列举了一些典型的坏味道,例如重复代码、太长的函数、太长的参数列等等。

2.2.3 设计和重构

存在这么一种说法:“设计不再是一切动作的前提,而是在整个开发过程中逐渐浮现出来”的。

事实上,在没有任何软件工程理论的时代,编程基本上是写到哪儿算哪儿。历史是螺旋上升的,在投影上很接近的两个点在铅垂线方向上是处于不同高度的。

重构是要纠正过度设计的倾向,告诉程序员:即使开始的设计有缺陷,也没关系,更不要僵化地保持,我们可以重构代码,平滑地修改原有设计。这并不是说前期设计不重要。

“设计是在整个开发过程中逐渐浮现出来”,这是在说随着开发的深入,我们会对很多问题考虑地更加清楚。在必要的时候,我们应该用重构的方法灵活地改变设计,适应变化。

推荐内容
相关内容
栏目更新
栏目热门