读《代码整洁之道》：命名是最便宜的重构
这本书被讨论得太多，很多人第一次读会觉得「都是常识」。但常识之所以是常识，是因为它反复被验证有效。
这次重读，最有感觉的是第二章：有意义的命名。
一个改名的例子
项目里有这么一段：
const d = new Date();
const t = d.getTime() - u.t;
if (t > 86400000) { ... }改成：
const DAY_IN_MS = 24 * 60 * 60 * 1000;
const age = Date.now() - user.lastActiveAt;
if (age > DAY_IN_MS) { ... }逻辑完全没变，但第二版你不需要在脑子里做单位换算，也不需要猜 u 是什么。
改名字不改变任何行为，却能降低理解成本——这是投入产出比最高的一种重构。
「想不出好名字」是个信号
书里有一句话我印象很深：
如果你为了给一个函数取名字而绞尽脑汁，那说明这个函数做的事情太多了。
这条规律这几年验证过很多次。当一个方法怎么命名都觉得别扭时，拆开之后往往一两分钟就取好了名字。它不是命名的困难，而是设计的困难。
三个具体的命名习惯
- 动词开头表示行为，名词表示数据。
fetchOrders()和orders，不要让它们混在一起。 - 不要在名字里编码类型。
strName、arrList是上个时代的产物，类型系统会告诉你。 - 长度和生存期成正比。循环里的
i没问题，模块级的变量必须起全名。
一点反对意见
书里主张「不要写注释，用代码表达意图」。我觉得这话对了一半。
代码能表达 做了什么，但表达不了 为什么这么做。那些「这里必须加 500ms 延迟，否则老设备会丢包」的注释，删掉之后接手的人会重新踩一次坑。
好的注释记录的是决策的上下文，而不是代码的翻译。
所以我的做法是：能改名字说清楚的就改名，说不清楚的，老老实实写注释，并且写清楚「为什么」而不是「是什么」。
小结
这本书最实用的部分不是那些设计模式，而是它对日常习惯的提醒。命名、函数长度、注释——这些东西每天都在写，稍微认真一点，收益是复利的。