"够用的代码"演化成烂代码的本质：使用场景变了，代码却没跟着变

判断一段代码是不是”烂代码”，本身没有一个脱离场景的绝对标准：如果一个工程从始至终只需要一个人维护，只要满足功能和性能要求，即使写法上不那么优雅，也可以称之为”够用的代码”，谈不上是烂代码；只有当代码需要在团队里被多人协作使用时，才必须易于理解和测试，才有”其他人有没有能力接手修改”这个额外的要求；越是处于系统底层、被越多上层逻辑依赖的代码，扩展性的要求也就越高。几乎所有的烂代码，都是从最初这份”够用的代码”一步步演化而来的——真正的分界点不是代码本身发生了什么变化，而是使用这份代码的场景发生了变化：一个原本一个人负责的小项目，代码只求能实现功能、按时完工，等到其他人开始参与，才发现代码看不懂、不敢动，但需求方还在催上线，于是只能小心翼翼地只改逻辑不动结构，在注释里留一句”这么实现很ugly，以后重构”；再往后遇到相似需求想复用这段逻辑，才意识到当初的代码里做了大量针对特定场景的专用假设，复用起来很麻烦，为了赶进度只能拷贝代码改一改——当前的问题解决了，但同类问题在未来会以加倍的规模重现。这个案例揭示了一条关于代码质量的重要认知：”烂代码”不是写代码那一刻的属性，而是代码和它所处场景之间关系的属性——同一份代码，场景没有超出它原本的设计边界时，它是完全够用、甚至优秀的；一旦场景（协作规模、复用需求、扩展需求）超出了这份代码最初的设计边界，它就自然而然地变成了烂代码，而这个转变几乎总是发生在没有人主动决定”现在要重新设计”的情况下，是被后续需求一点点推着、在没有人明确察觉的过程中悄然完成的。