技术债是什么
技术债是指程序员担心破坏现有系统而害怕更改遗留代码的委曲求全（或者也是为了快速实现业务而无力设计的无奈之举）。根据该主题的研究，挪威 59% 的商界领袖表示，技术债是阻碍他们创新的主要障碍。当你有很多技术债务时，感觉就像你在试图驾驶一艘船，而锚仍然钉在海底。
技术债的起源和产生它的机制实际上很容易理解。它的发生是因为你的系统中 “一个个小小的快速的需求实现” （=画外音= 业务：这么简单的需求还要开发两天测试一天，今天搞完吧），给一个已经很复杂的函数添加了另一个 if 语句，直到你的软件变得如此复杂，没有人敢再改变它，因为害怕破坏其他部分系统无意。软件开发人员将此类系统称为 “屎山” 或 “意大利面条式的屎山” 。矛盾的是，几十年来我们一直知道如何避免技术债务——然而， “没有人” 遵循这个秘诀，因为，我引用； “他们没有时间” . 所以黑客被应用于现有系统，直到它们变得如此复杂，以至于所有未来的创新都被扼杀，每个人都受苦。积累技术债务，以及产生它的过程，相当于在泥土上盖房子。
对于国内来讲感觉更多的是大环境所致；996、内卷、追风口、赚块钱，大都公司追求的是灵活，快速迭代，追求的是眼前的，项目能不能活过明年还未知，简单的需求代码还考虑到后年？赚了钱再招人重构吧~
它为什么如此重要？
公司可能希望在未来的某个时候改变其业务流程。例如，您的营销部门发现更改某些表内逻辑，能吸引大量新客户，而营销部门可能想要更改一些字段的顺序。如果您的系统是一个大💩山，那么这种简单的更改通常是不可能的。这是因为您的业务流程是基于目前的软件架构中实现的，如果您不能更改您的软件架构，您就无法更改您的业务流程。这导致您的业务部门不是告诉您的软件部门他们应该做什么，而是软件部门通常会告诉您的业务部门他们想要做的事情是不可能的。实际上， “这是不可能的” ，我补充说，您可能也应该这样做。
“Wag the dog”浮现在脑海中……：
有什么解决办法？
封装是避免技术债务的关键。封装是 “隐藏复杂性的艺术” 。例如，当我启动我的汽车时，这个过程可能涉及 500 个活动部件。但是，我不需要考虑这些部分——我只需要记住把钥匙转向正确的方向，汽车会在一段时间后自动启动。如果我们能像制造汽车一样创建我们的软件，我们就可以避免技术债务。当然，如果你问大多数开发人员，他们会声称他们确实在应用封装——不管他们的系统有多复杂和混乱。因此，这里的某人显然没有说实话......
我并不是要责怪你的开发人员。大多数开发人员都是好人和女孩，尽他们最大的努力取悦他们的经理——而且技术债务往往是由于 “请在这里再做一次更改” 而累积的，而没有考虑长期后果。然而，我们创建软件的方式存在根本性的错误……
让我再重复一遍，以防你不明白……
我们创建软件的方式存在根本性的错误！
知道了 …？
如果你让普通开发人员为你的营销部门创建一个注册表格来吸引客户，他或她会很乐意开始编写代码，等待熟悉的拍拍背后告诉开发人员； “干得好！”
相反，开发人员应该问问自己；有没有其他人在我之前解决过这个问题？这时候开发者很可能会发现某个微服务模块已经解决了问题，将多年的认知能量投入到问题中，产生了一个超级灵活的注册表，开发者未来可以屈服于营销部门的意愿。然而，软件开发者在这个过程中没有任何激励，因为它是 “不那么有趣的工作” – 从个人开发人员的角度来看，他或她实际编码的次数越多，他或她学到的就越多。开发者学习的越多，未来的开发者就越有价值。在某种程度上，您可能会争辩说，有创造性的开发方式有存在破坏他们的老板项目的个人动机的可能！
再说一次，这不是开发人员的错，而是系统性的。系统是被操纵的，它被操纵的方式是，个体开发人员交付的代码越混乱，从个体的角度来看，它就越成功。（因为除了最初的开发者，没有人能看得懂！哈哈~）
事实是，我们需要停止根据开发人员生产多少来奖励他们，而是开始为他们不生产的所有东西奖励他们！仅仅因为软件开发人员每次生产东西时，他或她代表他的雇主积累技术债务，导致从长远来看，创新实际上是不可能的。
与其奖励开发人员自己创造的聪明东西，我们需要开始奖励开发人员没有创造的每一件事情——而是找到一个漂亮的设计好的组件，开箱即用，开发人员无需应用一行代码即可运行；（避免重复造轮子）
当然，这种运行软件开发部门的方式非常困难，因为感觉就像你付钱给开发人员 “什么都不做” 。但实际上，找到一个架构精美的预先存在的微服务，可能比从头开始实现一个写得很糟糕的大💩山要困难几个数量级。我之前已经说过好几次了，但是一件好事不能重复，它的目标受众是患有 “not invented here syndrome”的开发人员……
您的工作不是创建软件，而是思考！
简而言之，因为您添加到 git 存储库中的每一行代码都变成了额外的一粒灰尘，落在项目上边，就是一座山……
