1. 你觉得一个模块很复杂吗？那就拆分吧，拆到每个部分都比较简单为止！ 模块功能划分明确吗？ 性能要求考虑了吗？ 模块间的接口定义准确无误吗？ 同一段代码多个地方用到吗？必须复用它！ 有暴露问题 & 自身监控的能力吗？ 模块设计 有可能会扩展、变化吗？那就抽象接口，实现独立，以不变应万变。

2. 输入校验 明确 提示 检测 合适 控件 使用合适的文本 / 数值编辑、下拉框、单 / 复选等控件吗？ 对所有用户输入必须要检测：文本 or 数字？长度？范围？ 输入不合理时，给出的提示信息简单明确吗？

3. 异常处理 一个普通异常没处理会导致整个系统崩溃知道吗？ 所有异常都是可控并处理了吗？ 不合理的异常都通过界面或日志明确无误的提示了吗？ 异常是该谁处理？ 要非常重视异常，不要忽略任何一个异常！ 所有的异常发生的场景必须是你非常清楚的。 所有异常的处理逻辑必须是有效的。 界面的异常要简单明确的告知用户。 后台的异常要记录日志，详细记录异常时的上下文。 不该处理的异常不处理，绝对禁止捕获而不做任何处理。 该你处理的异常必须要处理。

4. 珍贵资源合理使用 数据库连接、 MQ 连接、 SOCKET 连接、文件句柄都是珍贵资源 偶尔使用请用短连接； 频繁使用请用长连接； 对于长连接，需要监测断开； 断开后需要重连； 重连次数和时间间隔要合理； 使用后都要正常的关闭。 需要长连接吗？ 有断开检测和重连吗？ 都正常关闭了吗？

5. 日志 关键操作和流程要记录日志，便于核查程序逻辑； 主要的异常要记录日志，便于及时详细的了解故障； 关键的数据要记录日志，便于数据核查； 记录 清晰 大小 读写 日志最终要帮助你快速发现和定位问题，特别是已知问题！ 日志文件内容格式要统一、清晰； 要适当分类，不要鱼龙混杂 ； 日志要有明确的时间和级别 ； 日志比较多的 要规划日志目录结构 ； 杜绝频繁的打开关闭文件； 考虑一定的缓存，不要对主体功能造成性能影响； 不能因为日志读写而带来新的异常； 要适当规划日志的大小，最大不超过 200M ； 要考虑日志是循环写还是备份的方式 ； 必须设计日志的备份、清理机制 ；