范冰冰欠了8.8亿的罚款，而你欠了88天的技术债

范冰冰的偷税漏税案有了判决结果，她被罚款 8.8亿

无论是演艺圈的大佬，还是我们技术圈的码农，出来混迟早要还的。

本文将比较IT人欠的技术债和范冰冰欠的巨额罚款的相同点和不同点，和对如何避免技术债提出三点建议。

说到这里，也给大家推荐一个架构交流学习群：835544715，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，相信对于已经工作和遇到技术瓶颈的码友，在这个群里会有你需要的内容。

1. 什么是技术债？

据作者的不完全统计，除了需求变更，程序员还经常吐槽的另外一件事，就是接手了一个没有文档的半路项目。

更郁闷的是，前面负责开发的人还离职了，找不到人。

更加更加郁闷的是，这个半路项目的代码完全就是一大盘意大利面条——完全看不出头绪。

意大利面条式的代码是技术债的一种明显的体现形式。

还有的技术债没有这么明显，比如架构设计/技术选型方面的不足。

百科对技术债的定义如下:

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的一个比喻。

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

这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。

软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

2.技术负债和偷税罚款有什么异同？

1

相同点一: 对产品危害巨大

大家都在讨论范冰冰被罚的8.8亿是多么巨额的罚款，这里我想指出她更大的损失则就是她作为国内一线女星的品牌价值。

品牌价值的损失可能给产品造成致命的一击，如果这个人是在政法领域，可能就直接被“下课”了。

即使不在政法领域，这样的劣迹也足以让制片人/广告主退避三舍。

技术债给软件产品的危害，就如同上面的百科的定义里写到的，当技术负债积累到一定程度，后续的维护成本和开发成本会急速上升，严重的情况整个软件都要重写，比如当前的架构/数据库已经无法满足业务增长带来的性能挑战。

2

第二个相同点，就是技术债和偷税漏税罚款一样，欠的债随着时间的推移，需要加倍的偿还。

范冰冰其实并不是漏税漏了8亿，而是漏税在法律上需要加倍偿还造成的。如下截图：

另一个例子，日常生活中，为了省几十块的停车费随便停车，要罚款500块到2000。

技术债也是一样，今天节省了几天的时间快速把功能实现了，随着产品迭代，产品规模越来越大，如果架构设计不良，要做局部的修改都会牵一发而动全身，开发和维护成本巨大，欠的债要加倍偿还。

3

第三，技术债和偷税漏税的不同。

偷税漏税是一点也不要有，但是技术债并不是完全不能接受。

大家可能觉得技术债是越少越好，其实也不是。

持续将技术债维持在很低的水平需要较大的投入。所以这是一个投入产出比的问题。

比如一个创新的抢占市场，或者获得先机对成败至关重要的产品研发，它的时效性就更重要。

还比如一个生命周期相对较短，可以预见的产品，技术债的水平也需要做最优投入产出比的确定。

比较完了这两者的异同，现在我们来看一看：

3.如何避免欠下技术债？

1

‍第一步，你要知道你自己欠了多少技术债。

如果有条件的话，可以请技术专家来帮忙做一下评审。

如果没有条件，可以使用工具来检测自己的技术债的水平，比如Sonar。工具检测的结果仅仅做参考，这方面主要还是靠人来寻找自己主要的技术债的焦点，然后解决焦点问题。

再次强调一下，工具可能发现不了真正重要的技术债焦点，所以不要过度依赖和迷信工具的判断。工具只是一个起点，不是终点。

这里我要特别提醒一种比较特殊的技术债，就是安全漏洞。

在有的行业当中，比如：

金融；

涉及到关键用户信息的行业如酒店业；

涉及公司商业机密如公有云服务，

在这样的安全关键的行业中，我就不会把安全漏洞认为是技术债，因为在这样的环境中，安全漏洞不是可以欠的债，而是压根儿就不要借这个款。

如果发现安全漏洞的话，要立即修复。

其他行业，对安全漏洞的处理方式略有不同，需要视情况处理，不能一概而论。

2

第二步，考虑在你的团队创建一份大家达成一致的代码规范，并且开始遵循。新加入的团队成员也不例外。

代码规范不一定是要非常的全面和长篇大论，你们可以从最基本的开始，比如命名规范，注释规范，对异常处理的规范等等。

代码规范最好由研发团队和测试团队（尤其是也做白盒测试的测试团队）自行进行讨论后得出，而不是随便从网上下载一个规范就开始实施，那样可能会不适用当前情况，比如不符合团队习惯，或者规范过于重。

3

第三，考虑采用同行评审。

这一点比较好理解。但是实施方法可轻可重。

比较重的就是直接形成签入流程，工具上走代码评审的流程后才能签入。我之前做一款全球级的在线服务的自动化测试的时候，自动化测试代码签入都是要走流程。

还有一种我在一家大型互联网公司看到的做法，就是定期组织团队的代码评审，这个代码可能是已经签入甚至发布了的代码。有点类似研讨会，大家在一起评审代码，一起学习和进步。

4

第四，重构

有的团队会定期做重构，有的团队因为各方面的原因没有这么做。

重构是一个修整的动作。如果是一个在管理技术债方面没有太多经验的团队，我建议可以按照上面的这三步的顺序开始着手，先解决焦点问题和预防技术债继续堆积。

好了，现在做一个小结：

技术债是对产品有害的，它会随着时间的推移不断地积累和扩大不良影响。

技术债不是越少越好，需要按照具体的行业情况和要求来管理。

在某些信息安全关键的行业中，如金融，酒店，公有云服务，安全漏洞不是可以欠的技术债，一旦发现需要立即修复。

最后有四点避免欠下技术负债的建议:

    第一步，你要知道你自己欠了多少技术债，着力解决焦点问题。

    第二步，考虑在你的团队创建一份大家达成一致的代码规范，并且开始遵循。新加入的团队成员也不例外。

    第三，考虑采用同行评审。

    第四，重构。没有形成定期重构习惯的团队，可以先从上面3点开始做起。

你对范冰冰的判罚怎么看，你又是如何看待技术债的? 欢迎你在评论区留言！

想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费获取 架构群：835544715

点击链接加入群聊【JAVA高级架构】：https://jq.qq.com/?_wv=1027&k=5dbERkY