一、前言
你好，我是喵喵侠，一名前端开发。
当了这么多年程序员，我发现一个有趣的现象——写代码其实不难，难的是保持良好的编程习惯。同样的需求，有人一天写完，后续维护一地鸡毛；有人两天写完，半年后依然稳得像山。区别往往不在技术，而在习惯。今天我想分享一些我在日常工作中养成的好习惯，希望能给你一些启发。
二、好习惯分享
1. 开始写代码前，先想清楚实现思路
拿到需求时，我不会立刻打开编辑器。
我会先问自己三个问题：
- 这个功能的核心流程是什么？
- 哪些逻辑是可复用的？
- 会不会影响现有模块？
比如做一个多选筛选框功能，很多人第一反应是直接写事件绑定逻辑。但我会先想，这个功能以后会不会复用？是否可以抽象成一个组件？如果上游和下游是联动的（例如“省份”选择影响“城市”选项），那我就提前规划数据流和依赖，避免后面返工。
这种“写前先想”的习惯让我在后期重构时几乎不用推翻逻辑，只需要微调实现。
2. 代码一定要有注释，尤其是“非直观逻辑”
注释不是给别人看的，是给未来的自己看的。
我有过一次血的教训——三个月前写的逻辑，三个月后我完全看不懂。那一刻我深刻体会到注释的价值。
我一般遵循以下三条规则：
- 解释“为什么”，而不是“做了什么”。
比如下面这样写：
// 根据上一个下拉框的选项动态请求下一级数据（省市联动） watch(selectedProvince, async (val) => { cityList.value = await fetchCityList(val) })
而不是：
// 监听省份变化
因为后者虽然准确，但没有告诉未来的自己“为什么要监听”。
- 写 TODO 时加具体说明
不要只写// TODO: 优化，而要写清楚优化方向或原因。
例如：
// TODO: 这里后续要加防抖，否则快速点击会导致重复请求
- 为枚举值、接口返回做注释
比如一个 tab 切换逻辑：
// tabType: 1-实时监控，2-历史记录，3-报警日志 const tabType = ref(1)
这种注释让别人立刻明白每个数字代表什么，不用翻文档。
3. 养成规范命名的习惯
命名是最容易被忽视、但最能体现思维清晰度的细节。
我给自己的原则是：能让别人读懂逻辑，不需要解释。
例如：
const userList = ref([]) // 所有用户列表 const selectedUserIds = ref([]) // 当前勾选的用户ID
而不是：
const list = ref([]) const check = ref([])
这种命名虽然短，但完全丢失了语义。
我喜欢在写函数时也保持一致，比如：
function fetchUserDetailById(id) { ... } function validateFormBeforeSubmit() { ... }
一眼就能看出“做什么 + 针对什么”，比 getData、doCheck 清晰太多。
4. 代码 Review：及时、客观、带思考
我习惯在每次发完版本后做一次自我 review。
很多人觉得 review 是团队行为，但我认为自检同样重要。
我会浏览一遍 diff，看看有没有临时写的测试代码忘删、命名是否一致、逻辑是否能抽取为函数。
有时候我还会写上复盘注释，比如：
// REVIEW: 下次类似接口请求可以抽成 useFetch Hook
这样未来有类似功能时，我能回头看到自己的思考过程，持续改进。
5. 写文档，不是加班行为，而是沟通捷径
我遇到过最典型的场景是：别人接手我的项目，一脸茫然地问“要怎么跑起来？”
从那以后，我都会为每个项目写一个简单的 README.md，内容包括：
- 项目简介：干什么的
- 启动命令：
npm install && npm run dev - 配置项说明：环境变量、依赖 API
- 注意事项：例如接口限频、版本兼容等
我甚至会在复杂逻辑的模块里写一份简短的说明，比如：
/** * 表单验证逻辑 * 1. 用户名：不能为空 * 2. 密码：需包含大小写和数字 * 3. 手机号：正则校验，错误提示“请输入正确的手机号” */
这样的文档和注释结合，别人接手几乎不用问问题。
6. Git 提交信息要规范
Git 提交日志是团队协作的“时间线”，混乱的 commit 会让人抓狂。
我坚持用简洁的格式，比如：
feat: 新增用户信息导出功能 fix: 修复表单验证错误提示未显示的问题 refactor: 抽离通用请求封装 docs: 更新README项目说明
好处是两点：
- 看 changelog 就能知道这次版本改动范围
- 回滚或 cherry-pick 时能更精准地定位提交
如果一次提交改动太多，我会拆成多次 commit，保持单一职责，方便日后追溯。
7. 表单验证：提示语要友好
表单错误提示往往决定了一个产品的“温度”。
比如，不要写：
“手机号格式错误”
而是写：
“请输入正确的手机号（11 位数字）”
甚至可以加点贴心提示：
“请输入常用手机号，用于接收验证短信”
这种细节能提升用户体验，也让前端代码更贴近“产品思维”。
8. 删除无用代码，而不是注释掉
我以前常常把旧逻辑注释起来“以防万一”，结果两个月后我根本不敢动那坨注释。
现在我改成直接删掉，如果真的怕丢，就让 Git 帮我记着。
版本控制的意义就是——敢删敢改，无需保留尸体代码。
三、总结
编程不只是逻辑堆叠，更是一种思维的训练。
良好的习惯能让代码更干净、项目更稳、团队更默契。
我的习惯也在不断演化，但有一点始终没变：
写出自己半年后依然能读懂的代码。
如果你正在写代码，不妨问问自己：
“半年后的我，看得懂现在这段逻辑吗？”
——如果答案是肯定的，那你已经在走向成熟的开发者之路。
