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
Jing Conan Wang 