原来我之前写的不是代码，是"技术债务"啊！
刚翻开《代码整洁之道》第一章，就被一句话扎心了："糟糕的代码每年都要耗费难以计数的时间和资源"。突然想起上周为了改一个旧功能，在两千行的"祖传代码"里扒了整整一天——这不就是作者说的"泥足深陷"吗？
代码这东西，扔不掉的
作者说"代码永存"，一开始我还不服。现在想想，确实如此。哪怕用再高级的框架，最后落地到机器上还是得靠代码。那些觉得"以后代码会自动生成"的想法，就像觉得"以后数学会自己算答案"一样天真。需求的细节总得有人明确下来，而代码就是这种明确的载体。
想起之前做过的一个项目，产品经理说"这个逻辑很简单"，结果我们写了三个月。现在才明白：模糊的需求配不上整洁的代码，而混乱的代码只会让需求更模糊。
混乱的代价，比你想的更痛
书中举了个公司因为代码太烂关门的例子，我倒没经历过这么极端的，但见过团队因为代码混乱导致的"死亡螺旋"：
- 一开始为了赶进度，写得乱七八糟
- 然后改一个功能要改三处，还总出BUG
- 接着团队士气低落，新人来了更懵
- 最后只能宣布重写，之前的时间全白费
这不就是作者说的"生产力趋向于零"吗？最可怕的是，很多团队明明陷进去了，还安慰自己"先跑起来再说"。但勒布朗法则说得对："稍后等于永不"，混乱只会滚雪球。
什么是整洁代码？大佬们的答案很统一
看了好几个编程大牛对整洁代码的定义，总结下来就几点：
- 像Bjarne说的，要"优雅高效"，逻辑直截了当，缺陷藏不住
- 像Grady说的，要"像优美的散文"，读起来流畅自然
- 像Dave说的，要"能被别人看懂并修改"，还得有测试
- 最戳我的是Michael的话："看起来像是有人特别在意它"
突然想起自己写的代码，注释里全是"这里要注意"，这不就是承认自己写得烂吗？真正的整洁代码，应该让别人读起来觉得"就该这么写"。
程序员的"童子军军规"
作者推荐的"离开时比发现时更整洁"太有画面感了。以前总觉得"这点混乱不算啥"，现在想想：每次签入代码时，顺手把变量名改对、把多余的注释删掉，其实花不了一分钟。
上周改BUG时，顺手把一个300行的函数拆成了5个小函数。这周同事说"这段代码挺好懂"，突然有点成就感——原来整洁代码也是可以传染的。
最后碎碎念
第一章最让我反思的是：把代码写烂，本质上是一种不专业的表现。就像医生不会因为忙就不洗手，程序员也不该因为赶进度就放弃代码质量。
接下来打算试试作者的建议：每次写代码时，多问自己"这东西别人能看懂吗？"。毕竟，我们写的不只是代码，还是给未来自己和同事的"说明书"啊。
（下一章要讲命名了，突然有点慌——我那些a、b、temp变量，怕是要中枪了）
