你的技术债还了吗?
什么是技术债?
技术债是由沃德·坎宁安在1992年提出,指我们在软件架构或代码编写过程中有意无意地做了错误的决策。随着时间的累积,这种错误会越来越多,就像背负了很多债务一样。
技术债的危害
技术债同财务债一样,是有利息的,还债的时间拖的越长,就需要支付更多的利息。很多临时性的代码、不合理的架构最终都会造成严重的后果,比如:
- 一个小的功能优化,可能会引发大面积的代码修改,大大提高了开发成本和测试成本,还很容易引入新的问题
- 在客户的生产环境上,数据量提升一个数量级时,会出现严重性能问题,就像是一个隐形炸弹,不知道什么时候会爆掉
- 历史代码都不敢修改和维护,最终代码越来越臃肿,无效代码越来越多
技术债的形成
以我们现在的产品代码来看,技术债的主要是以下几个原因造成:
紧急任务
紧急任务分为两种情况
1、有时需要有一些演示性的功能需要提前上线使用,主要用于售前
2、客户的交付时间压的很紧
上面的两种情况都将使我们放弃原本好的设计方案,为了能更快速地交付,而采用一些临时的方式去进行架构或代码等编写,并且要求在代码改动的地方写上 //TODO:
标记,表示此处是临时代码,最终是需要回来进行代码重构的。
实际情况是,代码中的 TODO
会越来越多,就像开发经常喜欢说的一句话一样:“暂时先这样,后面有时间再来进行优化”,然后就没有然后了。
缺少沟通
一个初级程序员在修改历史代码的时候,如果在没搞清楚代码逻辑和业务逻辑的情况下,不和团队成员进行沟通,就擅自修改代码,会产生两种结果:
1、出现的问题会被自动化测试或测试人员检查出来,当然,这是一种较好的情况
2、修改后有隐藏的问题没有被检查出来就发布到生产环境,这种是非常危险的
KPI考核
从8月开始,团队开始了 KPI 考核,目的是提高每个人的积极性,但如果每个人只是关注考核指标,就会出现「事不关己,高高挂起」的问题。长此下去,每个人的绩效可能都还不错,但产品代码中的坏味道会越来越多。
所以我鼓励团队中的每个人,只要嗅到坏味道,可以提出重构申请,写出自己的思路和方案,通过后会有额外的奖励。
技术债要避免吗?
上面说到技术债的种种危害,那么技术债一定要去避免吗?其实不一定,例如为了售前演示而快速推出的功能,这种债是必须的,因为可以快速交付,也许就是因为速度快而得到了一个商机。
但因为沟通原因而欠下的债是需要避免的,在团队协作中,任何时候,沟通都是要排在第一位的。
技术债的偿还
出来混,迟早是要还的,欠债也是一样,欠债并不可怕,只要定期偿还,也会是一个良性循环。就像我们按揭买房,每个月得按时还款。
目前能想到的一些偿还的方式:
1、代码提测前的Code Review是后面准备要做的,可以在很大程度上避免一些不必要技术债的产生
2、定期以任务的形式来解决产品代码中的 TODO 问题
3、沟通非常的重要,需要形成一种团队文化,充分的沟通也可以避免一些技术债的产生
总结
正确的看待技术债,正向的技术债不可避免,但需要定期偿还;负向的技术债需要尽量地减少。所以说技术债是需要合理的规划和管理的,这也是一个技术管理者需要修炼的技能。
你们的项目或产品中有技术债吗?
![](https://images.cnblogs.com/cnblogs_com/oec2003/219566/o_qrcode_for_gh_1a8c0bee3c6c_344.jpg)
作者: oec2003
出处: http://oec2003.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接,否则 保留追究法律责任的权利。