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