封面
作者
杨冠宝
形式
电子书
工具
PC
出版社
电子工业出版社
国家
中国
类型
技术
状态
阅毕
当前进度
63
总计
63
已读
1
阅读进度
NaN%
评分
⭐⭐⭐
创建时间
Aug 8, 2021 06:56 AM
阅读时间
Aug 8, 2021
因为日常编码、大作业的开发不要求什么规范，自己也不大注意，希望通过阅读此书能够帮助自己养成良好的编码习惯
读书笔记
一、编程规约
- 辨识鲜明，快速理解
将设计模式体现在模块、接口、类、方法等命名中，有利于阅读者快速理解架构设计理念。
- 常量按常量的功能进行分类，分开维护，注意常量的复用层次：
常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
- 方法不超过80行
- 简洁性
- 红花和绿叶的区分
- 注意不使用过时的类或方法
- 构造方法里面禁止加入任何业务逻辑，如有初始化劣迹，需要放在init方法中
- 多个构造方法或同名方法，按顺序放在一起，便于阅读
- 类内方法定义的顺序：公有方法或保护方法>私有方法>getter/setter方法
- 合理利用数据结构，eg：set的唯一性、map、集合的有序性和稳定性
- 保证线程安全，线程资源必须通过线程池提供，不得自行显式创建线程
- 更加明确线程池的运行规则，规避资源耗尽的风险
- 高并发时，同步调用应该考量锁的性能损耗。尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法
- 注意代码规范，if/else/for/while/do语句中必须使用大括号
- 尽可能提高可读写性，不要在条件判断中执行其他复杂的语句，可以将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
- 避免采用取反逻辑运算符
- 注释规约需要使用Javadoc规范，包括返回值、参数、异常说明、做什么事、实现什么功能
- 所有的类都必须添加创建者和创建日期
- 代码进行修改的同时，需要更新注释的修改
- 注释掉代码需要在上方详细说明
- 语义清晰的代码不需要额外的注释
- 统一的重要性：格式、各类部件的属性、请求、消息设定等
- 任何数据结构的构造或初始化都应指定大小、避免数据结构无限增长吃光内存
- 及时清理不在使用的代码段或配置信息
二、异常日志
- 错误码的制定原则：快速溯源、沟通标准化
- 错误码格式规定，编号永久固定
- 捕获异常：
- catch的时分清稳定代码和非稳定代码
- 捕获的异常必须进行处理
- 尽可能进行区分异常类型
- 应用值不可直接使用日志系统中的API，而应依赖使用日志框架中的API
- 日志命名规定
- 谨慎地记录日志：
- 生产环境禁止输出debug日志；
- 有选择地输出info日志；
- 如果使用warn来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。
三、单元测试
- 好的单元测试必须遵守AIR原则
- A：Automatic（自动化）
- I：Independent（独立性）
- R：Repeatable（可重复）
- 单元测试需要保证测试粒度足够小，有助于精确定位问题
- 编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量。
- B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
- C：Correct，正确的输入，并得到预期的结果。
- D：Design，与设计文档相结合，来编写单元测试。
- E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。
- 多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。
四、安全规约
- 隶属于用户个人的页面或者功能必须进行权限控制校验。
- 用户敏感数据禁止直接展示，必须对展示数据进行脱敏。
- 表单、AJAX提交必须执行CSRF安全验证。
五、MySQL数据库
- 表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。
- 表名不使用复数名词。
- 表的命名最好是遵循“业务名称_表的作用
- 单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
- 表必备三字段：id, create_time, update_time
- 不得使用外键与级联，一切外键概念必须在应用层解决。[外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度]
- 因国际化需要，所有的字符存储与表示，均采用utf8字符集
- 在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。
六、工程结构
- 分层模型规约
- DO（Data Object）此对象与数据库表结构一一对应，通过DAO层向上传输数据源对象。
- DTO（Data Transfer Object）数据传输对象，Service或Manager向外传输的对象。
- BO（Business Object）业务对象，可以由Service层输出的封装业务逻辑的对象。
- Query 数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。
- VO（View Object）显示层对象，通常是Web向模板渲染引擎层传输的对象。
- 为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则：
- 精简可控原则
- 稳定可追溯原则
七、设计规约
- 存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。
- 类在设计与实现时要符合单一原则。
- 系统设计阶段，注意对扩展开放，对修改闭合。
- 系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，在系统中不出现重复代码的情况，即DRY原则（Don't Repeat Yourself）。
- 设计的本质就是识别和表达系统难点。