不要害怕技术债务

与任何类型的债务一样，技术债务也不值得害怕、厌恶或避免。利用技术债务可以区分优秀的开发人员和优秀的开发人员。

我一直讨厌编写“糟糕”代码的想法，从而导致技术债务周期。我知道我不会回来修理它，我只想把它放归野外，看着它蹒跚地走出门外。
但是，技术债务真的是糟糕的代码，还是我们只是停留在我们的黑白思维方式中？

如果你认为科技债务很糟糕，那就太可怕了。但是，如果您将技术债务视为垫脚石，那么您将成为团队中最好的开发人员。

如果我们了解我们可以和不能利用技术债务来满足我们的要求，以及我们如何偿还它，那么技术债务就会变得令人兴奋，可以验证我们的想法，而不是破坏我们未来的周期。

为什么科技债务不是一个肮脏的短语

知道何时以及何时使用技术债务，如何有效地“偿还”它并在计划中牢记这一点，将帮助您更快、更好、更智能地构建。
将技术债务看成是好是坏真的没有意义。这就像说工厂本质上是好是坏。如果应用得当，它们会很棒，但是如果您需要 Singleton，工厂不会帮助您。

技术债务也是如此。

编写糟糕的代码永远是编写糟糕的代码。但是，在短期内为小型卫星功能编写硬编码解决方案以启动大客户的功能，虽然不可扩展，但不一定是坏事。这是因为我们已经超过了开发周期的投资回报率目标，即使我们考虑重构传统的“好”解决方案也是如此。

同样，创建一个简单的实例来处理我们拥有 10,000 名会员的网站并简化优化和负载平衡，这在无法保证需要额外工作的增长，并且当前不需要真正拥有完全可扩展且客观上良好的东西时非常有意义。
这并不是说重构会很简单，但我认为它不会超过系统当前的需求。

尽管纯粹的技术人员会讨厌这一点，但业务需求很重要，并且通常胜过完美的技术构建。别担心，你最终会到达 科技浴 ，但一个项目的开始是创新和斗志昂扬的时候，而不是在一个功能上花费 6 年。

现在，并非代码库的每个部分都能从债务杠杆中同等受益。

何时何地利用科技债务

那么，我们实际上是如何有效利用技术债务的呢？它不能像拿出技术贷款并随意扔掉一样容易，不是吗？

显然，没有。别傻了。

老实说，知道是成功的一半。有很多情况，其中很多看起来几乎相同，所以很难定义一个硬性和快速的规则。在考虑捷径之前，我会问自己两个主要问题：

1. 如果我不能这么快地重构，对未来的发展会造成多大的伤害？
2. 与从一开始就编写它相比，重构会花费指数级的时间吗？

鉴于这些都是非常开放的，并且有很多边缘情况可以发挥作用，你只需要根据你所有的世俗经验和知识做出最好的猜测。如果您认为重构比预先编写“最佳”解决方案需要更长的时间，请不要借钱。
同样，如果您不能快速重构它，特别是如果它会对其他功能开发造成更大的伤害，请远离并让团队知道这需要重新审视（对不起，销售人员，您本周没有获得该功能）。

相反，如果您可以无限期地将其置于债务状态而不影响单个项目的推进，那么为什么还要寻求更长更复杂的解决方案呢？显然这实际上不会发生，但我们可以梦想！

我能提供的唯一另一个智慧是，不要在你的主要摘要或高流量组件上偷工减料（高流量，我直接谈论的是开发人员经常接触的系统，而不是客户一定要接触的系统）。
如果你有一个你知道对接下来 3 个月的工作至关重要的系统，并且会不断地改变或扩展，那么第一次就做好该死的工作，即使这意味着比你希望的要花更长的时间。

不要仅仅因为您认为以后有时间重构，就成为每个团队成员的大刺。有时，额外的 TLC 是一件好事（即使你的经理不这么认为。 旁注，他们大错特错 ）。确保这些系统建立在坚实的基础上，并专注于节省卫星系统的时间。

你认为能够利用技术债务有用吗？在评论中让我知道我错了！

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/29364/12431200

标签：重构,不要,开发人员,债务,害怕,技术,编写,我们
来源： https://www.cnblogs.com/amboke/p/16685219.html