Java代码评审都是怎么开展的呢？

1，代码评审可以帮我们提高代码质量，实质上就是一群人没事找找刷刷存在感。

2，代码评审可以提高产品的拓展质量。

3，项目外包的代码别提有多烂，外包公司只负责功能开发，不负责后期，所以很短的时间很难磨砺出来好的轮子。

4，代码审查可以提高我们程序设计逻辑能力，代码规范。

5，代码要经过黑盒测试，扫描代码安全漏洞。

为什么要做Java代码评审？

常见的代码规范：

阿里巴巴开发手册，阿里代码扫描工具。这两个是常用的代码规范工具吧，毕竟某厂996也是来源至此。（大型互联网公司都有自己的代码自检工具，和规范，不同公司的规范是不一样）

常见的代码规范：我们代码层面面向对象设计思想遵循，设计模式的原则就是最大的规范。（设计模式可以帮我做程序拓展，大大提高了代码的移植和拓展，设计思想有多重要，百分之70程序员其实都不是很清楚，就只会面向百度编程，复制粘贴.......）

设计模式六大原则

开闭原则（Open Close Principle）

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

里氏代换原则（Liskov Substitution Principle）

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

封装 继承 多态 重写（模版方法设计模式中） 接口、抽象类

依赖倒转原则（Dependence Inversion Principle）

这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。

迪米特法则（最少知道原则）（Demeter Principle）

为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

合成复用原则（Composite Reuse Principle）

原则是尽量使用合成/聚合的方式，而不是使用继承。

数据库三大范式规范：

1、第一范式：

当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。

2、第二范式：

如果关系模式R满足第一范式，并且R的所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

3、第三范式：

设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

服务器规范：

1，命令规范，必要权限控制，怕你使用rm -rm 像这样的命令是很恐怖的。

2，权限规范，根据用户分配不同权限，由专业的运维人员管理。

3， 越是安全等级高的服务器，越要严格划分权限等级。

其实最恐怖的的是数据泄密规范，数据的泄密是属于重大事故，国外对数据安全把控特别严格，国内也是特别重视数据的泄密操作，这也是你必须签署保密协议，安全协议，就连开发都是涉密开发，涉密开发都还是一套安全机制的策略。

代码评审属于必不可少的环节，代码审查是分析现有代码存在的一些问题，规范代码。

代码审查的流程：

1,选择代码分支发起codeview。（一般代码自检工具都已经帮我们做了很多事）

2,代码审查开始进行评审。

参与代码审查会议，根据代码核心功能，代码实现，代码用法，后期扩展，代码规范，读代码。

一行一行审查代码，哪里不妥。

3，代码审查修改，再发起codeview,最后敲定版本进行代码验收。

看完你觉得代码审查简单吗？代码审查其实是部署阶段一个很重要的环节，对此你怎么看？