在中小型企业技能债务是常态，我们须要做的是举债前行！
在没有涌现构造性毁坏的情形下，债务问题须要逐步来办理。
下面说下我经历过的债务项目！
案例1:
2015年参与的电商项目，项目全体业务模式与京东类似。客户在app下单，订单如约中央分仓分单后，推送给wms系统拣选、打包，tms系统方案路线后，由司机给客户配送上门。
整体技能架构是基于php的ecshop二次开拓，系统采取了单体架构，后期流量增多后，只在数据库层面拆给了读写分离。产品后期“重构”是团队的主色调，但是，在资金和韶光周期不敷情形下，终极难产，举债前行成为了技能常态。
案例2:
2020年参与的互联网加油项目，项目业务模式实在便是“加油行业的美团”。用户在app选择附近油站，导航到油站后下单，油站接单成功后，打印小票，完成加油。
整体技能上采取了基于java springboot的架构，后期流量激增后，采取了多实例的做事端拆分，数据层面是读写分离。
项目债务产生的紧张缘故原由是，需求变更过多和产品线繁芜。
债务产生的一定性
技能债务为啥会一定产生呢？项目管理金三角对此供应了有力阐明，软件质量与韶光、本钱、范围成正比例关系，由于质量每每是其他三个成分平衡后结果的表示。
按照此理论，质量只能在韶光、本钱、范围上选择个中两项，而不是成年人所谓的全都要。
债务的逐步办理方案
1、增加沟通本钱。
1、向上沟通
要常常和上级(特指老板)沟通技能的研发流程、导致代码腐蚀的关键节点，让上级做到心中有数，增加掌控感。
2、横向沟通
与运营、市场等部门增加前期设计方面沟通，可采取场景还原办法。让大家知道本次设计的重点和要办理的问题。做到信息透明化。
2、隔离化办理问题。
技能设计上要考虑微做事化，把常常变革点单独分离出来，做隔离变革点设计。如果是单体架构就把变动的内容做成模块，让变动内容的影响范围掌握在模块内，做到高内聚低耦合。如果是微做事架构，就把变动内容只管即便放在做事内。
