|
|
本文是从 Complexity is the enemy 这篇文章翻译而来。
差不多在Google工作有7个年头了(!)。我在这学到了很多东西，写都写不完。然而不管怎样，我至少要向你们分享一条只有在我有了更多经验后才得到的东西。
复杂是软件的死神。你无法用数字评估它所造成的代价，它会悄悄慢慢的出现，就像是用小火在煮你，让软件变得越来越糟，你很难察觉到，而当你察觉到时，那已经太晚了。在另一方面，你经常的会很容易的看到增加复杂度带来的好处：增加一个新的扩展层，你可以实现新功能X，或把本来运行在一个机器上的进程分成两个，用来解决当前系统的扩展瓶颈。但现在你的大脑里必须想着这个新增加的层，或这还要实现一个远程调用层来管理这两台机器。
基本上，程序员老手和新手一样都很容易出现上面的情况。我认为这些年我在这个行业里学到的只是更擅长在两者之前取得平衡；何时复杂一点是合理的，何时必须要拒绝。我经常回想起一个朋友在Ken Thompson写的Go语言编译器上的一句评论：它很快，因为它没有做多少事，代码直接明了。
事实表明，就像你能很容易的写出一篇很长的博客但把相同的观点叙述的简明扼要却很难，你很难把软件写的简单明了。在编程语言的设计上你最容易看出这一点；新手设计出的语言总是包含大量的功能特征，而很少像C语言那样清爽明晰。如今的程序，动不动就牵涉多少个对象；这在分布式系统里就意味这你要移动多少的东西。
另外一个用来描述这个问题的词是“才智”：引用另外一个C程序员的话，“调试纠错程序比第一次编写出这程序要困难两倍，如果你是用尽了你所有的聪明才智写出这程序，那根据这定义，你就没有最够的才智去调试debug它了。”
建议吗？我怀疑只有通过经验才能理解这个道理——有一个事很刺激我，太多的项目里都有人认为元数据编程很酷。我发现制定一个详细的设计目标来评估新代码是否有必要，这很有帮助。如果你可以说“这些代码不能帮助项目的最初设计目标上解决任何问题”，你就能很容易的拒绝这些代码。在Google，用来描述一个新项目的设计方案的文档模板上，在其右上角有个区域专门列着目标外内容：对项目的合理扩展将会被拒绝。
很讽刺的是，我发现使用弱智的工具或语言能帮助我们抵制复杂。你很难写出一个很复杂的C程序，因为它里面没有太多的东西。C程序大多用大量的数组，因为你只能用它，但结果却证明，数组是非常好的东西——紧凑的内存使用，O(1)次的数据访问，很好的数据存储。但我从来没有倡导过特意的使用一种弱智的工具。相反，我的心得是：像C一样编写Python程序。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
