代码质量像熵一样自然趋于混乱：环境和团队的持续变化是根本原因

一个容易让人沮丧的现实是：即使花了很大力气把一个工程重构得质量飞跃，也不代表这份成果能够长久维持——某天不经意间发现某个类又悄悄长到了几千行，翻查提交记录会发现，是每天都有人往这个文件里陆续提交十几、二十行代码，每一次单独的改动看起来都没什么问题，但日积月累、一年年过去，当初花了九牛二虎之力重构好的工程，又逐渐变回了一堆烂代码。这个现象背后的根本原因是：技术在持续更新、需求在持续变化、公司人员会持续流动，而代码质量在这些持续的外部变化面前，总会在不经意间悄悄变差——这个过程可以被类比成物理学里的熵增：一个封闭系统如果没有外部持续的能量投入去维持秩序，会自然而然地朝着更混乱的方向演变，代码质量也是同样的规律，如果没有持续的关注和维护投入，会自然地朝着更混乱的方向退化，而且写出烂代码的成本远比维持代码整洁的成本要低得多——一个实习生花上一个礼拜，就足以毁掉花半年时间精心设计出来的工程。这个类比揭示了一条重要的认知转变：改善代码质量不应该被理解成一个”做完就结束”的一次性项目，而应该被理解成一场需要持续投入、永远不会真正”完工”的持续对抗——就像维持房间整洁需要持续打扫而不是打扫一次就永远干净一样，代码质量的维护本质上也是一场和熵增规律的长期拉锯战，任何期待”重构一次、从此高枕无忧”的想法，都低估了这个系统本身持续退化的自然趋势。