关于前端的技术债务

最近一段时间，常常看到技术债务相关文章，最近也是参与了技术债务的清理。因此从参与者的角度介绍下遇到债务问题和对于技术债务的理解

其实在于前端领域，技术债务的相对较少，由于前端有一个特色就是随着功能和设计的升级，相对容易重构。

可是本文的背景是在一些大型的前端项目中

技术债务的产生

随着前端复杂度的增长，技术债务就开始慢慢的在浮现出来。特别是系统级别的单页面应用，功能不断的叠加，技术不断的更新，架构不断的升级，技术债务就暴露出来了。

举一个例子（若有雷同，表示慰问）：
最开始尝试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/