好代码不值钱

不值钱

长久以来我一直主张:好代码是廉价的代码。

当我跟做开发的同事说出这话时,他们的第一反应是一种惊愕,然后是将近一个星期的嘲笑,把它当作一个笑话来讲。当他们走近看我的表情、知道我是认真的时,才收敛一点。

当最初的惊愕消退后,他们会用一些这样的话来反驳:“好代码不廉价,好代码是采用经过数十年计算机科学研究和积累得出的最佳实践设计模式和方法论建立起来的精心制作的程序代码。”

我只好继续解释为什么他们给出的好代码的定义有问题的原因是(这是很多开发人员都忽视了的一个原因):知晓各种设计模式,框架,技术技巧只是事情的一方面,而知道何时该、何时不该应用他们才是更重要的问题。在不知道一种技巧方式如何能对系统的开发有帮助的情况下,这种模式方法极有可能成为一种开发的阻碍,而不是一种有益的帮助。

我还要解释说,我所说的“廉价的代码”是指这些代码只需要很少的人/天数就能开发出来,并不是说是由没有经验的开发人员、在很少的工资报酬下、用6个月封闭式、只有烤白薯和豆腐汤可吃的环境中开发出来的东西。

但是 … 设计模式毕竟是个好东西 … 不是吗?

当然,但它们好在哪里?它们能提供什么好处?

  • 容易维护
  • 产品更健壮
  • 容易理解
  • 易于日后的改进提高
  • 更好的可跟踪性

你会发现所有的这些最终都落到一点上:从长期的角度看,它们能让你更快的做事情。这事情有可能是系统迁移,或是增加一个新功能,不论是什么,通过运用这些方法模式,你会在时间效率上获得实实在在的好处。

这么说,我们观点一致吗?

怎么说呢,让我给你们说个例子,我们看看实现它的几种方式。

系统

用PHP创建一个发邮件的表单,表单里有几个表单项,用邮件把这些数据发送给某个人。除此之外,表单里的内容还要存入MySQL数据库里。

现在,用什么方式实现它们最好?按照传统的说法,采用最好的实践设计模式,你可能会想到这些:

  • MVC
  • N-层设计,包括数据库抽象层
  • 对象关系映射(ORM)
  • 可能用到的框架
  • XML配置和相关模型
  • 等等.

我可以说,这简直是疯了,客户的这些需求完全可以用10几行代码、一个小时里(包括测试时间)完成,而且所有的那些方法模式所希望达到的效果(诸如可读性,可移植性,稳定性)都有了。如果使用上面列出的那些,反而真正的会达不到这个目标,使代码复杂化,难于理解和维护修改。

那现在,假设客户又来了,要求做一些改动,比如要增加一个管理员的界面。这样的话,你就胜利了,你已经实现了很多很有用处的东西;然而这是因为你在第一次开发这个系统时付出了很大的代价。我要向你声明的是,即使我现在把这些简单的代码进行重构,增加一些简单的业务层,也仍然比按你要求的那种过度技术化的初始实现方案要简单的多。

再说了,如果客户要求的只是在表单里增加一个属性,那你的N-层设计方案会让你痛苦不堪,因为你需要改动各个层,包括那些CRUD代码。

SCRUM

我发现Scrum能吸引我的最大一个原因是它能迫使你敏捷开发;它能迫使你在每个Sprint结束的时候把东西都实现、发布。它不会让你做出目前用不到的多余的东西;它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。

相反,在你需要的时候你才去重构。当然,这会有一定的风险,因为在实现某些功能上你会花去比当初已经做了一些基础工作的情况下要更长的时间。然而,产品开发就像是一个沙漠中四处漂移的沙丘,你永远不可能准确的知道一个产品在将来会做如何的改动。所有的你花在实现这些很有吸引力的各种模式上的时间很可能会成为一种完全的浪费。

复用性

