混乱代码的代价
难以维护,降低生产力,增加系统错误风险,最后导致无法运行。
一. 有意义的命名
-
名副其实
-
避免误导
-
做有意义的区分
-
名称能读出来
-
避免使用编码
-
使用解决方案领域名称
-
添加有意义的语境
-
描述技巧和共有文化背景
二. 函数
-
短小
-
只做一件事(SRP)
-
每个函数一个抽象层级
-
使用描述性名称
-
函数参数尽量少和使用动词与关键字
-
函数不应该有副作用
-
分割查询和指令
-
使用异常代替错误码
-
消除重复
-
错误处理就是一件事
三. 注释
-
注释不能美化糟糕的代码
-
用代码来阐述注释
-
好的注释
-
法律信息
-
提供信息的注释
-
对意图的注释(返回值)
-
阐释
-
警示
-
TODO注释
-
放大
-
公共api的java
-
四. 格式
垂直格式
-
横向格式
-
团队规则统一
五. 对象和数据结构
-
数据抽象(隐藏实现,暴露抽象接口,无需了解数据本体)
-
数据、对象的反对称性(过程式编程还是多态式实现)
-
得墨忒耳律(隐藏数据,暴露操作)
六.错误处理
-
使用异常而非使用错误码
-
调用者定义异常类
-
别返回 nul值
-
别传递null值
七.边界
-
封装隔离来自第三方的api
-
使用适配器模式隔离尚不存在的api
八.单元测试
-
保持测试整洁
-
整洁的测试
-
每个测试一个断言
-
快速、独立、可重复、及时
九.类
-
类应该短小(SRP、内聚)
-
为了修改而组织(隔离修改)
十. 系统
-
系统的构造和使用分开(工厂、依赖注入)
-
扩容(迭代增量敏捷,横贯式关注面AOP)
-
代理
-
延迟决策
十一. 简单设计
-
运行所有测试
-
不可重复
-
表达意图
-
减少类和函数