“代码写好了就万事大吉”这个观点，可以说是软件开发领域最大的误解之一。

Scoful

于 2024-12-24 18:00:00 发布

阅读量2w

点赞数 30

分类专栏：程序员成长文章标签：个人成长认知开发

本文链接：https://blog.csdn.net/Scoful/article/details/144678377

版权

15 篇文章

订阅专栏

大多数人（包括一些初级程序员）认为，写代码是开发周期中最耗时、最具挑战性的部分。实际上，这是完全错误的。从行业数据来看，70%以上的软件开发成本都集中在后期维护阶段，而不是初始开发阶段。

具体例子：

Facebook 的代码库曾经因为技术债积累过多，导致每次新功能开发或上线时，都需要花费数周甚至数月去解决与旧代码的冲突。为此，他们启动了内部工具 Hack 和 React 的开发，专门用来对抗这种“维护地狱”。
NASA 的软件项目在发射前，编码阶段占比不到项目生命周期的 10%，而剩下的时间几乎都花在了测试、迭代和维护上。

写代码可能是整个软件生命周期中，最机械化、最不需要“创造力”的阶段——维护才是真正考验技术和智力的挑战。而大多数人对程序员的“编程”刻板印象，正是基于对这个事实的误解。

这一观点完全颠覆了传统的“多写点代码=更高产”的直觉认知。在实际工作中，代码量的增加几乎总是直接导致维护负担的成倍增长。写大量的代码，不仅没有功劳，甚至可能是程序员的失职。

具体例子：

Google 内部推崇“减少代码量”的文化，许多工程师在代码评审时，最受赞赏的并不是添加了多少代码，而是有效减少了多少冗余代码。原因很简单：每一行代码都会变成未来需要修复的潜在问题。
举个更贴近生活的例子：很多中小型初创企业的技术团队最终死于“代码爆炸”。前期为了快速上线，他们写了大量低质量代码。后期这些技术债务逐渐淹没整个团队，导致产品无法迭代，最终公司倒闭。

绝大多数公司，甚至包括很多技术团队，仍然用“代码生产量”作为评估程序员绩效的指标。这是从管理层到基层的普遍认知偏误，背后暴露了行业内对“技术债”的无视。

代码维护本质上是一个极端复杂的动态系统问题，而不是单纯的“修修补补”。这是很多人完全无法理解的一点。随着时间推移，代码的运行环境、依赖的库、硬件架构甚至用户需求都会发生剧烈变化，程序员需要对抗的不只是 bug，而是整个系统的“熵增”。

具体例子：

Windows 操作系统是世界上最著名的例子之一。其代码库的历史可以追溯到上世纪80年代。每次新增一个功能，都需要考虑是否会影响几千万甚至上亿用户的使用体验，以及是否会与历史代码产生冲突。维护这种规模的项目，不仅仅是技术问题，甚至需要整个公司级别的战略规划。
开源社区的项目如 Python 和 Linux，也经常因为向后兼容性问题而陷入争议。例如，Python 在从 2.x 升级到 3.x 时，因未能很好解决兼容性问题导致大量用户抗拒迁移，这种“维护灾难”直接影响了整个语言生态长达数年。

维护工作的核心难点不是解决具体问题，而是预测并控制系统未来的混乱程度。程序员的工作不是简单的“码农劳动”，而是一种类似于建筑结构工程师的系统性设计。

很多人天真地以为，只要代码写得足够“优雅”或者“标准”，维护成本就会降低。这实际上是个巨大的误解。所有代码，哪怕是最“干净”的代码，也会随着时间不断积累技术债。维护工作其实是不断推迟系统崩溃的过程，而不是彻底解决问题。

具体例子：

Twitter 曾经进行大规模代码重构以消除历史技术债务，结果却导致平台稳定性急剧下降，用户体验变差。最终，他们选择放弃彻底重构的想法，而是让“技术债”与平台共存。
银行和金融机构的软件系统中，大量的核心功能仍然运行在数十年前的 COBOL 代码上。这些系统极其脆弱，每一次维护都是一次“手术级操作”。然而，完全重写这些代码几乎是不可能的，因为技术债已经堆积到了不可逆的程度。

没有任何代码能够真正摆脱技术债的命运，维护工作的唯一价值，就是推迟代码库彻底“腐烂”的时间。而这种观点会让一些技术人员或团队感到“徒劳”。

绝大多数程序员的教育背景和工作经验都偏向“如何写代码”，而不是“如何维护代码”。这导致大多数软件项目进入维护阶段后，问题往往会失控，因为团队根本不具备维护的经验和意识。

具体例子：

初级程序员往往倾向于选择“最酷炫的技术栈”或者“最复杂的实现方式”，而忽略后期维护的可操作性。比如，一个只需要简单 SQL 的功能，他们会选择引入一个 NoSQL 数据库，增加了整个系统的复杂度。
企业内部常见的问题是，核心代码的维护完全依赖于少数“老员工”或“原作者”。一旦这些员工离职，代码就陷入“孤儿化”，整个系统随时可能崩溃。

真正优秀的程序员，不是写代码最快的人，而是让代码在未来5年仍然能够被轻松维护的人。然而，这种能力在招聘市场上，甚至在程序员的职业晋升路径中，几乎没有被量化或重视。