一套能落地的“干净代码”习惯：不用学架构也能用

很多人一听"干净代码"，就想到设计模式、架构分层、DDD。然后直接放弃：太复杂，不适合我。

先说结论：你不需要懂架构，也能写出80%干净的代码。

靠的不是理论，而是四个最基础的习惯：命名、注释、函数、结构。

一、先破：新手最常见的四个误区

1. 名字随便起，反正能用
data、list、res到处都是，看代码像在猜谜。

2. 注释越多越好

写了一堆"翻译式注释"，但代码一改，注释全错。

3. 函数越短越高级

拆到一行一个函数，读起来反而更碎。

4. 文件越分层越专业

搞一堆目录结构，但逻辑找不到。

一句话总结：

👉 不是写得"多复杂"，而是让别人"看得懂"。

二、立：用工程化四指标建立最小规则

不讲哲学，直接落地。

1. 交付：别人能不能接手你的代码？

变量命名规则

用"业务词"，不用"抽象词"
userList 比 dataList 更好
isLoading 比 flag 更好

👉 名字要回答：这是什么？

函数命名规则

动词 + 名词
getUserInfo()、calculateTotal()

👉 名字要回答：它做什么？

一句话总结：

👉 读变量像读句子，而不是解谜题。

2. 可控：改代码会不会牵一发动全身？

函数拆分规则（极简版）

一个函数只做一件事，但不要过度拆。

坏例子：

scss 复制代码

handle()

好例子：

scss 复制代码

validateInput()
createOrder()
sendNotification()

但别变成：

scss 复制代码

getName()
getAge()
getAddress()

👉 粒度标准：一眼能看懂逻辑流程

一句话总结：

👉 函数不是越小越好，是"刚好能读懂"。

3. 可复现：别人能不能快速定位问题？

注释规则（反直觉）

不要写"代码翻译"，写"为什么这么写"。

坏注释：

css 复制代码

// 遍历数组
for (let i = 0; i < list.length; i++)

好注释：

perl 复制代码

// 这里不能用 map，因为需要中途 break

👉 注释解决：代码看不出来的决策

一句话总结：

👉 注释不是解释代码，是解释"选择"。

4. 成本：写和改的代价高不高？

文件结构规则（极简）

不要一开始就分层，先按"功能聚合"。

坏结构：

复制代码

utils/
services/
controllers/

好结构：

css 复制代码

order/
  createOrder.js
  validateOrder.js
  orderService.js

👉 把"相关代码放一起"，而不是按技术分。

一句话总结：

👉 先按业务组织，再谈架构。

三、四条核心习惯，一次讲透

1. 变量命名：别偷懒

核心原则：少用缩写，多用语义

scss 复制代码

// ❌
let d = getData()

// ✅
let userList = getUserList()

如果你需要注释来解释变量名，那说明名字起错了。

2. 注释：写少一点，但写关键点

只在这三种情况写：

非直觉逻辑
性能权衡
业务规则

其他情况，让代码自己说话。

3. 函数拆分：先写清楚，再拆

顺序是：

先写一个能跑的函数
找出"逻辑块"
再拆

不要一开始就设计函数结构。

4. 文件结构：别过度设计

原则很简单：

👉 "一起改的代码，放一起"

如果两个文件总是一起改，那它们就该在同一个目录。

四、快速测评清单（自己验证，不靠感觉）

1. 命名是否清晰？

不看实现，只看变量名
能否猜出作用

2. 函数是否易读？

一屏能看完
是否需要来回跳转

3. 注释是否有价值？

删除注释，是否更清晰？
注释是否解释"为什么"？

4. 文件结构是否合理？

找一个功能，需要打开几个目录？
修改一个功能，需要改几个文件？

5. 是否容易改？

改一个逻辑，会不会影响其他地方？

6. 是否容易查问题？

出 bug 时，能否快速定位文件？

五、收个底

"干净代码"不是风格问题，是沟通问题。

你写的不是给机器看的，是给人看的。

未来的你，也是"别人"。

记住这四件事就够了：

命名：说人话
注释：讲原因
函数：刚好清晰
结构：按业务放

不用学架构，也能写出不让人骂的代码。

当你能稳定做到这一步，再谈高级设计，才有意义。