中国人总是迷恋大而全的东西，这种清洁也深深影响了中国的程序员和软件公司的老板们。每一个项目或者产品在规划之初和研发之中，都期望它能够是一个功能非常强大和完善的东西。为了这种期望，我们不得不把大道至简的东西搞得非常复杂。偏偏，复杂是软件的死神！
我们都是肉眼凡胎，根本无法看清复杂会给我们的程序带来多么可怕的毁灭。但这种毁灭会悄悄慢慢的出现，就像是用小火在煮你，让你的研发能力和思考能力变得越来越糟，你很难察觉到，而当你察觉到时，那已经太晚了。在另一方面，你会很容易看到增加复杂度给你带来的好处：增加一个新的扩展层，你可以实现新功能X；或把本来运行在一个机器上的进程分成两个，用来解决当前系统的扩展瓶颈。但现在你的大脑里必须想着这个新增加的层，或这还要实现一个远程调用层来管理这两台机器。
基本上，程序员老手和新手一样都很容易出现上面的情况。我认为这些年我在这个行业里学到的只是更擅长在两者之前取得平衡；何时复杂一点是合理的，何时必须要拒绝。我经常回想起编程初期一位师长对某个程序所做的评论：它很快，因为它没有做多少事，代码直接明了。
很多人都有这样的经验：我们可以絮絮叨叨地对别人数落半天，但要简明扼要地指出对方的错误却往往词不达意。同样的道理，我们似乎都很难把软件写得简单明了。在编程语言的设计上你最容易看出这一点；新手设计出的语言总是包含大量的功能特征，而很少像C语言那样清爽明晰。如今的程序，动不动就牵涉多少个对象；这在分布式系统里就意味这你要移动多少的东西。
另外一个用来描述这个问题的词是“才智”：引用另外一个C程序员的话，“调试纠错程序比第一次编写出这程序要困难两倍，如果你是用尽了你所有的聪明才智写出这程序，那根据这定义，你就没有最够的才智去调试debug它了。”
有些道理，只有在真实地遭遇经验甚至教训之后才能心悦诚服。有一个事很刺激我——太多的项目里都有人认为元数据编程很酷。我发现制定一个详细的设计目标来评估新代码是否有必要，这很有帮助。如果你可以说“这些代码不能帮助项目的最初设计目标上解决任何问题”，你就能很容易的拒绝这些代码。在Google，用来描述一个新项目的设计方案的文档模板上，在其右上角有个区域专门列着目标外内容：对项目的合理扩展将会被拒绝。
计算机技术发展至今天，各种开发的工具或语言在虚拟世界里争奇斗艳。但我们很容易发现，使用基础的工具或语言能帮助我们抵制复杂。你很难写出一个很复杂的C程序，因为它里面没有太多的东西。C程序大多用大量的数组，因为你只能用它，但结果却证明，数组是非常好的东西——紧凑的内存使用，O(1)次的数据访问，很好的数据存储。但我从来没有倡导过特意的使用一种老牌语言。我想尝试的是：像C一样编写Python、Java以及其他新兴语言。
本文转自狗窝博客51CTO博客，原文链接http://blog.51cto.com/fxh7622/564442如需转载请自行联系原作者
fxh7622
