最近在读《Google软件工程》，其中有一句话让我印象深刻：
代码是负债，而不是资产。
然而作为程序员，相信很多人都认为自己的代码就是资产，是自己智慧的结晶，怎么会是负债呢？
首先这个当然是要限定在软件工程领域来讨论。
在软件工程领域，代码的构建是要花费时间和人力成本的，但代码并不因此就能算作资产，真正有价值的是代码所要解决的产品问题，给用户和公司带来的价值。
而且写好的代码也是需要长期维护，长期运行的，而不是一次性的。
虽然维护的时间或长或短，决定于其服务的产品的生命。
所以代码是有维护成本的，就像负债，在没还清前，是需要源源不断的投入的。
我觉得这其实才道出了代码的本质。
为什么软件工程领域围绕代码有那么多方法论？
结对编程，代码评审，代码风格指南，测试驱动开发，设计文档评审，流水线集成和发布，清理技术负债，等等。
身处其中的程序员当然知道这是为了保证代码质量，但仅仅就是这样么？
要是从一开始就明白代码是负债，这一切就好理解了。
因为代码是需要维护的，不合理维护的代码就会像逐渐发霉的苹果，早晚有一天变成人人厌恶的坏代码，那些你眼里讨厌的legacy。
所以从一开始，代码就应该结合产品生命周期的规划，明白构建的代码将会存活大概多长时间。基于此再去设计，去实现，去计划相应的代码维护方案。
前期合适的流程能构建出当下场景合理的代码，避免代码一开始就腐烂。
但重要的是，团队能一开始就意识到代码需要长期合理的维护。
不会因为新需求的交付，而忽视那些将要后已经有问题但没人问津的技术负债。毕竟负债分散到日常去处理成本远远要小于最后一次偿还。
而且，当代码不能很好的服务产品的时候，要考虑何时弃用，将负债彻底清理。这反而是很多团队会忽略的东西。
不过有人就说，代码不用了不清理可以么？好像也没什么问题是不。
等遗留的旧代码依旧被别的代码引用，新老服务代码还有一些纠缠剪不断，代码仓库变得越来越臃肿，代码缺陷检查通不过，到时候开始抱怨的你猜会是谁？
到这里，你有没有发现，代码永远是程序员的负债，如果你自己还混不自知的话，最后很容易把自己搅入泥潭。
那个时候你能怪PM或者EM没有给你规划技术负债的清理维护么？
可能他们也知道，但是他们的屁股更关心的是需求的交付，产品的迭代。
而你有没有提前识别出代码负债的问题，有没有把技术负债也加入到日常交付中，是你要关心和负责的事情。
以前觉得软件工程都是些虚头巴脑的东西，不如写代码实在。
现在慢慢觉得写代码确实实在，但那些“虚头巴脑”的东西反而更考验一个程序员的能力。
如有疑问，请文末留言交流或邮件：newbvirgil@gmail.com本文链接 : https://newbmiao.github.io/2023/08/12/seeing-code-as-debt-not-value.html
