十条良好的编码原则：从安全到重构的一张图

软件工程里有很多「清单」和「口诀」，真正难的不是背下来，而是在写每一行时知道该用哪一条。下面这张图（来自 ByteByteGo 的信息图思路）把十件事摆成一轮：从安全与规范，到可测与可演进，适合当作日常 code review 或自己写代码时的自检表。

1. 安全（Security Assurance）

代码首先要不帮攻击者做事：防 SQL 注入（参数化查询、别拼字符串）、防 XSS（输出编码、CSP）、防敏感数据外泄（密钥不进仓库、最小权限、传输与存储加密）。安全不是上线前加一层，而是从接口设计、数据边界就默认「不可信」。

2. 代码规范（Code Specification）

同一套风格（缩进、命名、导入顺序）让 diff 更小、评审更快。语言层有成熟约定就跟随（例如 Python 的 PEP 8、Java 常见团队会参考 Google Java Style Guide），再用格式化工具与静态检查固化，避免「每个人一种写法」。

3. 文档与注释（Documents and Annotations）

注释优先写为什么这样设计、曾踩过哪些坑，而不是把代码用中文复读一遍。对外 API、复杂算法、非常规权衡，用简短文档或 ADR 记下来，并随代码一起更新，否则文档会变成误导。

4. 健壮性（Robustness）

系统在运行时会遇到：错误输入、磁盘/网络故障、恶意请求、流量过载。健壮性不是「永不报错」，而是错误可预期、可观测、可恢复：校验输入、超时与重试、熔断降级、清晰错误码与日志，避免静默失败。

5. SOLID

面向对象设计里常用的五条：单一职责、开闭、里氏替换、接口隔离、依赖倒置。它们共同指向一件事：模块边界清晰、依赖方向可控，改一处不必牵一片。不必教条化到每个类都拆五个文件，但在「开始变乱」时，用 SOLID 当重构方向往往划算。

6. 易于测试（Easy to Test）

可测的代码通常副作用少、依赖可注入、单元粒度合适。目标是：自动化测试成本低、跑得快、失败时能定位到具体行为。若测试必须起整站、连真实数据库才能跑，往往说明边界与抽象需要再收一收。

7. 适度抽象（Moderate Abstraction）

没有抽象时代码冗长难维护；抽象过度时概念满天飞、跳转太多也难懂。好的抽象是刚好包住变化点：把稳定的核心逻辑抽清楚，用公开接口表达意图，其余留给实现细节，避免为「优雅」而层叠。

8. 设计模式（Design Patterns）

模式是常见问题的可复用方案：创建型（如工厂、单例）、结构型（如适配器）、行为型（如策略、代理）。先理解问题是否匹配，再套用，而不是为了「用模式」而引入复杂度。

9. 减少全局依赖（Reduce Global Dependencies）

全局可变状态会让调用链难以推理，测试与并发都更痛。尽量把数据通过参数、返回值、显式上下文传递；若必须用单例或全局配置，也要缩小写入面、声明生命周期，避免「谁都能改」的隐式耦合。

10. 持续重构（Continuous Refactoring）

重构是在不改变行为的前提下改进结构：命名、拆分、消除重复、理顺依赖。它和「加功能」可以交替做；小步提交、有测试兜底，比攒一大坨再改安全得多。图里用「进化」来比喻很贴切：代码是活的，设计是迭代出来的。

小结

这十条不是「一次做完」的 checklist，而是在不同阶段反复出现的维度：写新功能时想安全与规范；抽模块时想 SOLID 与抽象；修 bug 时想健壮性与可测；维护旧代码时想全局依赖与重构。把这张图放在手边，比背定义更有用。