有效解决技术负债问题

代码债务

1. 需要清楚的是，代码债务是无法消除的，必须随时做好承担技术债务的准备。
2. 在有的项目场景中，一些解决方案可以针对性解决某些具体问题，但该方案可能不是全局有效或最佳的，于是在系统的其他方面就形成了一个不可避免而必须承担的技术债务问题。
3. 一个好的工程师团队应该最小化技术债务影响，并对技术债务进行合理管理。

有意的与无意的

1. 有意的技术债务会让团队意识到问题，从而有意的去进行优化改进等；
2. 无意的技术债务在项目中是无法避免的，只能通过工程师团队中强化编码规范、业务理解等来对技术债务进行管理或减弱其出现的可能。

相关影响

• 对开发人员的影响

  • 在开发阶段，开发人员不可避免会遇到技术债务，应当直面技术债务，并积极处理技术债务问题。虽然处理技术债务可能会使得开发周期变长，但从长远来看，开发人员技术处理技术债务是有益的，一方面处理技术债务是一个技术经验积累的过程，另一方面及时的处理可以在之后的迭代中减少技术债务产生的可能等。
  • 每个开发人员都应当有意或尽力避免那些无意的和鲁莽的技术债务。

• 对客户的影响

  • 虽然乍看起来，技术债务和客户并无联系，客户也不太关心产品的代码质量等，客户只需要在成本没有增加的情况下，产品能够按时交付使用。
  • 然而，一个背负无意或者鲁莽的技术债务的产品在开发过程中，往往需要花费更多的时间、精力和资源，导致成本增加而收益缺减少的情况等。

• 对用户的影响

  • 用户可能不关心开发过程所需的工作量或资金，但他们关心软件的可靠运行以及快速添加的新功能。
  • 用户越快乐，客户越快乐，开发人员越快乐。

对解决技术债务的最佳实践，虽然技术债务无法真正被量化，但是这里还是有一些建议的

1. 保持最新状态
   工具、框架和库应该始终保持最新状态。并不是每个人都能意识到这一点。
2. 文档
   1. 记录需要修复或更新的所有内容，这是确保实际修复和更新的最重要步骤。
   2. 如果存在技术债务，最好了解他并确保团队或未来的开发人员也了解。
   3. 文档减少了定位和修复问题所需的工作量，如果文档记录良好，甚至能在业务层面上可见，将有助于客户承认并提供额外的资源。
3. 代码审查
   1. 在sprint期间定期审查代码。代码审查可以捕捉到可能导致问题的隐患，并找到解决方案。
   2. 代码审查确实需要一些时间，但在整个项目的背景下肯定是值得的。
   3. 但是，代码审查也有缺点。开发人员往往很忙，无法深入挖掘他人的代码，因此他们只会发现明显的错误，而吹毛求疵可能会导致团队内部紧张。因此应该谨慎应用。
   4. 当然审查代码不是没有边界的，否则它可能会无止境的消耗时间。但是，如果在每个sprint中留出一定比例的时间，专门用于修复开发人员发现的任何技术债务，那么可以在很大程度上保持产品尽可能的无债务。
4. 自动化测试
   1. 在开发阶段，有必要实施测试驱动开发，编写完善的测试用例，以清除代码中的许多不易察觉的问题。
   2. 自动化测试被忽略后，可能无法察觉出代码中的隐藏问题，往往导致产品发布后需要投入不成比例的人力和时间来应对，使得成本变高甚至不可控。
5. 敏捷架构
   在构建软件的过程中对更改更加开放，【点击跳转敏捷架构/开发】，敏捷架构要求代码具有灵活性和可维护性，因此敏捷开发自然会使开发人员保持良好的代码，有助于防止技术债务的大量积累。
6. 有效地复盘
   1. 如果出现问题，应该勇于面对，当问题解决后，需要进行有效地复盘。
   2. 但是要注意，复盘是为了提高工作效率，而不是为了找人背锅。复盘的重点应该放在了解问题及产生问题的原因上，以便团队可以采取必要措施防止同样的问题再次发生。
7. 高利息（高代价）技术债务优先
   1. 并非所有的技术债务都是平等的，因此应该优先考虑在特定时间内要解决的问题以及先不解决的问题。
   2. 存在于经常使用的更改的部分代码中的“垃圾”，就比在几乎没有使用或更更改过的部分代码中的“垃圾”要严重得多。
   3. 高息债务往往是项目起重要作用的核心部分，如果此部分的债务没有解决，就会妨碍所有的工作，并可能迫使其他部分的代码背上更多的技术债务。因此如果可能，应优先考虑这些问题。
8. 童子军规则
   “让营地比你刚来时更干净。”鼓励团队成员，以积极减少技术债务；

标签：负债,开发人员,代码,技术,债务,问题,有效,解决,团队
来源： https://www.cnblogs.com/sweetXiaoma/p/12599517.html