控制代码质量减少混乱

代码质量控制

严格规范代码质量. 代码质量分为两块, 一块是代码的结构, 另一块是代码的运行效率. 普通的项目关键组件才着重代码的运行效率优化. 对一般的组件主要的要求就是代码的结构. 这里对之前的经验做个总结, 如何写出高质量的代码.

第一步: 理解项目的结构体系. 写某个服务之前, 先理清服务涉及的表结构和表关系. 在开始阶段就减少大规模修改代码的可能.

第二步: (项目已搭好)先从最底层的service接口开始.

- 方法和参数的命名规范:

1. 方法中明确说明动作和主体, 如updatePermission()

2. 不写非通用的单词简写. 如permission, 不写成per. 至少写成perm, 并且做好注释. perm: permission, 权限

3. 参数命名简短, 如accountService的findAllWithRoles. find后面不写对象类型,就默认为account.

4. 类似rolePermissionService这样的service, 在命名方法的时候全部加上对象类型.不能出现findList这样的方法. findListWithPermission这样的方法名, 虽然能知道查的是role, 但还是尽可能不要出现.

5. 一个方法中有多个对象, 都要用到id属性, id参数除@PathVariable以外, 全部加上对象类型.

7. 关于's'.

a. 类名一律不加s, 所有的findAllPermission类型的方法名称一律不加s. 除个别情况以外, 全部使用对应的名词.

b. 参数中尽量使用List代替s. 个别情况如: ids ,这种简单并且较常见的可以使用s. 尤其是数组类型. 非数组慎用.

6. 返回的结果集与接收的参数名: List -> ***List, Map -> ***Map, Set -> ***Set. 其中List不使用加类型 + s的表示方式. 如permissions. 不容易看见, 且某些以单词s/se结尾的很不合适. 连发音都是个大问题.

7. 单词尽量选择简单, 常见的. 但不能以牺牲描述的准确性为代价.

8. 英语单词描述准确. 名词, 形容词, 形容词做定语, 形容词做表语等待要分清. 不会的使用百度/谷歌/有道翻译. 起个好名事半功倍. 相反就容易出问题.

 

- 写好方法的注释, 既要描述准确详细, 又要充分简洁.

1. 所有参数有写上注释. 一眼就看出来的尽可能写的简单.

2. 准确的描述方法针对/操作的对象.

3. 准确的描述方法的返回值.

4. 复杂的内容: 分层次, 写清楚操作步骤, 传递的参数(值, 类型, 可能的值), 可能的结果.

5. 写service方法以及注释前, 最好多想一会方法中需要哪些参数, 方法的执行过程. 尽量避免serviceImpl的修改. 否则还有回来修改service的注释. 关键点是CRUD需要什么样的参数, 还要考虑表的关联关系

 

第三步: serviceImpl和API(Controller)

1. 一次查询不要返回过多数据, 最好使用分页查询. 如果一次查询结果有十万条, 可能会引发内存溢出.

2. List / Map集合中有对对象的引用, 使用完后要清空. 避免内存溢出

3. 日志记录查询出的结果数量

4. 返回对象时, 只返回需要的属性, 而不是返回整个对象. 做法是新建一个Vo, 封装需要的属性, 返回给前端

5. 在查询数据库时, 可以只返回一个DTO, 只包含必须的数据, 封装一个Vo传给前端

6. 使用Bo封装若干Po处理数据