常识——译者序

1776年,美国独立战争爆发,当时北美还有很多民众对“独立”充满怀疑: “北美真的要脱离英国吗”、“新的国家需要怎样组织”,这些今天看来不是问题的问题,并没有清晰明确的答案。就在此时,有位叫托马斯•潘恩的人站了出来,单枪匹马解开了人们心中的疑惑,大大鼓舞了北美民众的独立情绪,而他所依靠的,只是一本名为《常识》的小册子。

《常识》这本小册子说了什么呢?我随便摘录几句:“如果没有人监督,对国王是不能信任的;或者换句话说,渴望保持专制政权的欲念是君主政体的固有弊病”,“独立自主的问题不外乎意味着:究竟是我们将自己制定我们的法律,还是让这个大陆的目前和将来最大的敌人——英王来吩咐我们,除我所喜欢的法律以外不准有任何法律”,“让我们为宪章加冕,从而使世人知道我们是否赞成君主政体,知道北美的法律就是国王”…… 200多年后再读,仍然可以感受到这些文字的力量,所以不难想象,在美国独立战争时,告知民众这些道理,能发挥多么重要的作用。据载,在当时只有200多万人的北美,成年男子几乎人手一册《常识》。不夸张地说,这本书推动了美国建国的进程。

潘恩既不是高明的政治哲学家,也不是熟谙宣传的政客,他的书之所以具有如此大的力量,在我看来,主要原因是他能用朴素平实的语言把道理讲出来,告诉大家“原来是这样的”。换句话说,许多道理其实并不高深,但常识也必须以“常识”的形式表达出来,大家才能听进去。

读者或许会觉得奇怪,一本技术书籍的译者序,为什么要花这么多篇幅介绍历史呢?之所以这么做,是因为我在翻译本书的过程中,数次想到托马斯•潘恩的《常识》。我深刻觉得,在软件开发的各种书籍和资料中,也应当有类似《常识》的文本来告诉大家:道理原来是这样的,就是这样。

我相信,任何一位读者,只要认真看过全书,都会发现《简约之美》其实只强调了几条互相联系的简单道理:软件是必然要变化的,变化是常态;有变化就需要维护,随着时间的推移,维护成本会远远超过初期开发的成本,占据成本的大头;因此,在软件开发中,最重要的是要降低维护成本;维护成本正比于系统的复杂程度,所以要降低维护成本,系统的设计就应当追求简单清晰。

这根逻辑链条看似简单,其实并非如此。不少有经验的开发人员,似乎对这类“道理”不屑一顾,他们更在意新潮的技术、先进的架构、流行的语言……新出了哪种类库,什么软件新发布了版本,大数据该怎么处理,说起来头头是道,但真刀真枪地写起程序来,往往错漏百出(甚至不自知)。

我曾经见过一套系统,设计和开发这套系统的人几乎用到了.NET的所有高级特性,但95%以上都用错了,结果就是系统层次混乱、类责任混淆、通讯完全不可靠。诡异的是,许多错误都属于“地雷”,如果业务一直维持在原始甚至野蛮的状态,它们几乎不会爆炸。不幸,业务无可避免地要扩展、要增长、要规范,于是地雷一颗接一颗地爆炸,只能投入大量优秀程序员,花比开发多好几倍的精力,去维护和重构系统,才勉强保证了业务的发展。最终,当系统重构告一段落之后回头看,其实所谓的“维护”,也无非是“降低维护成本”,一点点地去掉之前那些花哨的特性,用简单的技术构建清晰的架构,而已。

就我所见,上面这种情况并不罕见,反而非常常见,更糟糕的是,还有许多项目始终不得解脱,被高昂的维护成本死死困住;即便推倒重来,因为设计和开发仍然缺乏对“降低维护成本”的足够重视,导致悲剧重现…… 说起来,这一切的根源都是因为目标不明确,没有考虑且不重视维护成本,也没有考虑设计的简洁清晰。其中的道理不算复杂,但怎么才能让大家明白?这个问题我一直在思考,所以在翻译本书时,才会反复想起托马斯•潘恩的《常识》——软件开发需要常识,软件开发的资料里需要《常识》之类的读本,不需要艰深的道理,也不需要花哨的说辞。潘恩的《常识》用短小的篇幅向广大民众澄清了“北美应该独立,且不需要国王”,我希望《简约之美》也能用短小的篇幅向广大开发人员说明“应当重视软件的维护成本,追求简单清晰的设计”。

——余晟,2012年12月6日

余晟,毕业于东北师范大学计算机系,副修中文,非正统型技术爱好者。曾任抓虾网、银杏泰克主力程序员,盛大创新院高级研究员,现任华南某电商公司技术总监。坚信计算机可以无限延伸人的能力,前提是人必须理解计算机的逻辑,所以对任何技术都不应该浅尝辄止,仅仅满足于“会用”。

目录

  • 版权声明
  • 常识——译者序
  • 前言
  • 第1章 引言
  • 第2章 缺失的科学
  • 第3章 软件设计的推动力
  • 第4章 未来
  • 第5章 变化
  • 第6章 缺陷与设计
  • 第7章 简洁
  • 第8章 复杂性
  • 第9章 测试
  • 附录A 软件设计的规则
  • 附录B 事实、规则、条例、定义
  • O’Reilly Media, Inc.介绍