Chinese Translation of Complexity is the enemy

I just came across a good article about software design written by a Google engineer. I have found a Chinese translation, but some parts, particularly the last paragraph, are not satisfactory enough. So I simply put up my own.

复杂是敌人
作者 Evan Martin
原文地址:http://neugierig.org/software/blog/2011/04/complexity.html

我来到谷歌都快要满七个年头呢。我在这里学会了许多,远比我能写下来的要多得多。我想我至少可以和你们分享一些经验。

复杂是软件的死敌。它非常难于定量描述,而且日积月累。它像一个逐渐变烂的脓包,通常发现它时为时以晚。另一方面,通常增加复杂度的好处显而易见:新的间接曾允许新的特性,另一个例子是,把运行在一个机器上的程序拆分成为两个,在两个机器上面分别运行来解决扩展的问题,但是你必须实现一个RPC层来管理这两个机器。

不论新手老手,上面这些好处都是显而易见的。通过这几年的工作,我认为我已经可以很好的平衡什么时候该加入新的复杂度,而什么时候不该。我经常回想我的一个朋友对Ken Tompson的Go编译器的评价:它很快,因为它做得很少,也正因此它的代码简洁明了。

写一篇长博客很容易,但是言简意赅的表达相同的观点就很难。同样,写简洁明了的代码也很难。最明显的例子就是程序语言设计;新手设计的语言总是有很多特性,但是缺乏c语言那样的清晰性。在现在的程序开发中有一种不好的风气,程序的优劣在于它用了多少对象,而在分布式系统中,在于有多少可以活动的部件。

另一个对于这个问题的描述是“过分聪明”。引用一位c大牛的话说: 调试比写代码难一倍,因此,如果你的代码写的太聪明,调试的时候你就得抓狂呢。

怎么才可以解决这个问题呢,我怀疑是不是只有通过痛苦的经验来解决---等你调完其他人用“元编程”写的程序你就明白呢。不过我发现如果加入一些设计目标用于评估新的代码,这个问题可以得到有效的缓解。因为这样你就可以更容易的判断新代码能否帮助解决开始的问题,从而决定是否应该拒绝。在谷歌内部的设计文档模板开头都有一个None Goals 列表:你需要合理拒绝的项目扩展。

具有讽刺意味的是,我发现使用较原始的工具能够有效的降低复杂读。你不太可能写一个很复杂的c语言程序,因为c语言所能做的不多。c语言倾向于使用数组这种原始的结构,因为数组确实很棒,紧凑的存储,O(1)的存取复杂度,很好的数据局部性。我这样说并不是倡导使用原始的工具。事实上,我的经验是:写python的时候最好将它当做c语言对待。

Reference

This is the translation I noted in the beginning of the article, thanks the translator, too.
http://photo.weibo.com/1915548291/wbphotos/large/photo_id/3520526301358418?refer=weibofeed

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: