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