技术开发 频道

为什么我们应该像盖房子那样写程序?

        【IT168 评论】在砌上一块砖或钉下一支钉子之前,建筑设计师会制定好详细的计划。程序员或者软件工程师却不会。这难道就是房子很少塌倒而程序经常会崩溃的原因?

  蓝图保证建筑设计师的设计的建筑按规划建成。“建成”不仅仅意味不会塌倒,还意味达到业主要求的功能。建筑设计师和他们的客户在着手建造之前,通过蓝图来沟通,以理解他们将要建造成的建筑的样子。

  但是很少有程序员在编码之前,会勾画哪怕是简单的草图来说明他们的程序将是会怎么样子。

  大多数程序员认为做任何不产生代码的事情都是浪费时间。思考并不会产生代码,没有想好就开始编码,那只会产生出糟糕代码。我们应该理解这些代码到底要实现哪些功能。理解需要思考,而思考很难。借用一句漫画家迪克·圭尼登的话:

  写作是一种让你知道你想法有多伤感的本能方法

  蓝图让我们想清楚我们打算要建造的建筑。在写下一段代码之前,我们应该先写蓝图。软件的蓝图称为技术说明书。

  已经有太多的借口说撰写技术说明书只是浪费时间。比如:技术说明书毫无用处,我们不能通过它来产生代码。这就好像说建筑设计师应该不要画蓝图,因为他们最终还是需要承包商去建造房子。另外一个反对撰写技术说明书的争论也能够用蓝图的例子来反驳。

  还有一些程序员争辩说,把蓝图和技术说明书作比较是无用功,毕竟程序不是建筑物。他们认为推倒一堵墙要比改变代码难多了,所以程序的蓝图不是必须的。

  错!改变代码也很难,特别是如果我们不想让程序有缺陷的话。

  我最近需要修改一些不是我写的代码,从而给程序增加一个小小的功能。要完成它需要理解一个接口。我花一整天用调试器来研究该接口到底是干什么的——这种事读读技术说明书只要5分钟就能搞定。为了避免导入缺陷,我不得不弄清楚我每次修改之后的结果。因为没有技术说明书,这个事情变得更加困难。我必须要阅读上千行代码,我花了数天来琢磨怎样才能修改尽可能少的代码。最后,我花了一周,新增、修改了180行代码。这可仅仅是这个程序的一个很小的变更啊。

  修改代码只是一项大任务中小小的一块工作,大多数代码已经是我十几年之前写的了。尽管我几乎不记得这些代码是干嘛的,要修改它还是挺容易的——通过阅读我写的技术说明书,很容易就能找到我要修改的地方。尽管这些修改工作量不少,而且还影响到其它代码,我还是能很快搞定它。

  我所说的技术说明书到底是什么?通常它被认为是以正式的技术语言写就的东西。但是撰写正式的技术说明只需要偶尔为之,如果我们仅仅是盖个工具棚的话,就不需要画摩天大楼所要求的那种蓝图。对于大多数软件来说,我们不需要正式的技术说明书。然而就算是写小程序也不能不写技术说明,否则就像没做任何计划就要盖工具棚一样。

0
相关文章