迁移自简书，格式可能未经校对。

这周也帮其他人看了看代码，发现大家对一些规范不以为然，所以我想借这个机会聊聊。代码规范的重要性说的太多了，我来说说代码不规范的危害。

为什么要统一、规范的命名

举个例子，我们有公寓表 suites、房间表 rooms ，rooms 里有个关联到公寓的字段叫 suite_id。试问把 suite_id 改成 house_id 是否合理？

单从这个例子来说，好像并无不妥，suite 和 house 都能表示公寓的意思。

但是如果我告诉你我们现在还有额外的两张表：

• house_resources 信息采集端的外部房源，是外部房源进入收房系统的入口
• resource_house 楼盘字典中的公寓，沉淀下来的外部房源，暂定

这个时候，假如你是非直接开发人员，比如其他工程师、需要看数据库的运营、财务或是 BI，你第一感觉，rooms 表的 house_id 是到哪个表的关联？我觉得猜到 house_resources 的人会多一些，但如果是 suite_id，再辅之以注释，就会好很多。可即便如此，BI 同学也经常过来问字段的关系。。

这个例子想说明，当你的系统已经复杂到无法靠简单的 “望文生义” 去识别&区分时，你就得靠统一的规范去保证大家不会乱。我们约定所有的 xx_id 都是到 xx 表的关联，大家就不会再困惑。

如果只是自己私下写一个二三十行的小脚本，你用 abcdefg 命名没啥问题，但在这里，你 hold 不住的。

信息采集端的几个表前缀都是 house_resource ，渠道就是house_resource_users ，渠道费就是 house_resource_bills ，也算一个识别标记。其实从更大的角度来说，房源和客源的跟进，也都该放一起，历史遗留问题。。

为什么要抽象和封装

思考：为什么我和孟德都没有参与过合同、活动的开发，但都能在几分钟内添加一个可以自定义规则的新活动？答案是，因为现有的封装已经满足现阶段的需要，我们无须关注整个实现逻辑，只需要改一个文件里的一小段（其实就一个 array）就能实现了。

如果之前没有做这些工作，那么市场部今天下午告诉你12点前要上一个活动，你要从头熟悉整个代码，要熟悉每个节点的处理方式。恐怕你就是不吃饭不睡觉也来不及。

其他的系统里，遇到的问题也是一样的：

• 做支付平台，能否在不涉及业务逻辑的情况下，快速添加一个支付平台
• 做分期平台，能否在不涉及业务逻辑的情况下，快速添加一个分期公司
• 做房源对接，能否在不涉及业务逻辑的情况下，快速添加一个信息平台
• 做供应商管理，能否在不涉及业务逻辑的情况下，快速添加一个供应商

如果你为了省一天的时间，在将来却给每个人加了一天的工作量，那么你的代码就是有毒的。

诚然有很多情况，你并不能预测将来发生的情况，但是按照软件工程的原则，你应该留有扩展的空间。如果其他人已经帮你预料到接下来会有一个类似的东西时，你就必须考虑了。

小故事，退转换上线前的一个晚上，10点多。我在那里吐槽又要改需求，高靖听到了就跑出来跟我说，你们的系统要做的模块化，在碰到这种情况的时候就能快速组合几个模块达到他们的目的，我们以前巴拉巴拉省略500字。。

我当时一阵惊讶，一个不写代码的人都懂这个道理，可为什么我们这些“专业人员”却要对几十年的行业经验嗤之以鼻。

为什么会有必读源码

必读源码最大的用处就是让新人知道这个系统是怎么运作的。

当时我挑了好多个文件才决定选用这几份代码，有几个考虑：

• 里面包含了laravel、orm 的基本用法和文档，能让你快速上手
• 有我们沉淀下来的各种轮子，能让你快速实现常用的功能
• 有我们最一般最一般的产品设计规范，避免你为了达到某一个效果费劲脑汁

看这三份代码花不了个把小时，但是不看呢，有几个人都踩了坑，其结果是本来几十行代码的事，花了几百行才搞完。费时费力还有坑

分享两例小故事，

• 有天雷雷一激动说我们能不能把完成标成红色（好像是喜庆的意思），我还没开口，旁边一个销售就说我们习惯绿色了，然后我才说我们把红色作为警告的意思。

• 还有我们的列表里按钮一般都在首列，结果就是无论第一列是“编辑”还是一个图标，大家都知道那个修改的地方。

红和绿、行首或行尾，都不是什么原则问题。但是在现有环境下，随机改动就增加了其他人的识别和使用成本，那就属于不合理的设计。

系统内部的 Error、Flash（小提示）、Confirm 以及 DataEditor 的错误提醒，都是统一的组件，即能提高你的开发效率，也能保证绝大多数人快速上手你的作品。

总结就是，强调代码规范，不是闲的蛋疼去满足个人的代码洁癖，而是不想让大家再去踩之前已经踩过的坑，提升整个团队的效率。

至于什么是代码洁癖，我可以分享一下我的一些洁癖：

• 我不喜欢一大行从半截折开，我自己设的最大宽度是160，后来妥协于 psr 规范，改成了120，出现了很多我觉得奇丑无比的折行。而且经过“科学试验”，我认为我们的项目设140比较合适，为此和张卫还争论过。。
• 我写 json，key/val 之间的冒号我要对齐，工具不支持我就手动对齐，但是为了统一，我也放弃了。绝大多数工具是冒号左边有空格，右边却没空格，我也觉得丑，但。。你懂的。
• 一个表达式a + b*c，仔细看，+ 两边有空格，但 * 两边没有空格，这是 Go 官方fmt 工具的标准格式，它会把优先级高的运算放一起，低的才有空格。在接触 Go 之前，我自己其实也这么干，特长的表达式，几个空格、几对括号的情况都有过。就为了阅读清晰。
• 有贝原名 uubee ，我在后台都写的 Ubee，是因为首字母要大写，我觉得 Uubee 又极丑无比，所以就省了 u。好在有 namespace 挡着，应该不会干扰其他人。

所以，不要觉得我是在故意刁难，为了遵循psr 规范我已经很委屈了。。

其实说这些东西，并不是因为水平多么厉害才提，这些规范都和技术本身无关。提到的东西，也都是一路颠簸的血泪教训。谁没被自己的代码恶心过几回？

今天这些更多的是想说为什么要好好设计你的代码，至于怎么设计，以后一点点的整理吧 ^_^

最后

我坚信，写代码不是砌砖，不是画条线放块砖就完成任务了。奥对了，即便是砌砖工人，发现有块砖烂掉了也会毫不犹豫的扔掉，也不会以“赶工期”为由说“就这样吧，反正又不会塌”。