编程规则

编程规则--转载

个人一直很喜欢这篇文章，一直保存着…… 总是在脑袋模糊、混沌的时候都会翻出来读一读，其实下面的十条已经不仅仅是编程的规则了！ 下面我带您一起解读！ 规则一这世界上唯一的真理就是不要盲目相信真理 这本就是一条哲理，无需赘述。 从某种意义看，原则、规矩这类东西就是用来打破的。所谓原则，就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近，我们可以参考前人的经验。我们是主动地拿来，而不是被动的遵守。 规则二未蕴而变，自欺也；知律而变，智者之道也 这条规则亦可用在过程改进上，要想改变现在的流程，你首先必须对流程很了解，正所谓“知律而变”也 这句话谈的是学词，必须先了解格律，然后才谈得上变化，否则就是自欺欺人了。在编程上，也是一样。在有资格打破一条原则前，首先要了解这条原则。先了解事物的规律，然后才是变化和灵活的应用。不要打倒自己不了解的东西。 规则三寻找结构和成本的平衡点。当结构不能容纳变化时，重构代码到新的平衡点 这条规则亦诠释着当今的金融海啸，当华尔街的资本结构和利益的平衡点发生改变的时候，正是因为华尔街的资本结构容不下华尔街那些贪婪的家伙对利益的追逐，因此经济危机产生了！几次经济危机都已经告诉世人，资本主义的金融结构需要打破当前的格局建议一种新的平衡，重构金融市场找到新的平衡点。 开闭原则要求：一个软件实体应该对扩展开放，对修改关闭。即软件的结构要达到：允许在不修改软件的前提下扩展软件功能。但好结构是要花成本的。程序员总是在折衷，寻找结构和成本的平衡点。我们会放一些余量，让结构能承受一定的变化。 规则四要针对接口编程，不要针对应用编程 这条规则很简单，我们不可能是为了编程而编程，也不可能是为了做事而做事。所有的事物都应该有对接。 前面谈过了。我们总希望通过工作得到一些收获，积累一些经验。只有将代码分解成尽可能独立的模块，然后针对接口编程，才能保护我们的成果，让我们有所积累。 规则五最少知识原则：模块对外界的了解应当尽可能少 《道德经》是经典中的经典,博大精深 前面也谈过了。所谓“圣人之治”，经常是“虚其心，实其腹；弱其志，强其骨，常使民无知无欲”。让被管理的对象尽可能得弱，对象间的关系尽可能得简单，可以降低管理的成本。在面向对象编程中“组合优于继承”，就是因为继承将基类的实现细节暴露给子类，两者的耦合性太强了。另外，继承的实现是静态的，而组合可以更灵活地实现。 规则六 尊重习惯 21天能养成一个习惯。很多成功的人之所以能胜出，80%的原因都是因为他们比你习惯要好！ 在任何领域编程，应该尽量了解这个领域的习惯，尽量符合这些习惯。这样，别人可以更容易地理解和使用我们的程序，更不容易出错。 规则七 程序中不要出现magic number或其它神奇的东西 magic number就是诸如17、42这类数字。请用有描述性的常数名替代它们。常数名、变量名、函数名就是最好的注释。结构清晰的代码甚至可以不需要其它注释。 “需要很多注释的代码”是代码坏味道的一种，常常意味着需要重构代码，使它更容易被理解。 规则八 “两顶帽子”和“小步前进” 你愿意“大步慢跑”还是“小步快跑”？这是老板问我的问题。很有意思，包含哲理！ “两顶帽子”前面讲过了。面对复杂的问题，我们不仅要从结构上分解它，还要将实现步骤尽可能地分小，在一时一地以压倒性优势解决问题的一小部分。n-1个总比n个好对付，我们越来越强大，敌人越来越弱小，我们要做的只是将优势保持到最后。“保持优势”的关键是正确的理解、合理的划分。 规则九适当地引入中间层，可以解决所有问题 很简单又很试用的原则，很多问题需要迂回解决，不能单刀直上，那样解决不了问题反而让问题更复杂。 这条规则是实质是“抽象”。在遇到问题时，多引入一层接口，将问题封装起来。抽象本身并没有消除系统的复杂性，但它减少了在某个时刻需要处理的细节的数量。或者说，抽象将复杂性控制在接口和模型的后面，可以推迟我们处理这些复杂性的时刻。这条规则的另一个说法是“多做白日梦”。假设我们已经得到了需要的东西，然后会怎么？通过“白日梦”我们可以在更高的层次考察问题，可能找到解决问题的线索，也有可能发现这个问题毫无价值。即使毫无收获，我们也的损失也很小。 规则十不要依赖调试，尽可能地依赖分析和推理 要深究事务的本质，这需要用脑子去分析和推理。不要想着调试通过就OK，也不要侥幸的认为这个风险没有转化成问题就可以将该风险“束之高阁” 我经常会在头脑中预演调试的过程，计算我要做什么，我能得到什么。“预演”的结果经常是我没有必要这样调试，或者应该试一试另一个方法。根据测不准原理，任何实际的测量、调试都会改变、影响被研究的对象。用调试辅助、验证我们的推测，但不要依赖调试。