- 保持对代码细节的偏执观念
- 控制系统的熵增
- 编写自动化测试
- 尽早测试
- 项目中统一术语
- 不 要面向需求编程,应当面向业务模型编程
- 软件工程 = 科学 + 艺术
- 我们可以使用框架，但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它进入内圈。 ——《整洁架构之道》
- 解耦 插件化
- 如果有一些参数是可变的，我们应该使用配置，而不是把参数写死在代码里 新时代的两个道理：（1）配置即隐性耦合。配合和相隔十万八千里的代码产生了耦合。 （2）代码有很强的自解释能力，工程师们更愿意阅读可读性强的代码，而不是编写得很烂的配置文档。
- 封装不一定是好的组织形式,不要过度封装
- 当自己代码可能会给别人带来困扰的地方,应该显式去处理
- 合理注释一些并不”通俗“的逻辑和数值（神秘字符串）
- 代办的事项要用TODO标识出来，极有可能就是你自己接着开发
- 要把错误（error/Exception）包装一下返回上层，而不是直接抛弃
- 历史有问题的代码, 发现了问题要及时 push 相关人主动解决
- 如果打了错误日志，有效信息必须充足，且不过多。讲不清楚的日志等于没有
- MR 要自己先 review, 不要浪费 reviewer 的时间
- 空实现需要注明空实现就是实现。
- 不要出现特定 IP，或者把什么可变的东西写死
开发习惯
· 阅读需 3 分钟