复杂是软件的死敌，它很难估值，常慢慢地混入到软件开发中。它像一个逐渐变烂的脓包，发现它时，为时已晚。从另一方面 来讲，增加复杂度可以帮你解一时之忧：一个新的间接层允许增加新的特性X，但同时你需要增加另外一个间接层；把运行在一个机器上的过程分隔成运行于两个机 器上的过程，可以帮你解决当前遇到的扩展难题，但你同时也必须实现一个RPC层，来管理这两个机器。

上面所说的现象在开发者新人中和在老手中一样突出。通过这几年的工作，我认为我已经可以很好地在这方面达到平衡，什么 时候应该增加软件的复杂性，什么时候应该拒绝。我常常回想一个朋友对Ken Thompson所开发的Go语言编译器的评价：它很快，因为它只做很少的工作，它的代码十分简单易懂。

写一篇长长的博客容易，而用简短的话来概括相同的观点却很难，同样的道理，开发一款简小而优秀的软件是很困难的。在程 序语言设计中，此种现像很普遍。新手所开发的新语言包含过多的属性，很少具有C语言的简明和清晰。在今天的程序开发中，程序的优劣与其包含多少个对象有 关，在分布式系统中，则与有多少个可移动的部分有关。

针对此问题的另一个词语是“精巧”：再引用这位C语言大牛的一句话，“调试代码比写代码困难两倍之多，所以，你如果写的代码尽可能的精巧，理论来讲，你很难对它进行完美地调试。”

什么可以帮助解决这个问题呢？是否只能依靠经验呢？我发现，通过特定的设计目标来评估新代码可能会有帮助。如果你说 “这并不能帮助解决项目的最初目标”，那么可以很容易地把新代码否定掉。在Google，每个新项目的设计模版文档的开头都有一个“ non-goals”列表：你应该拒绝的合理的项目扩展。

很讽刺的是，我发现了一个很“差劲”的工具，它可以帮助减低软件的复杂度。用C语言写一段很复杂的程序很难，因为它所 能实现的功能有限。C语言通常会使用大量的数组，而且你只能使用这些数组，但是这些数组功能很强大——可以压缩存储器表达式，如O(1) ，可以很好的定位数据位置。我从未有意地提倡使用这个“差劲”工具，然而我所得到的应验是：像C语言那样写Python代码。