系统之内：
请求重试一定要保证传入的和重试不相关的变量不被修改。
程序=指令+数据=文件
对后期更新频率要有一个预估，进行模块化处理。
对数据结构有修改时要考虑历史数据的处理。
动态生成之前添加清除代码。
查询和操作的权限分开。
和时间判断相关的逻辑，要考虑时间推移的状态。
注意对时间的赋值，是使用utc时间还是local时间
变量作用域，代码块执行顺序。
方法注释有无时间和开发者名称。
文件夹结构规范和命名规范，类命名规范。
逻辑判断使用的值是否合理（如果要使用常量判断，则必须使用不可变的值）。
取字段值时，能使用api的要优先使用api。
增删改查要作为一个整体考虑，注意 改查 的配合。
查多示少（对扩展性需求的考虑），删更必先查（保证记录存在）。//需要学习更有效应对高并发的内容
parse的字段必须先做正则验证，或者约定必须为某类型。
注意使用select distinct 列名 from 表名。
登录和非登录状态下的测试，不同角色的测试。
空与非空的测试。
token有无的测试。
网络通与不通情况下的测试。
网络断联等情况的测试。
输入值长度的限定。
代码注释。
try-catch范围。
日志打印。
新增代码的时点是否在上下文准备好的位置。
要把代码写清晰，就要保证“语义与细节分离”，即将“做什么”(dowhat) 与 “怎么做”(howtodo)分离开。在主流程里，坚持只叙述 dowhat ，只在函数或方法里写清楚 howtodo 。
遵循软件质量指标：
完全性：功能要求的全面实现程度；（功能测试）
可跟踪性：记录软件执行状况以及执行过程中出现的全部时间的程度；（日志）
精确性：为计算、处理输出提供的精确度；（api了解）
容错性：在非规定条件下继续运行的能力；（防呆，常规输入限制）
兼容性：两个或两个以上系统交换信息的能力；
可操作性：软件使用操作的’容易程度；（遵循大多数软件规范）
简明性：以最容易理解的方式实现规定的功能；
模块性：模块化结构程度；（提前设计）
可扩充性：需求和功能的扩展能力；（提前设计）
自检性：软件监察自身运行状况和发现自身错误的能力；（编写自监控代码）
系统独立性：对软硬件系统的依赖程度。
系统之间：
功能模块划分 与 代码架构设计 与 服务器架构设计要一致。一定要考虑到模块之间的交互。
系统之间交互盒结构是否统一。
耗时操作放置的位置最好在调用接口端，防止调用超时。
远程调用成功与失败双重方向的考虑。
要考虑服务器可能挂掉的情况。
方法：
原设计如果做不到的话要给出替代方案，而不是单纯否定。
部署之前把测试使用的内容都注释掉或删掉。
选择供应商合作伙伴时，要先看他们的过程文档，过程质量的管控。
