数据治理实战(二十)：从几百个实际项目中提炼。

下面看一下第五部分命名规范跟第六部分的开发规范。前面的四个部分都是从标准文件里边来的内容，参考国标、行业标准、地方标准、标准。从标准文件里边把它标准文件里边的内容信息化出来，去指导整个数据治理的建设开发过程。

·第五部分、第六部分就是项目上积累的一些经验，比如命名规范，这里边包含了数据仓库的整个的命名规范、实体的表、目录、脚本、工作流等等一些命名规范。

比如数据仓库里边的层级都是怎么去命名的？层级下面的表怎么去命名的？看到一个表就知道它是在哪一层的，这一个表大体的含义是什么，是在哪一个主题的，通过命名的规范。工作流是怎么样子？

·第六部分就是开发规范，代码的要求、代码的规范语法、注释怎么去写、测试的时候有什么规范、调度的时候有什么规范等等，这都是要去follow一个标准规范。

看一下标准规范的文档，这是项目上这么多年总结下来的经验，规范文档会有规则。看一下命名的规范，实际表命名的规范怎么去定义？自断命名、目录命名、自断命名，就是刚才讲了从数据员到自断过程都是通过数据来去命名的，都是follow国家标准的。

·第三部分目录的命名怎么取？存放的目录都是有命名规范脚本写的，每一个脚本怎么去命名的都是根据成绩、表明来去对应的。工作流是怎么去命名规范？这都是有命名其他的一些命名规范。

·还有一个就是开发规范，整个的开发规范是怎么样子的？有哪些个要求？内部表有什么要求？外部表有什么要求？要用什么样的风格服务？这些都是同意的。质量的要求、脚本的要求、怎么去传传餐、怎么去写注释等等。

这是整个的关于妹妹跟开发的规范的要求，不管是做什么行业、做什么项目，首先要定义在开发之前需要定义这样的命名跟开发的规范。这是非常有必要的。

这统一了大家的整个的编码或者是开发的习惯，要不然只要是项目上有人员变动，那么他留下来的东西其他人都看不懂的。如果是没有一个统一的标准规范。

所以举个例子，之前我在做项目的时候，之前项目组的一个成员去定义这种变量的时候都是很随性的，比如说用什么大瓜子、瓜子皮等等类型，类似于这种的去定义一个变量。除了他自己能看懂自己开发代码，别人根本就看不懂，而且注释也没有。如果他一旦有变化尤其在有变动，那么他留下来的东西别人基本上很难去维护。

所以命名规范也好，开发规范也好，这是在整个的项目管理上是非常有必要的。