技术举债前行是常态

啥是IT技术债务？技术债务是指在技术研发过程中，因产品设计、架构设计、编码规范、监管、rc等问题，这些问题，如果没有及时修正，就会导致代码臃肿、系统效率低下，难以维护，也难以新增功能。

在中小型企业技术债务是常态，我们需要做的是举债前行！在没有出现结构性破坏的情况下，债务问题需要逐步来解决。

下面说下我经历过的债务项目！

案例1:

2015年参与的电商项目，项目整个业务模式与京东类似。客户在app下单，订单履约中心分仓分单后，推送给wms系统拣选、打包，tms系统规划路线后，由司机给客户配送上门。

整体技术架构是基于php的ecshop二次开发，系统采用了单体架构，后期流量增多后，只在数据库层面拆给了读写分离。产品后期“重构”是团队的主色调，但是，在资金和时间周期不足情况下，最终难产，举债前行成为了技术常态。

举债前行

案例2:

2020年参与的互联网加油项目，项目业务模式其实就是“加油行业的美团”。用户在app选择附近油站，导航到油站后下单，油站接单成功后，打印小票，完成加油。

整体技术上采用了基于java springboot的架构，后期流量激增后，采用了多实例的服务端拆分，数据层面是读写分离。

项目债务产生的主要原因是，需求变更过多和产品线复杂。

债务产生的必然性

技术债务为啥会一定产生呢？项目管理金三角对此提供了有力解释，软件质量与时间、成本、范围成正比例关系，因为质量往往是其他三个因素平衡后结果的体现。

项目三角

按照此理论，质量只能在时间、成本、范围上选择其中两项，而不是成年人所谓的全都要。

债务的逐步解决方案

1、增加沟通成本。

1、向上沟通

要经常和上级(特指老板)沟通技术的研发流程、导致代码腐化的关键节点，让上级做到心中有数，增加掌控感。

2、横向沟通

与运营、市场等部门增加前期设计方面沟通，可采用场景还原方式。让大家知道本次设计的重点和要解决的问题。做到信息透明化。

2、隔离化解决问题。

技术设计上要考虑微服务化，把经常变化点单独分离出来，做隔离变化点设计。如果是单体架构就把变动的内容做成模块，让变动内容的影响范围控制在模块内，做到高内聚低耦合。如果是微服务架构，就把变动内容尽量放在服务内。