【藏经阁一起读(40)】读《Java应用提速(速度与激情)》,你有哪些心得?
一、编程规约 辨识鲜明,快速理解 将设计模式体现在模块、接口、类、方法等命名中,有利于阅读者快速理解架构设计理念。 常量按常量的功能进行分类,分开维护,注意常量的复用层次: 常量的复用层次有五层:跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。 方法不超过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)。 设计的本质就是识别和表达系统难点。
赞0
踩0