释放数据的力量以减少技术负担
由于技术债务已成为我最近职业挑战的核心部分，因此我开始撰写有关该主题的系列文章。
不要指望这里有任何详尽而详尽的工作，如果需要，可以通过谷歌搜索或从自己喜欢的在线内容来源获得。
只是期望从工作经验和实用技巧中获得更多轻松的成果。
因此，事不宜迟，让我们开始吧。
你要我释放什么吗？
数据湖通常专注于解决业务问题，最近甚至专注于用于训练机器学习模型。
不幸的是，通过减少技术负担或优化现有系统，很少有人关注使用数据湖来保护系统的价值。
最好将心态转向使用数据，以减少技术负担，如何通过使用度量帮助开发团队跟踪进度以及如何优化当前系统，从而构建更强大和更具弹性的系统。
我们可以使用进化架构范式中的某些元素（例如适应度函数）来主动应用技术，以减少那些在那一刻最适合您目标的架构维度中的技术负担。
那么，什么是技术债务？
技术债务是沃德·坎宁安（Ward Cunningham）首先使用的概念，即与金融债务的相似之处。
马丁·福勒（Martin Fowler）确定了什么被认为是技术债务，什么不是。
根据该分类，我们认为我们所知的所有错误，问题和缺陷都不是技术债务。它们包括在“ 外部质量 ”类别中。
外部质量包括那些功能，行为等，应完成代码，但不会影响客户和业务。
除了缺陷之外，外部质量还包括可用性和用户体验形式。
然后，我们获得“ 内部质量”，涉及建筑主题，例如：
代码的可理解性是指这样的事实，即代码对特定的开发人员而言并不严格，任何人都可以轻松地对其进行修改。
代码易于适应，构建新功能。从这一点出发，提出了一项技术债务的重要指标：（未来）变更成本 ..
变更成本会影响工作量，包括思维和代码，开发时间以及开发人员的专业知识或技能。
大家可能都已经知道了，管理外部质量要比内部质量容易。
技术债务分类
同样来自马丁·福勒（Martin Fowler），他提出了对技术债务根源的定义。
故意：我们故意制造技术债务。从本质上讲，这不是一件坏事，好/坏事来自于我们创造技术债务的方式。
鲁ck：“ 我们没有时间进行设计 ”。看到？这不是一个好选择。这听起来更像是借口，而不是理由。
谨慎：“我们必须立即运送并处理后果”。再见？每个人都意识到自己正在做的事情不是那么伟大，但这没关系。他们已经确定了什么以及何时做得不太理想。理想情况下，应该对其进行跟踪以查看对系统的未来影响，并在可能的情况下将其删除。
无意间：我们正在创造技术债务，我们不知道自己正在创造技术债务。这是技术债务的最危险形式，因为我们甚至不知道自己正在创造它。无论如何，我们可以采用两种不同的方法来处理它：
鲁ck：基本上，我不知道自己在做什么，我也不在乎。因此，那里可能会有一些不太理想的东西，我对此一无所知，最糟糕的是，我不会在意。
谨慎：“ 现在我们知道我们应该怎么做 ”。好的，至少您已经吸取了教训。
最好的技术债务是谨慎的技术债务。
提示：标记何时故意欠下技术债务，并对其进行仔细监控。
常见误解
缺陷不是技术债务。缺陷只是技术债务的症状。
数据湖可能不仅包含业务信息，而且还包含IT信息。
了解您的技术债务
首先要记住的是，不要试图消除技术债务，而要控制住债务并忍受它。
技术债务总是发生在最好的团队中，因此，我们应该准备好应对它。
有关如何发现缺陷的一些提示：
如果仅在一个模块，类等中存在许多错误，那么这很可能是技术债务的迹象。
浏览您的开发版本控制（例如Git，Mercurial等），您可以确定由于发行数量和提交，开发而导致的不稳定，性能不佳。
如何忍受技术债务
正如我们前面提到的，技术债务将始终以一种或另一种形式存在，因此，与之共存的最佳方式是制定战略和程序，以使其得以识别和控制。
一种控制它的方法是通过利用数据体系结构来提供来自系统，开发（即VCS）和操作（即监视，跟踪，日志记录）的数据，以丰富您的业务指标。
这样，您可以评估系统对业务的影响。
使用演化架构的适应度函数，我们应该能够为架构定义优先级（即指标，目标），从而控制技术负担。
“ 架构适应度功能提供了一些架构特征的客观完整性评估 ”
下一步
这只是对技术债务的简要概述，以及使用数据来实现更多IT目标的另一种方式。
由于这是一个广泛的主题，因此下一部分将更深入地介绍更具体的主题，例如：
如何衡量技术债务
SDLC中减少技术债务的策略
我应该使用哪种数据来减少技术债务？
通过部署自动管理的发行版来发展系统。

关注 CDA人工智能学院 ，回复“录播”获取更多人工智能精选直播视频！