编写可维护代码的 5 个原则

原则一：代码是写给人看的

代码首先是给人阅读的，其次才是给机器执行的。衡量代码质量的标准不是"能不能跑"，而是"下一个读它的人需要多少时间理解它"。

原则二：好的命名胜过注释

// ❌ 需要注释解释的代码
// 检查用户是否有权限访问管理后台
if (u.r === 1 && !u.d) { ... }

// ✅ 代码自说明
if (user.isAdmin && !user.isDeleted) { ... }

命名准则：

• 函数名用动词（fetchUser, validateEmail）
• 布尔变量加 is/has/can 前缀（isLoading, hasPermission）
• 避免缩写（usr → user，btn → button）

原则三：函数只做一件事

单一职责原则（SRP）是最重要的设计原则之一。如果你发现函数名里有"和"字，或者函数超过 20 行，通常意味着它在做多件事。

原则四：拥抱删除代码的勇气

• 注释掉的代码 → 直接删除（Git 会记住它）
• 未使用的参数 → 删除
• "以防万一"的代码 → 删除

死代码是最危险的代码，因为它会引起误解，让维护者以为它有存在的必要。

原则五：一致性比"最优"更重要

团队中保持一致的代码风格，比每个人都写出"最优雅"但风格各异的代码更重要。工具优先：ESLint + Prettier + EditorConfig 自动化强制一致性。

总结

可维护性不是一次性投资，而是日积月累的习惯。每次提交前问一句："如果我六个月后看到这段代码，能快速理解它的意图吗？"