前言：

作为一个技术负责人，不能只定义一个项目的技术选型，而不注意开发细节。
开发前，如果不预先定义好规范，那么项目中就会乱成一锅粥。每个人自成一派，单看每个人的模块，貌似都没啥大问题，但合在一起，就明显感觉是多个人开发的。这个时候，等发发现问题，再让某些人去改的话，一方面容易引起coder的反对，另一方面也会减少技术负责人的威望。因为一般出现这种情况，大部分原因是项目的技术负责人不合格，没有把事情提前想好，也就是所谓的没有经验。

那么，如何才能当一个合格的技术负责人呢？如何去定这些规则呢？

0、约定

1、确定业务常用词语的英文单词，项目开始的时候提前做这一步，后期开发会有意想不到的酥爽。
2、提前写好常用工具类，比如文件上传下载，转换工具类，excel操作工具类等。
3、提前约定好其他常用开发约定，比如可以按照阿里巴巴开发规范去做，idea也有对应的代码检查插件，可以让每个人都装上。
4、提前约定好代码风格，比如统一面向接口编程，service+serviceImpl等。其实这个也是阿里巴巴规范中有的。
5、约定好项目中所有的状态都用int类型，0一般不用，1代表有效，2代表无效等等
6、约定好dao层的写法，比如都用mybatis或者mybatis-plus，mapper直接用注解sql还是XML

1、git规范

现在开发对于版本控制，最多就是git了，所以以git为例，讲讲通用的规则。
一般线上分支是master，保证上线部署的必须是master分支的代码。
开发总分支是dev分支。
普通的开发分支一般是dev_业务内容，这个其实就没有那么多限制了。
1、新代码开发完成后，本地环境自测，测到通过。
2、然后合到dev后，上测试环境测试，测到通过。
3、最后code review，然后由技术负责人或者指定的一位大佬将dev的代码合到master。
4、master分支上线，上线后再次测试验证。

对于普通的开发人员：

所有关于master的操作一律禁止。
开发完成并且自测通过后，只需要将自己开发分支的代码merge到dev分支，然后将devf分支部署到测试环境，测试通过即可。
所有新分支都从dev分支拉出来，切勿从master分支拉代码。
dev分支，不允许普通的开发人员直接提交。

对于技术负责人或技术负责人指定的开发大牛

负责dev代码的codereview。
负责将dev代码合到master。（gitlab中有merge request，直接审批也可以）

2、数据库规范

数据库相关的，有些事情需要提前规范好。比如：
1、每个表中，都要带有create_time和update_time字段，时间类型。
2、每个表中，都必须有自增id字段，bigint类型。
3、具体业务中，常用单词的英文翻译，需要提前定义好。比如企业员工，有人用user，有人用staff，其实用哪个都可以，重在统一，提前要说好，比如都用user。
4、sql规范，比如查询禁止使用select *，禁止表连接等等。
5、数据的删除，都是逻辑删除，del=1代表已删除，del=0代表未删除，禁止使用delete语句物理删除数据。
6、复杂业务的库表，必须先设计，后开发。技术负责人应该把所有设计都过一遍，避免返工。

3、包结构规范

1、比如项目实体统一放在entity包下，dao层统一放在dao包下，service，controller同理。
2、比如service使用面向接口编程，统一先定义接口，再实现接口。比如userService接口和userServiceImpl实现类。
3、提前给同学们说明项目中dto，vo等对象的含义以及使用场景。
4、提前根据项目要求，提供出一些公共的util，比如文件上传下载，excel导入导出，校验等等，这个不强求，如果项目中开发人员普遍技术水平较高，可由开发同学自己编写，但需要定一套统一的util，避免重复开发。比如excel的导入导出，可能有人用easyexcel，也有人直接用poi，这样poi的包版本就有可能和easyexcel中引用的poi包版本冲突。

4、代码质量检测工具

如果代码量过大，没有人力去codereview，那就要用一些代码检测工具了。比如统一使用CheckStyle插件，也可以自定义一些检查规范。
这个也是代码的终极规范了。但不要完全依赖，只不过是一些明显的错误可以被挖出来了，一些偏业务的坑，还是需要codereview的。
个人经验，基本上看一个人写代码，看他写100行的核心代码，就知道这个人的代码的大概质量了。