Complexity is the enemy 复杂是敌人翻译

» Complexity is the enemy

I'm almost through my seventh year working at Google(!). I have learned many things there, more than I could ever write down. I thought I would at least share with you something that's only come to me with more experience.

 

我已经在google待了7年了。我在那儿学到了很多比我以前用纸记录下来的更多的东西。我认为我能够与你分享一点我的经验，这些经历使我变得更有经验

Complexity is the death of software. It's hard to quantify the cost of, and it tends to creep in slowly, so it's a slow boil of getting worse that's hard to see until it's too late. On the other side, frequently it's easy to see a benefit of increasing complexity: a new layer of indirection allows new feature X, or splitting a process that ran on one machine into two allows you to surmount your current scaling hurdle. But now you must keep another layer of indirection in your head, or implement an RPC layer and manage two machines.

 

复杂的软件往往导致一个产品死亡。事实上往往很难衡量它的成本，而且复杂化的过程是很缓慢的，这个过程中存在的问题是很难被发现，直到量变达到质变的程度，那时已经为时已晚。但是从另外的一个角度看，增加了一个功能增加了复杂度，往往会带来好处，例如：增加一个新的间接层，会有产生新特性X的可能，或者将在一台机器上的的处理流程一分为二（就像我们口碑现在搞的hsf服务化改造），使得你能够超越你现有的处理能力，但是实际上，当你解决了一个问题之后会产生出另外的问题。这个时候你必须要额外增加另外的一个中间层的维护开销，或者需要实现一个RPC（远程调用层）并且管理两台机器。

The above is hopefully just as obvious to a new programmer as it is to a veteran. What I think I've learned through my few years in the industry is a better understanding of how the balance works out; when complexity is warranted and when it should be rejected. I frequently think back to a friend's comment on the Go compiler written by Ken Thompson: it's fast because it just doesn't do much, the code is very straightforward.

 

这些对于有经验的程序员来说是显而易见的，我希望新程序员也能有同样的感受(这句是而杨总翻译的)，我认为我在大学中学习到的是更好地理解执行中的平衡。当过度复杂已经被证明，这个时候你应该学会拒绝。我经常回想起一个朋友对《Go compile》这本书的评论：因为没有额外做很多事所以实现可以很快，而且代码会非常直接明了。

 

 

It turns out that, much like it's easier to write a long blog post than it is to make the same point succinctly, it's difficult to write software that is straightforward. This is easiest to see in programming langauge design; new languages by novices tend to have lots of features, while few have the crisp clarity of C. In today's programs it's frequently related to how many objects are involved; in distributed systems it's about how many moving parts there are.

 

结果是，你会发现写一个长的博客来表达一个主题是容易的，相对于用非常简洁的语句来表达。用非常直接的方式来写一个程序是非常困难的。这种现象在编程语言的设计过程中是最容易发现的。一个新的语言会有很对特性，然而很少有C语言那样清晰明了的。眼下的程序经常需要考虑要与有多少对象有关；在分布式系统中，需要考虑有多少移动的部分运行其中。

Another word for this problem is cleverness: to quote another one of the C hackers, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

What helps? I wonder if it maybe just comes down to experience -- getting bitten by one too many projects where someone thought metaprogramming was cool. But I've found having specific design goals to evaluate new code by can help. It's easier to reject new code if you can say "this does not help solve the initial goals of the project". Within Google the template document for describing the design of a new project has a section right at the top to list non-goals: reasonable extensions of the project that you intend to reject.

有什么帮助吗？我怀疑这要归结为我们的经验了------在不止一个项目中痛苦纠结之后发现元数据编程是一件非常cool的事。但是，我发现有开发的时候,有明确的目标的话可以对评估新代码有所帮助。拒绝新的代码是非常容易的如果你能说“这对解决项目初始目标是没有帮助的”，在google中，在项目初始阶段,在设计项目项目的时候，需要使用模板文档，在这个模板文档上有一些非项目目标的条目需要写：你打算拒绝的合理的项目扩展点（很难理解为啥要把这个写下来，现在口碑项目需求往往是不合理的项目需求都接下来了，更不用说合理的了，我得想想这个中间有什么玄机）

Ironically, I've found that using weaker tools can help with complexity. It's hard to write a complicated C program because it can't do very much. C programs tend to use lots of arrays because that's all you get, but it turns out that arrays are great -- compact memory representation, O(1) access, good data locality. I'd never advocate intentionally using a weak tool, though. Instead, my lesson has been: write Python code like it was C.

 

具有讽刺意味的是，我发现使用弱工具（weaker tools）能够解决复杂性的问题。使用C语言写一个复杂的程序是困难的，因为它所能做的事是有限的。C语言会使用很多数组因为那就是你所能使用的，但是结果是数组是很有用的虽然很简单，---紧凑的内存使用等。我从未特意的提倡使用弱工具，但是，当我写Python 代码的时候会把程序的风格写得像C一样。