打开

代码能跑就不要动,为什么我们都会有这样的想法?

subtitle
蛋糕烘焙 2021-10-21 03:14

为什么程序员会有代码能跑就不要动的观点?

今天就和大家说说这个有趣的话题。

打开网易新闻 查看更多图片

针对这个问题某乎上有个小哥讲了一个小故事,先分享给大家:

新来的程序员小哥觉得代码不规范,内存释放的模块很混乱。这可能有隐藏的风险。接下来,他做了整合,把内存释放进行了模块化,专门整好了。代码变的更优质了,对吧?到这里算是好的。

然后过几天,就出事了,生产出现重大故障。系统内存泄漏,系统崩了,影响客户使用。客户投诉,扣钱。然后整个项目组开始大排查。排查到最后,就是这个内存释放的优化,有个位置漏了,没改到。但是其他位置全改掉了。然后这个没改到的位置,内存长期不释放。好了,内存爆了,内存泄露,系统崩溃。就是这个优化,导致了重大故障。

然后全公司通报批评。要求项目组整改,并且出检讨,现在能理解了吗。代码能跑,就别改。

辣条对这个倒是没有太大感觉,也没有很多工作这块的经验,不过之前暑假实习,有位前辈和我聊过这个话题,他大致是这么看的:

很多中小型公司和一部分大公司对于代码质量、开发效率等基础设施建设没有什么追求。这些公司的商业模式侧重在业务逻辑方面。由于各种原因(比如垄断等),用户对于产品质量没有什么话语权,不得不容忍系统和应用的缺陷。这使得此类公司的技术团队从KPI的角度没有足够的动力去改良代码和系统的质量,除非这种改良可以直接带来商业利益。

具体来说,比如一个提供打车或者外卖服务的平台,它的商业收益主要来自于线下的用户行为。改善代码质量只有在用户数量增长需要扩容服务、提高性能的时候才有真正的商业收益。除此之外,改善代码质量几乎没有可见的商业收益。这给中层管理者带来很大的挑战,因为他们需要去证明投入工程资源的产出。如果这种产出无法直接或间接地通过销售增长、用户增长等指标反映出来的话,中层管理者就不会愿意让自己管理的开发者去改善代码质量。

长此以往,代码库中会逐渐累积各种技术债和潜在的缺陷。随着时间的推移,重构代码的代价会越来越大,风险也越来越高。这种情况下从风险收益比来看,尽量不要改动能够运行的代码是一种局部最优的策略。

只有当代码质量严重影响了系统的稳定性以后,中层甚至高层管理者才会有动力去投入资源做大范围的重构和改良。而这种时候通常伴随着技术团队人员流动,很容易出现全部推翻重写的局面。

辣条个人认为倒也不是绝对的。这取决于你个人对整个项目的熟悉和理解程度。

可以动的情况如下:

  • 你是项目的主要代码贡献者之一,你对每个模块做什么都有充分的理解,知道修改带来的影响。
  • 项目成败责任在你,你需要判断某个模块如果不修改的风险,以及事故发生时会造成什么损失。
  • 虽然之前的代码很乱但能跑起来,但项目还没上线,为了日后系统的稳健,你决定大动干戈,重构一下。

不要动的情况:

  • 你往一个巨大的项目里面添加了小功能,为小功能而且修改已经存在很久的部分,风险是很大的,除非你有充分的理由。
  • 项目bug很多,改了一个bug会有n个新bug出现。
  • 项目已经上线,如果需要大改动,需要测试。

个人建议:

  • 如果你的代码能跑,但你不知道它为啥能跑,你还是不要提交这种代码了,搞懂了再提交。
  • 写单元测试,以后修改了跑一次全部测试,也知道修改带来了什么影响。

元芳,你是怎么看的呢?欢迎在评论中留言。

特别声明:本文为网易自媒体平台“网易号”作者上传并发布,仅代表该作者观点。网易仅提供信息发布平台。
154赞
大家都在看打开应用 查看全部
网易热搜每30分钟更新
打开应用 查看全部
打开