有些人会指出,我所说的方式产生的代码不具有太多的复用性,不能在新开发的一些其它系统中使用。我对这个问题的回复就是,在根本不知道某些东西是否/如何/在哪将会被复用的情况下去设计一个可复用的东西,这就跟去实现一些你根本用不到的功能或你的应用里跟本用不到的功能一样愚蠢而糟糕。如果你有一个清楚的远见,知道什么地方会复用这些东西,这就不同了,因为你确实有一个内部的业务需求在指导你正确的开发方向。

我的最后的思考 …

  • 了解你的设计模式,知道它们各自的好处(我一直认为,好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式);
  • 让你的代码廉价:
    • 当模式能够给你带来好处,而且为你省时时才去使用它们;
    • 如果不是这样就不要使用它们(例如:想想你最近的一次为什么要把系统迁移到一个不同的数据库上?);
    • 当框架能够帮你提高开发速度时才使用它们;
  • 在必要的时候重构,不要做一些超前性的开发;

我想,如果你能按照这些指导原则做事,你会发现开发周期变短、实现的代码更简洁,易于调试,易于维护修改。

[英文原文:Good code is cheap code ]

分享这篇文章:

22 Responses to 好代码不值钱

  1. zoujia says:

    某种程度可以这么说,这或许就是“敏捷开发”的一种实践感受吧\(^o^)/~

  2. haitao says:

    软件工程师其实就是自掘坟墓。。。。理解这一句,应该也就能理解本文了。
    还有扁鹊3兄弟的名气和水平成反比。。。。。。。。

  3. yangsheng says:

    文章写得很好,很有收获,但标题很误导人,用这一句“好代码是廉价的代码”就好了。

  4. 没看出来内容和标题的关系,是不是翻译有问题?

    good code is cheap code 也许可以翻译为 好代码都是简单的

  5. reeze says:

    是有点标题党了…
    我觉得这个cheap应该是相对成本而言, 而不是廉价..

  6. tree says:

    反过来说,烂代码很费钱,因为需要不断的修理维护。
    这样来看,号代码就很省钱了。

  7. 胖子 says:

    加个引号就好了。
    不断重构,不断优化,快速上线。
    只是在某些大公司,只有最后一条

  8. Bruce says:

    如果是一个好程序员,那么他就知道在不久的将来会有哪些地方可能会做改动,同时他也会让自己的代码易于改动。
    好程序员总是在评估实现方法的性价比

  9. monkey says:

    说实话我也是最近才领悟到这一点的,用那么多的模式、框架、配置文件有必要吗?代码简单了,开放和运行的效率才会上去,出现bug的几率也会大幅度降低,重构和扩张也会更容易!同样也会降低服务器的压力……

  10. 谈谈IT says:

    真正意思是好代码是成本低的

  11. 啃冰 says:

    看到这些回复就想笑,anyway,大家都理解了“good code is cheap code”,再怎么标题党,作者或译者也如愿了。

  12. Yanjun says:

    不要被作者误导了,那是在开发一些小程序或者一些小系统时确实是,如果是中大型系统,那可就坏事了。一些模式的应用,本来,就是在设计,可维护,性能等方面的一个比较合理的折衷。

  13. xbon says:

    cheap译为轻量的也许更合题意。技术滥用其实是一直存在的问题,有些人更是喜欢这样以显示自己的“厉害”。大道至简

  14. 郭佳赫  这篇文章
  15. Evans 对这篇文章的反应是很实用
  16. 张汉峰  这篇文章
  17. keatkeat says:

    我们用模式用框架开发主要是为了统一开发节奏,复用性高,理解起来容易。
    每个人都知道如果左看右看没有车,红灯也可以过的道理。但你会发现哪有这么好每次都没有车!
    客户的要求总不会是这么简单的。

  18. adwan says:

    好代码是超出客户智商并预测未来同时照顾自己且简单的代码

  19. 丁俊玮  这篇文章, 并对这篇文章的反应是赞一个
  20. 鲁承星 对这篇文章的反应是赞一个

发表评论

电子邮件地址不会被公开。 必填项已用*标注