规范手册

看了《代码精进之路：从码农到工匠》这本书以后，有了一些小启发。感觉大厂如阿里的规范手册，有点把握不住。所以实际工作中，很多细小的规范和问题点，还是需要单独列出来的。这里整理和增补了一些，以备后用。

以下是没有整理顺序的一些规范点：

一、dao层：
1. CURD命名规范

CRUD操作

方法名约定

新增

create

添加

add

移除（逻辑删除）

remove

删除（物理删除）

delete

修改

update

查询（单个）

get

查询（多个结果）

list

分页查询

page

统计

count

搜索

select

批量

batch

存在

exist

检查

check

2. 后置限定词

例：
Total、Sum、Average、Max、Min
revenueTotal（总收入）、expenseTotal（总支出）、revenueAverage（平均收入）和 expenseAverage（平均支出）
我觉的这样做是有点面向对象的味道，例如 customerId这个命名，就有点customer.getId()的意思。
统一的命名风格，可以有效的减少很多命名有歧义的问题。使开发效率更快；

3.统一业务语言

这一条很难了，对于同一业务，产品和开发工程师的称呼可能完全不同。。
这个问题会对于当事人影响不大，但是对于后期加入的人来说，是一种灾难。。

4.统一技术语言

规范命名不需要过分注意对错，只要没有明显的错误或者歧义。则适用于团队，开发人员有统一的认知就可以。

类型

命名方式

实体类

Student

数据处理层接口

StudentDao

数据处理层接口实现类

StudentDaoImpl

业务处理层接口

StudentService

业务处理层接口实现类

StudentServiceImpl

控制层

StudentController

枚举类

StudentEnum

常量类

StudentConstant

配置类

StudentConfig

通用工具类（不限定业务）

StudentUtils

业务工具类（限定业务）

StudentTools

测试类

StudentTest

等等 … …

/

5.代码规范

名称

说明

Single Responsibility Principle（SRP）/ 单一职责原则

每个软件模块职责要单一。职责越单一，被修改的原因就越少，模块的内聚性（Cohesion）就越高，被复用的可能性就越大，也更容易被理解。

Open Close Principle（OCP）/ 开闭原则

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。对修改关闭，意味着类一旦设计完成，就可以独立完成工作，而不要对其进行任何修改 。      开闭原则个人认为非常的重要，有时候必要的重复代码和拒绝修改反而是对项目设计和扩展有更重要的意义。如果随便修改项目的设计，对后期维护是灾难性的（我就遇到过，F**k）

Liskov Substitution Principle（LSP）/ 里氏替换原则

程序中的父类型都应该可以正确地被子类型替换

Interface Segregation Principle（ISP）/ 接口隔离原则

接口隔离原则认为不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口要好。这个和第一条类似， 尽量使接口功能单一，这样减少修改，使层级和依赖变的清晰。

Dependency Inversion Principle（DIP）/ 依赖倒置原则

DIP要求高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象。程序之间的联系，应该像是标准插口一样，无论是哪个程序，只要实现了同样的插口，那就可以直接使用。依赖倒置可以提高系统的灵活性。如果类只关心它们用于支持的特定契约，而不是特定类型的组件，就可以快速而轻松地修改这些低级服务的功能，同时最大限度地降低对系统其余部分的影响。

名称

说明