编程规则－转载

规则一这世界上唯一的真理就是不要盲目相信真理

从某种意义看，原则、规矩这类东西就是用来打破的。所谓原则，就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近，我们可以参考前人的经验。我们是主动地拿来，而不是被动的遵守。

规则二未蕴而变，自欺也；知律而变，智者之道也

这句话谈的是学词，必须先了解格律，然后才谈得上变化，否则就是自欺欺人了。在编程上，也是一样。在有资格打破一条原则前，首先要了解这条原则。先了解事物的规律，然后才是变化和灵活的应用。不要打倒自己不了解的东西。

规则三寻找结构和成本的平衡点。当结构不能容纳变化时，重构代码到新的平衡点

开闭原则要求：一个软件实体应该对扩展开放，对修改关闭。即软件的结构要达到：允许在不修改软件的前提下扩展软件功能。

但好结构是要花成本的。程序员总是在折衷，寻找结构和成本的平衡点。我们会放一些余量，让结构能承受一定的变化。

规则四要针对接口编程，不要针对应用编程

前面谈过了。我们总希望通过工作得到一些收获，积累一些经验。只有将代码分解成尽可能独立的模块，然后针对接口编程，才能保护我们的成果，让我们有所积累。

规则五最少知识原则：模块对外界的了解应当尽可能少

前面也谈过了。所谓“圣人之治”，经常是“虚其心，实其腹；弱其志，强其骨，常使民无知无欲”。让被管理的对象尽可能得弱，对象间的关系尽可能得简单，可以降低管理的成本。

在面向对象编程中“组合优于继承”，就是因为继承将基类的实现细节暴露给子类，两者的耦合性太强了。另外，继承的实现是静态的，而组合可以更灵活地实现。

规则六尊重习惯

在任何领域编程，应该尽量了解这个领域的习惯，尽量符合这些习惯。这样，别人可以更容易地理解和使用我们的程序，更不容易出错。

规则七程序中不要出现magic number或其它神奇的东西

magic number就是诸如17、42这类数字。请用有描述性的常数名替代它们。常数名、变量名、函数名就是最好的注释。结构清晰的代码甚至可以不需要其它注释。

“需要很多注释的代码”是代码坏味道的一种，常常意味着需要重构代码，使它更容易被理解。

规则八 “两顶帽子”和“小步前进”

“两顶帽子”前面讲过了。面对复杂的问题，我们不仅要从结构上分解它，还要将实现步骤尽可能地分小，在一时一地以压倒性优势解决问题的一小部分。n-1个总比n个好对付，我们越来越强大，敌人越来越弱小，我们要做的只是将优势保持到最后。“保持优势”的关键是正确的理解、合理的划分。

规则九适当地引入中间层，可以解决所有问题

这条规则是实质是“抽象”。在遇到问题时，多引入一层接口，将问题封装起来。抽象本身并没有消除系统的复杂性，但它减少了在某个时刻需要处理的细节的数量。或者说，抽象将复杂性控制在接口和模型的后面，可以推迟我们处理这些复杂性的时刻。

这条规则的另一个说法是“多做白日梦”。假设我们已经得到了需要的东西，然后会怎么？通过“白日梦”我们可以在更高的层次考察问题，可能找到解决问题的线索，也有可能发现这个问题毫无价值。即使毫无收获，我们也的损失也很小。

规则十不要依赖调试，尽可能地依赖分析和推理

我经常会在头脑中预演调试的过程，计算我要做什么，我能得到什么。“预演”的结果经常是我没有必要这样调试，或者应该试一试另一个方法。

根据测不准原理，任何实际的测量、调试都会改变、影响被研究的对象。用调试辅助、验证我们的推测，但不要依赖调试。

推荐到鲜果：

人月神话的Blog