命名
- 描述意图,而非细节
- 用业务语言写代码
- 类名:名词,表示一个对象
- 方法名:动词或者动宾短语,表示一个动作
- 和业务方共同确定一个词汇表,包含业务术语的中英文表达
- 编写符合英语语法规则的代码
好代码
- 不要复制粘贴。提取函数,在需要的地方调用这个函数。
- 能够发现重复
- 类似含义的代码应该有一致的名字
- 不一致的名字表示不同的含义
- 把类写小,越小越好
- 把函数写短,越短越好
- 按职责拆分不同的大类
- 消除长参数列表,将参数列表封装成对象
- controller层承载一些校验和对象转换的角色,而service层的参数是不需要关心这些的
- controller层请求对象的字段主要是基本类型,而service的参数对象,需要全部转换为业务对象
- 业务代码中任何与业务无关的东西都是潜在的坏味道
- 可能为null的返回值返回optional,以此减少犯错的几率
- 不断学习新的代码风格,不断改善自己的代码
- 尽可能多暴露问题,尽可能多做代码评审,每天评审一次
- 异常情况要考虑充分
- 对新增接口保持谨慎,对外提供的接口越少越好
- 从业务上判断需要新增还是复用
- ”I“打头给接口命名,用”Impl“给实现类结尾是不好的编程习惯
- 一个接口只有一个实现类,可以不需要这个层次关系,命名可以是DefaultXXX;一个接口有多个实现类,需要把不同实现类的特点描述出来,如FileXXX,DbXXX等等
- 尽量规避全局函数和全局变量;尽量不用static函数;尽可能不用单例模式
- 好的程序员要学会表达,不仅仅用代码表达,也要会用文字表达
模型
- 出现技术名词(如kafka),往往缺失了一个应有的模型
- 识别一个东西是业务的一部分,还是一个替换的实现,如果不是它,是否还有其它的选择?
- 模型封装以行为为基础
- 典型的动数据(变化)和静数据(无变化)是不同的关注点,应该分离开来
- 变化频率相同,则封装成一个类
- 少暴漏细节
- 尽量使用final,限制变量的赋值
- 对象一次性完成初始化,guava的集合工具类
- setter只在初始化过程中用到,可以用更完整的构造函数替换掉它