我相信软件开发人员都多多少少听说过「规范」一词，如："这段代码很规范！"，"这种写法不遵守规范！"等，而随着软件行业的发展，各种「规范」也层出不穷，基础点的有设计的规范如设计模式，特定语言的规范如Java开发规范，特定领域的规范如电商业务开发规范，细化点的有：公司的规范，项目组的规范，甚至个性化一点的有个人自己的规范，前任开发人员留下来的规范等。可能每个开发人员每天都会遇到各种与规范相关的抉择，如：这些规范我应不应该遵守，是不是还有些我不知道的规范需要遵守，本篇想谈的就是开发人员应该如何看待并遵守规范
也许有人会说，「这个还用想吗？规范就是好的，标准的，遵守就完了，想那么多干嘛？」，对于这种看法，我觉得不能说是完全错，因为它至少比完全不知道规范来得好，但就像对一件事物的认知经常要经历「看山是山，看山不是山，看山还是山」这三个阶段，而认为不管三七二十一，直接遵守规范的人应该就处于「看山是山」这个第一阶段：知道有规范这么个东西，觉得大概是好的，那就应该使劲用。但是，有心的人可能会多想一层：我为什么要遵守这些规范？遵守了规范会带来什么好处呢？
回答这个问题之前，我们先来看下「规范」这个词本身的含义：
「规范」一词本身可以指代一种「范式」或一种「标准」，表示的是对特定的事情，由前人总结出来的好的，值得借鉴的行事准则
其实通俗一点的意思就是前人总结的经验心得，即：在特定的场景下最好这样做，回到为什么要遵守规范的问题，我们不妨反过来思考，不遵循规范可以吗？就如同刚进入一个行业，师傅把毕生经验智慧传授给你，但是你觉得太麻烦，要按自己的想法来，最后的结果无外乎两个：
- 碰得鼻青脸肿，失败而归
- 环境变了，你还真就"乱拳打死师傅"，成功了
我想，大概率第一种的可能性比较大，而对于第二种情况，要么是你运气比较好，要么你是不世之材，注定改变行业，创造规则，但这两个可能性都很小；所以说遵守规范的好处就在于：当我们对事物的认知还不成熟的时候，这是成功概率最大，失败概率最小的一种做事方式，换句话说，你是菜鸟的时候就按高手总结的套路来，这个时候不用纠结太多，纠结也不一定有个所以然
而当有一定的积累，有些人就会思考自己每天遵守的规范所代表的更深层次的含义，但由于还是一知半解，并未完全理清楚规范的本质，所以这个时候会比之前啥都不懂，无脑遵守要来得纠结，正所谓「看山不是山」，规范还是那些规范，只是你突然有些无所适从，不知道为什么要遵守；一般这种情况就应该多锻炼多思考，多与高手沟通，争取早日达到第三阶段：「看山还是山」，这个时候将突破迷茫，并且对规范的表象到其背后的本质都了然于胸，所谓「知其然，知其所以然」，这个时候设计开发不需要僵硬的去考虑遵循什么规范，用什么设计模式，一切自然而然就呈现出合适的结果，即便最后发现出来的代码好像不符合某些规范，大部分情况可能是这些规范不适用于你当前的场景，也就是你自己已经不知不觉针对这个场景创造出了更合适的规范
在平常的工作中，很多开发人员都停留在第一个阶段，这样常常就导致一个现象，为了遵守规范而遵守规范，如听说要「面向抽象编程」，那么好，所有的实现类上层都加一个接口，包括很多根本无抽象需求的实现类；或者听说「实现接口比继承父类要好」，就完全拒绝继承；更有甚者道听途说了一些适用场景很窄或者完全不正确的所谓规范，不加思考，直接生搬硬套，导致出来的代码要么过度设计，要么匪夷所思，这都是没有思考规范的本质带来的后果；其实规范这个东西就像是数学里的公理和定理，它们都有自己的适用范围，使用合适了肯定会带来正面效果，而不合适的使用会导致矛盾不好的结果；比如「开闭原则」这种就类似于一个普世的规范，你应该尽量和自己的设计开发思维融为一体，类似的有「遵循普遍接受的命名惯例」等，而像「枚举比常量要好」，「基本类型优于装箱类型」等就属于有一定适用范围的规范，你应该理解其背后的原理，再结合当前场景判断是否应该遵守
说一千道一万，规范是死的，需求是活的，专业的软件开发人员应该尽量思考规范背后的本质，这样方可兵来将挡水来土掩，反之若一味固守一套死规则，不知也不会变通，那就永远只能处于初级阶段，无法走得更远！
