接手别人的项目时，最怕打开代码看到这样的景象：命名一会儿拼音一会儿英文，一个函数三百行，同一个功能在五个文件里各写了一遍。改一个字要全局搜索，改完还不确定有没有漏。
代码规范听起来像形式主义，但它直接决定了这个项目能活多久。
命名是第一位的
好名字能让代码自解释。几条简单的约定：
- 统一语言：要么全英文，不要混着拼音缩写
- 变量用名词，函数用动词开头：
getProductList一看就知道是干什么的 - 布尔值加判断前缀：
isActive、hasStock - 常量全大写：
MAX_UPLOAD_SIZE - 别怕长：
filterProductsByCategory比fp好一百倍
目录结构要一眼看懂
按功能分还是按类型分，选一种坚持到底。常见的前端结构：
src/components/ 组件pages/ 页面utils/ 工具函数services/ 接口请求styles/ 样式assets/ 图片字体关键原则是相关的东西放在一起。某个业务模块改起来，不用在十个目录之间跳来跳去。
函数要短，职责要单一
一个函数超过五十行就该警惕了。判断标准很简单：你能不能用一句话说清这个函数是做什么的。如果说的时候要加"并且""然后"，那它该拆了。
重复代码超过两次就抽出来。复制粘贴一时爽，改需求时要改五处，漏一处就是 bug。
注释写为什么，不写做了什么
// 不好：把 i 加 1i++;// 好：兼容旧浏览器不支持的新接口，做降级处理if (!window.IntersectionObserver) { ... }代码本身已经说明了"做了什么"，注释的价值在于解释为什么这么做，尤其是那些看起来奇怪但有其原因的写法。
用工具代替人工检查
靠自觉执行规范是不现实的，用工具自动卡：
- 代码格式化工具：保存时自动格式化，缩进和引号这类问题根本不用讨论
- 静态检查工具：未使用变量、潜在错误、可疑写法，编辑器里直接提示
- 提交前钩子：代码不达标就不让提交
- 编辑器配置统一：把缩进、换行符这些约定写进项目配置文件
工具的最大好处是把"风格之争"变成"配置之争"，团队不用再为两个空格还是四个空格吵架。
文档写三份就够
不需要几十页文档，写清楚这三件事：
- 怎么跑起来：环境要求、安装依赖、启动命令，新人照着做半小时能跑起来
- 怎么部署：步骤、涉及的服务器和账号、回滚方法
- 有哪些坑：特殊配置、历史遗留问题、不能碰的地方
别追求一步到位
已有项目不要试图一次性重构到位。原则是"碰哪改哪"：改到某个文件时顺手把它整理干净，不相关的先不动。半年下来，代码质量会自然改善，风险也可控。
代码是写给人看的，顺便让机器执行。三年后维护它的可能是别人，也可能是忘了这件事的你自己。
—— 一位常年接手遗留项目的开发者