技术债

1 引子

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

终有一天，心动变心痛。

从今天起，专注搬砖

什么需求，都能实现

复制粘贴，这很简单

一天不行，就两天

前后端到AI，不过是概念

总之，都能实现

2 技术债

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

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

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

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

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

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

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

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

——沃德·坎宁安（1992）

3 还债

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

可以问自己两个问题：

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

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

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

——蚂蚁金服 右军

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

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

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

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

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

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

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

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

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

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

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

——康威定律（1967）

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

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

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