摘要：最近一段时间，经常看到技术债务相关文章，最近也是参与了技术债务的清理。但是本文的背景是在一些大型的前端项目中技术债务的产生随着前端复杂度的增加，技术债务就开始慢慢的在浮现出来。
最近一段时间，经常看到技术债务相关文章，最近也是参与了技术债务的清理。所以从参与者的角度介绍下遇到债务问题和对于技术债务的理解
其实在于前端领域，技术债务的相对较少，因为前端有一个特点就是随着功能和设计的升级，相对容易重构。
但是本文的背景是在一些大型的前端项目中
技术债务的产生随着前端复杂度的增加，技术债务就开始慢慢的在浮现出来。特别是系统级别的单页面应用，功能不断的叠加，技术不断的更新，架构不断的升级，技术债务就暴露出来了。
举一个例子（如有雷同，表示慰问）：
最开始尝试mvc时，使用了backbone开发单页面，然后一年后，发现angularjs特别火，而且调研发现这种mvvm模式更加提高效率，这时项目中一些新的模块开始都用上了angularjs，然后随着时间的推移，发现angularjs存在性能瓶颈，这时发现reactjs的虚拟dom和单向数据流很好，然后继续在新模块中引入。然后某一天，回头一看。。。WTF。。。发现架构混乱，维护困难，新业务开展困难等等。。。
如上面的例子，架构的升级，新技术的引入，特别容易引发技术债务的出现。
正如我之前的文章《如何在大公司成长》提到的，在成熟的系统中引入新技术其实是一个挑战非常大的事情，因为首先你必须控制好技术债务。
因为在厉害的架构师也无法设计一个面向未来可以一直不变的框架，再流行的模式也会不断演变。如果解决不好新旧的过度就很容易出现上面的情况。
可以直白的说，在越复杂的系统上面开发，就是带着越重的脚镣在跳舞。
技术债务的定义再举一个例子，也是引发技术债务的一种情况：
由于进度的原因，不得不使用一些hack的方式（而不是从根源解决)去完成任务，然后在没有来得及删掉这种hack方式前，有其他人在你的基础上继续迭代和模仿，最后变得想去掉这种hack方式都去不掉。
什么样的问题称之为技术债务，我和网上观点有些不同。对于一些编程习惯，编码方式，有异味的代码等等，我认为这些应该属于代码素养的范畴，这些可以不断改善，而且完全可以小范围的重构解决，不会形成叠加效应。
我理解的技术债务是它的存在影响了整个系统的效率和阻碍了系统的发展，随着系统复杂度的增加，问题会不断的被放大。
下面一一说明，并且配合举例
影响日常的开发效率
我认为这个应该属于最严重的影响，由于债务的原因，严重拖慢了开发效率，导致开发人员开法困难。
举例：
两个模块共用一个修改组件，由于两个模块底层依赖不一样，导致需要重复开发两次。而且每一次需求升级，都是两次的重复开发。这种情况的结果直接导致人力成倍翻倍。
提高了开发人员的学习成本
这也是对于工程效率的影响，由于技术债务的积累，导致开发人员需要花更多的时间去理解开发任务，需要更多的时间学习理解。
举例
由于历史原因，同样一个组件/模块有两种实现方式，新同学在选择时第一感觉就是迷茫，乱，烦躁，不知所措，还需要花人力去了解哪个更加合适，哪个会有什么样的坑等等，如果选择错误了，还需要花无谓的时间重做。
持续的影响网站性能
债务的积累必定是一些遗留问题，特点就是随着时间，会越来越多，越来越复杂，越来越不敢砍掉。直接导致的问题就是，遗留代码太多，这些代码都是对线程的无谓消耗。最后的结果就是网站越来越慢
举例
控件最初使用的是1.0版本，换2.0时，由于旧的业务没有随着升级，就导致系统里面ui库多版本，这样，ui初始化就需要初始化两份，而且合并打包的时候，代码也会多出很多。
容易触发bug
旧代码的错误使用，或者使用不当，经常会导致一些莫名其妙的bug，而且极其难定位。
举例
在开发中不小心使用了旧代码的一些功能，而其他人员在清理或者修改重构时没有考虑，直接就会间接的产生bug。也是因为这种原因，旧代码也越来越不敢清理
成为了业务规划的瓶颈
由于一些架构因素，导致某些业务功能无法实现，或者实现起来的成本特别高。
如何避免技术债务举例
两个模块由于底层的技术架构不同，如果pm希望模块间有一些数据的互通，或者功能的互相调用，这种需求就是受到技术的限制而实现不了（当然可以通过一些hack或者非常规方式实现，但是每一次hack都是一次新债务的产生）
技术债务能避免吗？
我觉得不可能，因为随着复杂度的增长，债务也在慢慢增长，只是快和慢的问题，也许你今天写的一个完美的功能，一年以后，对于新的架构就是一个债务，因为技术在不断再更新换代，没有任何一种模式是银弹。
如果非要有一种办法避免，我能想到的就拒绝新技术引入，一种模式坚持到底，但这肯定是不实际。
所以个人觉得对于技术债务
我们首先我们需要认识到债务的存在，最好有一个债务管理机制。例如有一个债务范围的控制，当影响面达到一定程度，就必须去清理。
其次认识到清理债务对当下的收益可能不明显，但是收益在未来会不断放大，所以对于债务的清理，我们必须要去面对，而不是逃避。
最后，还需要在平时的开发中，有技术债务的意识，例如，临时方案真的是临时的吗？开发出来的代码可维护吗？
http://tangguangyao.github.io/
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/86143.html
摘要：什么是技术债务由于团队在开始新项目的时候，旧项目的任何未完成的事情都会形成技术债务。技术债务产生原因有哪些原因技术债务的产生原因是多方面的，其形成的过程和生活中所担的债务形成的过程具有非常大的相似性。 什么是技术债务？ 由于团队在开始新项目的时候，旧项目的任何未完成的事情都会形成技术债务。比如代码不规范，需要进行代码重构的重构债务；比如设计上未完成的设计债务，等等，统归于技术债务。 而...
摘要：什么是技术债务由于团队在开始新项目的时候，旧项目的任何未完成的事情都会形成技术债务。技术债务产生原因有哪些原因技术债务的产生原因是多方面的，其形成的过程和生活中所担的债务形成的过程具有非常大的相似性。 什么是技术债务？ 由于团队在开始新项目的时候，旧项目的任何未完成的事情都会形成技术债务。比如代码不规范，需要进行代码重构的重构债务；比如设计上未完成的设计债务，等等，统归于技术债务。 而...
阅读 5264·2021-09-22 15:59
阅读 1855·2021-08-23 09:42
阅读 2560·2019-08-29 18:42
阅读 3443·2019-08-29 10:55
阅读 2057·2019-08-27 10:57
阅读 1759·2019-08-26 18:27
阅读 2721·2019-08-23 18:26
阅读 2911·2019-08-23 14:40
