一个逻辑只写一次
如果同一段业务逻辑在多个地方都有实现，那么以后迭代大概率要出问题。
需求分析的一些原则
明确收益，理清内容，设计简洁的、低耦合的架构，充分考虑异常，适当考虑扩展。
Makefile
代码仓库中应该有一个 makefile 文件，保存构建过程中需要的命令，不需要依赖文档或口口相传。
写for循环要谨慎，可能导致接口时延变高
遇到一个case，接口里要为每个对象打包额外的数据，每次打包都要调用下游接口。一次调用花费100ms，10个就是 1000ms。
优化思路有2个，一是提高并发（要考虑下游容量），二是增加缓存。在对数据的实时性要求不高的情况下，更建议后者。
怎么衡量代码的可维护性
读：变量命名、函数长度、圈复杂度。
写：单测覆盖率。
状态机
凡是涉及“状态”的模型，都应该有清晰的状态图。这样才能更清晰的定义状态边界和转换行为，防止业务迭代时，字段被滥用或者“状态”字段膨胀。
决策
有时我们需要根据一些条件进行决策。应当把整个决策流程封装成一个函数。编写单元测试覆盖每个分支。如果有不同的条件最终走向同一个结果，还应该打印过程日志，或返回具体理由，以便排查问题。
产品使用手册
平台类的产品都建议有产品手册并长期维护，否则迭代一段时间后就容易缺少全局信息，如果在人员变动比较大的情况下，功能会变得很零碎（缺失、重复、矛盾……）
产品手册可以帮助使用者了解业务背景、原理、操作方式。以免出现误操作、误反馈，后者会给运维团队带来额外压力。
另外，产品手册更偏向宏观功能，对于细节信息（用户可能更希望得到即时的解释），直接做“圆点备注”更合适些。尤其是数据口径，应该有个地方注明数据取自哪里。
offset和limit
随着offset增大，查询的复杂度会非常高，查询耗时会大幅增加。这种场景下，用 cursor（书签查询）是更好的选择。
