企业架构开发债务

近期在处理公司项目历史债务问题，由于客观历史原因导致。为了快速收益初期不知情况下产生。定期不清理债务导致。

综合债务偿还规划

根据当前情况，除重写策略以外，其他策略同时进行。按阶段将债务问题逐步偿还。根据阶段性成果适当调整下个阶段的重点工作。

技术债务和贷款买房的思维模式一样，如果借技术债务的收益大于利息的时候，大胆借！

**开发速度降低：**通常项目正常情况下，在相同的时间间隔下，完成的任务是接近的。随着项目的迭代，项目单位时间内能完成的任务数明显下降，那很可能是技术债务太多导致的。
**单元测试代码覆盖率低：**现在大部分语言都有单元测试覆盖率的检测工具，通过工具可以很容易知道当前项目单元测试覆盖率如何，如果覆盖率太低或者下降厉害，就说明存在技术债务了。
**代码规范检查的错误率高：**静态代码分析工具提示的代码债务太多，存在大量历史代码就需要处理。
**在线bug越来越多：**正常情况下，如果没有新功能开发，Bug 数量会越来越少。但是如果 Bug 数量下降很慢，甚至有增多的迹象，额外增加研发成本、不稳定的产品质量、难以维护的代码。
**业务共识问题：**理解需求需要时间，加入一个新功能需要写 100 行代码，只要花 20 分钟。但是搞清楚这 100 行代码，应该加到哪个文件里，关联那些系统需要超长时间。

策略并没有绝对好坏，需要根据当前项目场景灵活选择。有个简单原则可以帮助你选择，那就是看哪一种策略投入产出ROI更好。

重写：推翻重来，一次还清。
维持：修修补补，只还利息。
重构：新旧交替，分期付款。
投资：好的架构设计、高质量代码就像一种技术投资，能有效减少技术债务的发生。
测试：日常能做好代码审查、保障单元测试代码覆盖率，预防技术债务。
还债：因为进度时间紧等客观原因，导致不得不走捷径，那么就应该把欠下的技术债务记下来，放到任务跟踪系统中，安排在后续的开发任务中，及时还债及时解决，就可以避免债务越来越多。

防止技术债务产生的主要方法是了解开发团队存在的技术债务。开发团队必须全面了解技术债务，以及债务对项目的影响。合适的流程可以帮助开发团队避免技术债务积累，例如代码、设计、架构和测试的审查等。而且，这些流程必须是务实的，否则事与愿违。

PDCA（Plan-Do-Check-Act）它最早来⾃于质量管理领域，意思是做任何事情，都要经过规划（Plan）、执⾏（Do)、检查 (Check) 和⾏动 (Act) 这四个步骤。这四个步骤提供了⼀个简易的思考和做事框架。这个循环并不是运⾏⼀次就结束了，⽽是周⽽复始、螺旋上升的。
WBS（Work Breakdown Structure）任务分解。识别依赖及各环节关键路径，定义完成标准，达成共识并公开透明，变更即时调整。
MVP（Minimum Viable Product）最⼩化可实⾏产品。来自产品开发，不要⼀下⼦做⼀个「尽善尽美」的产品，⽽是先花费最⼩的代价做⼀个「可⽤」的产品原型，去验证这个产品是否有价值、是否可⾏，再通过迭代来完善细节。
ROI（Return on Investment）投资回报率，通常在广告业务作为重要的衡量标准。因为它是衡量广告投放花费的资金是否对于公司业务产生良好的实际影响，例如产生潜在客户、增加销售额、提升品牌知名度或者推动其他有价值的客户活动。
效率先行。开发过程越快越好，越快越有竞争力。这的确是软件开发，尤其是互联网行业软件开发的不二法则。

团队内债务认知建立，技术债务会直接影响到公司业务的成长，间接影响个人的成长。
- 技术债务产生的负作用，将直接影响相关业务线的发展。
采用低成本的方式进行预防。
- 强化开发人员时间管理认知，帮助开发人员更好的安排时间高效完成工作。
识别债务并标记。
- 服务、组件依赖混乱；文件、函数、包内容太多职责不清晰。
- 魔法值、炫技、复杂设计、无设计。函数、接口、参数过多。
采用PDCA的方式循环迭代。
- 标记出存在的负债问题。集中汇总到bug池。关联相关业务线。
- 梳理业务边界，统一代码风格、完善开发文档、接口文档、接口单元测试。降低开发人员协调共识周期长的问题。
采用WBS方式标记、处理、公开相关问题。
- 优先处理服务稳定性问题、线上紧急bug问题。
- 根据bug与业务的关系程度划分处理级别。
采用MVP方式逐步迭代项目。
- 落地持续改进能力；快速的增量交付。
- 提早集成与测试；让问题得以及时暴露，带来了更快的反馈及应对。
- 及时规避⻛险；意外仍然会有，但⼤多数情况下，急早发现问题，避免更⼤的影响。
- 降低发布周期；降低修复试错成本。