重读《程序员修炼之道》：那些工作五年后才真正读懂的道理

书架上有一本翻得卷了边的《程序员修炼之道》，是刚毕业那年买的。当时一口气读完，觉得写得都对，但也仅限于"都对"——就像听长辈讲人生经验，道理都懂，但没什么体感。

最近整理书架又翻到它，随便打开一页读了几行，突然就愣住了。原来当年那些觉得"正确的废话"，现在每一条都能对应上一段踩坑的经历。

"不要重复你自己"不是一句口号

书里说DRY原则——Don't Repeat Yourself。刚工作的时候觉得这还不简单，不就是把重复的代码抽成函数嘛。

直到有一次，系统里有三个地方都写了用户权限校验的逻辑，长得差不多但又不完全一样。产品说要改权限规则，我改了两处，漏了一处。线上出了问题，查了半天才找到那个被遗忘的角落。

后来才明白，DRY不只是代码层面的"不要复制粘贴"，更是知识的单一来源。一个业务规则，应该只在一个地方定义，其他地方都调用它。否则改的时候必然漏，漏了必然出bug，出了bug必然背锅。

书里花了不少篇幅讲正交性——改变一个东西不影响其他东西。当年觉得这是讲架构的，离我太远。

真正理解是在一次需求变更之后。那个需求是改一个展示字段，按理说改一个地方就行，结果牵一发动全身，改了前端改后端，改了后端改数据库，最后还影响了三个不相关的功能。

原因就是模块之间耦合得一塌糊涂，A模块直接读B模块的内部变量，B模块又偷偷改C模块的状态。改一个地方，不知道会炸哪里。

从那以后，写代码之前会先想：这个改动会不会影响其他地方？如果会，是不是设计有问题？

书里说做项目要像曳光弹一样，先打一发看看偏哪里，再调整。而不是坐在屋里算好所有参数，等一切完美了再开火。

刚工作的时候喜欢"完美设计"，一个功能要在脑子里想清楚所有边界情况才动手。结果想了一周，写出来的东西还是有考虑不周的地方，而且因为想太久，交付时间也紧了。

现在的做法是：先搞一个能跑的最小版本，看看实际效果，再迭代。很多问题坐在屋里是想不出来的，只有跑起来才知道哪里不对。

当然，这不是说不做设计。而是先做"刚好够用"的设计，剩下的在迭代中完善。

书里讲怎么做时间估算，说要把任务拆小、要留缓冲、要记录实际耗时和估算的偏差。当年觉得估算不就是拍脑袋嘛。

工作后才发现，估算是程序员的核心技能之一。估短了，加班加点还交不出来；估长了，老板觉得你效率低。

我现在的做法是：先拆任务，拆到每个子任务不超过半天；然后每个任务乘以1.5的缓冲系数；最后记录实际耗时，下次调整系数。

练了两年，估算准确率从最初的不到50%，到现在能做到80%左右。这不是天赋，是练出来的。

有人说经典的书要反复读，不同阶段会有不同的体会。以前不信，现在信了。

同一本书，二十岁读和三十岁读，看到的是完全不同的东西。不是书变了，是你变了。你经历的事情越多，书里的话就越能和你的经验产生共鸣。

这本《程序员修炼之道》，我打算每隔两三年再读一遍。看看下一次读的时候，又会有哪些新的体会。

毕竟，程序员这条路，修炼是一辈子的事。