程序员的迷思——技术债

程序员的迷思——技术债

这个需求很简单。

1 引子

曾几何,一人一键盘,指尖到天明。跳动的字符,砰然的心动,这不是初恋,但很甜。

终有一天,心动变心痛。

从今天起,专注搬砖

什么需求,都能实现

复制粘贴,这很简单

一天不行,就两天

前后端到AI,不过是概念

总之,都能实现

2 技术债

“人一切的痛苦,本质上都是对自己无能的愤怒。”

我们既想保代码,又要保业务,当这两者产生冲突,且必须取其一时,就会痛。代码流产,业务发芽,说来侥幸。

离业务越近的代码,越痛。月月痛、周周痛、天天痛,流得稀里哗啦。从0到1的实现者们,着实是个幸运儿,闭目思索,便可忆起当年需求。嗯,这段IF-ELSE的故事我知道。

从1到N的接力选手,就不那么好命了。过尽千帆皆不是,手捧黑盒独懵逼。三下五除二,拨开乌云,三行代码,美其名曰的Feature来自于此。产品欢呼,喜悦中却难以颜开。

我们深知,下次的Feature将会付出更多代价。即使可以欺骗内心,手指还是很诚实,噼里啪啦敲打之下,除了Feature还有Hack。

令人悲伤的是,这种临时方案带来的债务,不会随着需求的满足而清零,反而会变本加厉,直至产品消亡。下一次的需求需要付出更高的代价,人力、时间、风险、效果,都在瑟瑟和我们招手。

资源限制导致技术复杂性提升,技术复杂性引发研发成本提升,这便是技术债。

技术债:指开发人员为了加速软件开发,在应该采用最佳方案时进行了妥协,改用了短期内能加速软件开发的方案,从而在未来给自己带来的额外开发负担。

——沃德·坎宁安(1992)

3 还债

没有人想背负债务,但现实情况是,我们都是债务加重的刽子手。

可以问自己两个问题:

  1. 如果接手一份完美的代码,能否保证其继续完美下去?
  2. 如果接手一份烂代码,能否保证其不会更烂?

能与不能我们无法定论,现实情况是,这很难。因为业务会拖着代码一起跑。

业务逼着你跑,你不跑不行,可能跑着就累死了;你停下来歇会儿,搞搞技术改造,又可能被业务压力压死了,反正都是死 。

——蚂蚁金服 右军

所以,结论是没有什么灵丹妙药。业务要跑,债务要还,老婆孩子都得保。

因此,一定程度的负债是正常的,保持还债是必须的。

能认识到这样点,再看还债,内心会好过一点。

  • 曾经内心OS:业务给这么点时间,还要求代码质量,咋可能,应付着来吧。
  • 现在内心OS:业务要支持,代码要保证,能保一点质量算一点,少挖坑,多填坑。

西去终有经,内心的坚定能与拧巴的日子抗衡多久?这样做,“小拧巴”可能会少点,但“大拧巴”仍有很多。

对于大拧巴,除了少挖坑,多填坑,更需要机遇:

  • 抱紧大需求
  • 暴露大问题

不要幻想有一天业务静止,给重构留有余地。机遇之下,顺势重写。

为什么要重写?因为这已经不是小拧巴了。对待大拧巴,重构会花费大量精力琢磨过去,而非思考未来。对待烂代码,不要留恋。

除了小大拧巴,还有一个超级大拧巴等着我们——架构。

设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。

——康威定律(1967)

架构的宿命早已写在康威定律里。架构是人的映射,有什么样的Team,就有什么样的架构。代码可以优化,结构可以改善,语言可以更迭,但架构不容易改变。

曾有人笑言,如果有4个软件团队开发编译器, 那么结果很可能是编译器有4个部分,或者有4步完成编译。

架构,已经不单单是一个技术问题了。

参考