- 综合排序
- 最热优先
- 最新优先
- 来自专栏CSDN搜“看，未来”
技术债：HTTPHTTPS
技术债：HTTP/HTTPS HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol) 与 HTTP 有关的协议 在互联网中，任何协议都不会单独的完成信息交换，HTTP 由此出现了 Cookie 技术。 明文 HTTP 协议里还有一把优缺点一体的双刃剑，就是明文传输。
56920编辑于 2022-08-11 - 来自专栏小二十七
什么是技术债，为什么要还技术债？
先说我的结论就是：技术债要还，还不还技术债，决定你所在的公司是不是尊重科学尊重技术，观点主要有以下三个： 技术债是什么，对产品和项目有什么影响 技术债对开发环境和技术氛围的影响 技术债和技术价值观 技术栈是什么 ，对产品和项目有什么影响 既然叫技术债，那么他本质是一种“债”，所以我们先脱离所谓的技术，单独聊聊什么是债？ ，为什么要重视技术债和细节？ 难道不应该等到你的身体已经出现问题，或者发出警报后，你再去看医生吗说到这里，技术债的重要性毋庸置疑，重视技术债，就是重视于未然，以最低的成本或者零成本，防止未来的灾难发生，还不还技术债很多时候是一种选择 没有良好的技术环境企业就无法吸收和留住高质量的技术人才，人才是现代企业的核心竞争力，没有人才的企业在瞬息万变的市场上是难以做出快速反应的 技术债和技术价值观 不重视技术债就是不重视技术，不尊重科学发展，
70320发布于 2020-08-06 - 来自专栏云云众生s
数据债与技术债
积极处理数据管理可以减少技术债务并增强可扩展性。 译自 Who’s the Bigger Villain? Data Debt vs. IT 行业的每个人都知道技术债务。技术债务（也称为技术债、代码债务或设计债务）是一个比喻，它描述了开发团队优先交付功能或项目可能带来的后果，这些功能或项目以后需要重构或重做。 技术债务可能是故意的，应该保留在开发人员有意识地采用长期不可持续但能带来短期利益的设计策略的情况下，例如发布版本。非故意的技术债务可能是由于“快速而肮脏”或“快速行动并打破常规”的方法造成的。 Martin Fowler 的2009 年文章关于技术债务象限的文章描述了第二个轴，对谨慎的技术债务和鲁莽的技术债务进行了相关的区分。 尽管数据债务和技术债务密切相关，但两者之间存在关键区别：您可以宣布技术债务破产并重新开始，但对数据债务这样做很少是可行的选择。
26810编辑于 2024-12-15 - 来自专栏程序人生
技术债：人的因素
「利息」继续借债，债务成本会越来越高，累积的利息会呈指数增长 —— 在技术债基础上继续引入技术债，会让事情变得越来越糟糕，引入新功能（软件资产）的时间会越来越长。 技术债分成几个部分：1) 架构和设计上的技术债 2) 代码实现层引入的技术债 3) 软件测试的技术债 4) 文档技术债。 我们平时对技术债有些误区，认为技术债的引入很多时候是开发工期不够，开发团队不得不做出妥协，选择短平快的解决方案。 其次，开发者需要知道当前的系统有哪些技术债，这些技术债产生的原因是什么。 如果说对 API 的理解还不算太大的挑战，那么，全面了解当前系统，尤其是自己所做功能涉及到的技术债，则难度高了一大截。 这个流程不但考虑了尽可能减少代码层面的技术债，还考虑了减少测试层面的技术债。但很可惜，根据我跟很多微信朋友的了解，一半以上的团队都没有这样的流程。
60620发布于 2021-05-11 - 来自专栏腾讯移动品质中心TMQ的专栏
代码质量与技术债
SQALE方法的分析模型解决了这个问题，由此我们也引出了本文中的第二个重要概念：技术债TechnicalDebts。 这个定义暗示了这种“负债”是一种刻意的、理性的经过权衡的行为，后文中我们进一步探讨技术债务的类型时会指出这一定义仅仅代表了技术债中相对良性的一类，是一个比较“温和”的定义。 此处我们关注的重点是使用技术债这一隐喻来帮助大家理解度量代码质量的方法。 既然谈的是“债”，自然就应该和钱有关了。 后续文章在讨论技术债的危害时，我们还会时常提及技术债的非线性特征。 现在我们还剩下一个度量问题：如何知道两段代码的质量差异？现在有了技术债本金这个绝对值，但是不同规模，不同类型的代码应该如何比较呢？ 这4条规是我们需要优先偿还的技术债，目前已经在整个部门推广实施。 读到这里，很多人也许忍不住想问，如此这般折腾有啥用？
3.4K73发布于 2018-06-22 - 来自专栏数据库学习
如何解决技术债
以上将技术债务产生的原因分为四类。我们通常认为，健康的技术债是右边的两个维度，不健康的技术债是左边的两个维度。基于此我们可以分析技术债产生的原因并制定相应的改进措施。 四、技术债类型关于技术债的类型及常见问题主要有：五、为什么要管理技术债Martin Fowler 在 Is High Quality Software Worth the Cost? 技术债的持续累积是导致质量下降的关键原因，但技术债无法避免，因此技术债的有效管理和消除是我们保障高质量软件的必不可少的方式之一。 当然也不仅仅限于团队内部，也要倾听用户的问题，有意识的建设研发效能度量体系，度量技术债和留意产品延迟和成本的上升。 针对上面这几个技术债象限产生问题的原因来分析如何避免和解决技术债。 的迭代解决；在没有高价值+高/低成本的技术债时，再来考虑低价值+低成本的技术债；最后如果只剩下低价值+高成本的技术债，还是先拆分，再解决，或可考虑直接移除；6.4计划执行由于我们难以在一段时间内集中处理技术债务
86420编辑于 2023-11-05 - 来自专栏程序人生
技术债：the good, the bad, and the tao
也许是年关将至，出来混，欠的账都要还了，我正好也打算写写技术债，干脆趁热打铁，也来一篇。本文从另外一个视角看技术债。 首先，什么是技术债？ 这种由于时间和资源受限的情况下不得不牺牲质量引入的技术债是最主要的一种技术债。 第二种技术债是因为开发团队未能事先进行合理的设计，导致架构混乱或者过度设计，从而引发在未来时刻爆发的技术问题。 第三种技术债是随着时间的推移，一个原本设计良好的架构不断叠加第一种技术债，导致代码是 case by case 堆叠起来的。 还有一种技术债是因为开发团队的能力和水平有限，写出来的代码质量低下，从而引发在未来时刻爆发的技术问题。 大部分软件开发团队同时背负以上几种技术债。 所以，不要怕引入技术债，相反，要敢于引入技术债，举债经营，尤其是新的产品和功能未能证实其价值的时候。通过引入技术债，我们以软件日后腾挪的空间换取了发展的时间。
1.2K150发布于 2018-03-29 - 来自专栏喵喵侠的社区活动征文
浅谈前端开发的技术债
技术债是一个老生常谈的话题了，这个无可避免，会伴随开发一生。只要技术在更新，需求在变化，技术债就一定会产生。那么如何有效治理技术债，这个话题就很有探讨的价值。 下面我将会以我个人的角度，浅谈一下技术债产生的场景，以及如何解决和避免技术债。 总结 也许每一个人对技术债的理解都是不一样的，但在我看来，每一个小的改动，都可能会堆积成技术债。合理的代码书写、恰当地使用成熟的技术方案，会在一定程度上防止技术债的出现，减少技术债越欠越多的情况。 我上面举的一些例子，并不是什么高大上的技术债，而是日常开发的坏习惯，一点点累计起来的技术债。一眼望去都能看懂，但深究起来能够在细节方面都做到位的人却很少。 如果你有更多对于技术债的案例分享和思考，欢迎在评论区与我互动交流。
68293编辑于 2024-07-09 - 来自专栏咩嗒
puerts偿还了xLua哪些技术债
我想既然都重新开发了，能否重新考虑当年xLua的一些技术决策点，放在UE，放在那么多年后的今天是否仍然合适。 没有静态类型检查，大项目很难做重构，随着技术债的积累会越来越难维护。 一些拼写错误，类型错误，得在运行时才能发现，然后靠肉眼排查。
1.7K30发布于 2021-11-10 - 来自专栏腾讯移动品质中心TMQ的专栏
腾讯TMQ在线沙龙回顾|技术债
技术债 活动时间：2017年11月23日 QQ视频分享 活动介绍：TMQ在线沙龙第三十四期分享 本次分享的主题是：技术债 有72位测试小伙伴报名参加活动！ 想知道活动分享了啥吗 请往下看吧！ 分享主题 1、代码坏味道 2、理解技术债 3、技术债的天敌 问答环节 1、对于业务比较重的项目，业务流程变动频繁、开发周期短，如何去有效管理代码质量？ 如果是业务增长平稳的项目，可以引入技术债去观察变更热区，缺陷发现情况，先确定需要提升的代码或模块，推动项目研发正视现有问题和痛点，让其理解改善技术债有利于降低代码变更成本。 先设立小目标,比如新增代码的技术债控制。 2、如何和开发有效的进行沟通，让他们采用TDD的方式来进行编写需求? 答：解决时间和技能的问题。
1.1K60发布于 2018-02-08 - 来自专栏深度学习与python
如何领导团队做好技术债管理
如果你想要统计数据或过滤视图，请随意标记技术债，但请确保将整个积压工作一起安排优先级。 不要让技术债成为一场指责的游戏 另一个常见的错误是对技术债的争论充满了指责。 如何讨论技术债 现在我们知道了该避免什么，让我们来看看一些讨论偿还技术债的重要性的方法。这通常围绕现有技术债务的风险，由其引起的（维护）辛苦，以及它如何 阻碍新功能 的开发。 每段工期都要解决 N 个技术债问题 另一个极端是停止讨论投入的时间，而只是从每个工期的积压工作中拿出固定数量的技术债问题。 这里有一个明显的问题，有些技术债问题可能很大，会占用工期的大部分时间。 将中等大小的技术债当作涉及该系统或代码库的下一个项目的一部分 所谓的“童子军规则”的一个版本：你应该让代码库和系统变得更好。 一种方法是经常在项目中规划一些额外的技术债偿还。 这里的问题是，技术债丧失了优先权——你偿还什么技术债是由你下一个项目所接触到的东西驱动的。 要做到这一点，你还需要与你的产品同事建立牢固的信任关系，因为这对他们来说似乎是一种职责越权。
40830编辑于 2023-04-01 - 来自专栏芋道源码1024
“技术债就像俄罗斯方块”
技术债可以与金融债进行比较。如果不偿还技术债，则会积聚“利息”，从而导致之后更难以实施更改。不过，技术债不一定是一件坏事，有时恰恰需要技术债才能推动项目前进。 ? 开发者 Jonathan Boccara 将技术债比作俄罗斯方块。游戏初始，需要从一个空白的页面开始进行，就像从什么都没有的编码项目开头一样。 技术债也是如此，如果能够控制，并且计划在以后偿还，则可以适当增加债务。 当过去的技术债管理不善时，方块堆积至顶部，无法再添加新功能。在这一点上，前进的唯一方法是回到过去，从而通过重构简化代码。 另一位同样将技术债比作俄罗斯方块的开发者 Colin O'Dell 认为，必须使用与玩俄罗斯方块类似的思维过程来管理技术债： 如何排列先前的块？（当前如何构建代码库？） 是否有放置当前块的理想位置？ 当你背负技术债时，不妨借鉴俄罗斯方块的思路，或是玩几局游戏，说不定能激发灵感。
59020发布于 2020-02-20 - 来自专栏JavaEdge
05-大厂咋解决技术债的？
现实没有技术债管理团队，也没人愿意加入这样队伍。这种团队每天就是给其他开发人员收拾烂摊子，谁愿意给别人擦屁股呢，毕竟又不是年薪百万？ 这项工作本质上和管理技术债是一回事。因此，把小组叫技术债管理小组挺合适。 这个团队现在实际上就是技术债管理团队了：高风险、低收益。没人愿意加入这种群体。 可行解决方案 也许核心团队也应该像特性团队一样对待他们的工作。每次迭代都应该有要达到的里程碑。 8 总结 技术债管理团队是组织希望扩展产品开发工作时必不可少的重要团队。我们可以将其命名为核心团队、基础设施团队、架构团队，甚至像 SWAT Team 这样有趣的名称。 组建这样一个核心技术债管理团队并不容易，维持和扩展它是更难的事情。但是，如果我们真的想扩大我们的开发规模，这样的团队是必不可少的。 关注我，紧跟本系列专栏文章，咱们下篇再续！
20300编辑于 2024-05-26 - 来自专栏架构之家
从整体组织的角度看待技术债，避免技术破产
我们通常把这种情况归咎于猖獗的“技术债”，但却没有讨论导致技术债的原因。 笨拙的编程不是造成技术债的主要原因，因此我们不能指望仅依靠更熟练的编程就能解决技术债。相反，技术债是沟通不畅的三阶效应。 我们所观察到并被标记为“技术债”的是这一功能失调开发过程的副产品：代码中缺乏解决方案的具体化。为了解决不断积累的技术债问题，我们需要修复这个被破坏的过程。 造成技术债的主要原因 技术债的比喻是由 Ward Cunningham 引入的，它用来描述开发人员有意识地决定将具有已知限制的代码交付到生产环境中的过程。 实践中的技术债 如果我们要理解无意中导致技术债积累的力量，我们必须要看下代码，并看看“技术债”是如何体现出来的。 我的观察结果是，代码中往往有很多的“如果”和“但是”，但很少能传达意图并帮助理解。 事实上，认为开发人员能够并且应该单独处理技术债是导致技术债的另种思维症状。对于开发人员和业务人员来说，这都是一个令人不安的观点。
33710编辑于 2022-09-01 - 来自专栏JavaEdge
技术债正在悄悄拖垮你的团队！
这引出了“技术债务”的隐喻（参考 Ward 的解释）。开发人员选择暂时不投资于代码的可变更性，而是承受技术债务，以便更快完成任务。之后，每次修改代码都需要支付额外的“利息”，直到技术债务彻底清偿。 1 啥是技术债？ 技术债务是指当前软件状态与最适合于轻松实现更改的目标状态之间的差距。在某些情况下，积累技术债务可能是值得的——例如，为了满足一个硬性截止日期，否则整个项目可能停滞不前。 当然，这个指标既主观又依赖于开发者的技术水平及团队的工程文化。根据破窗理论，糟糕的代码越多，就越会鼓励开发人员继续制造技术债务。 每个团队都会面临其独特的技术债务挑战，因此解决方法也会有所不同。 最简单的衡量方式可能是估算清偿技术债务所需的工作量。 通过结合这些能力，我们可以更准确地评估并应对技术债务。 10 关键总结 技术债务是指当前软件状态与最适合轻松实现更改的目标状态之间的差距。 在几乎所有情况下，保持技术债务处于较低水平是非常重要的。
24600编辑于 2025-06-01 - 来自专栏深度学习与python
从整体组织的角度看待技术债，避免技术破产
我们通常把这种情况归咎于猖獗的“技术债”，但却没有讨论导致技术债的原因。 笨拙的编程不是造成技术债的主要原因，因此我们不能指望仅依靠更熟练的编程就能解决技术债。相反，技术债是沟通不畅的三阶效应。 我们所观察到并被标记为“技术债”的是这一功能失调开发过程的副产品：代码中缺乏解决方案的具体化。为了解决不断积累的技术债问题，我们需要修复这个被破坏的过程。 造成技术债的主要原因 技术债的比喻是由 Ward Cunningham 引入的，它用来描述开发人员有意识地决定将具有已知限制的代码交付到生产环境中的过程。 实践中的技术债 如果我们要理解无意中导致技术债积累的力量，我们必须要看下代码，并看看“技术债”是如何体现出来的。 我的观察结果是，代码中往往有很多的“如果”和“但是”，但很少能传达意图并帮助理解。 事实上，认为开发人员能够并且应该单独处理技术债是导致技术债的另种思维症状。对于开发人员和业务人员来说，这都是一个令人不安的观点。
38510编辑于 2022-03-22 - 来自专栏云云众生s
在云端平衡AI创新与技术债
如今，技术高管们正在告诉他们的工程团队：“我们现在需要一个人工智能故事”，而很少考虑如何在他们的系统中最终实现这一点。这场竞赛是真实的，它有自己的一套独特的影响，特别是对于那些管理云基础设施的人来说。 这场人工智能热潮正在以前所未有的规模创造人工智能技术债务，了解这些影响对于确保我们的云环境保持高效、安全和经济高效至关重要。 这种对资源需求和云支出的激增会导致许多 CTO 开始抱怨的人工智能技术债务。我们正处于人工智能开发速度往往超过组织有效管理和优化它的能力的阶段。 现在比以往任何时候都更加重要，在技术债务失控和数据隐私被不再受人类控制的机器侵犯之前，根据数据隐私、治理、FinOps 和策略标准运行人工智能应用程序至关重要。当然，数据不是唯一面临风险的东西。 将 AI 的优势与有效的管理和治理实践相结合是确保由新兴云技术驱动的可持续 AI 创新的关键。
24710编辑于 2024-09-01 - 来自专栏深度学习与python
技术债不是负担，而是成功的战略杠杆
如果领导团队连我们的技术栈都不了解，我又如何说服他们投资解决技术债的问题？ 很多这类问题都是出于这样一个信念：技术债应该尽可能地低到零。但公司和产品绝不会因为拥有尽可能少的技术债而取胜。 这就是说，你应该将技术债视为组织长期成功的战略杠杆。 要把技术债视为战略杠杆，你需要： 确认并努力解决围绕技术债的负面假设。 分类和区分技术债的类型。 评估技术债。 假设 1：技术债 = 坏账 假设 2：所有技术债 = 复杂的工作 假设 3：技术债 ≠ 产品工作 假设 4：个体痛苦 = 组织痛苦 2假设 1：技术债 = 坏账 毋庸置疑，技术债有着坏名声。 最好是把技术债分类，通过命名和评估痛苦来“打破”技术债，这样每个项目都可以独立存在，并且有机会被解决。在本文后面，我们将讨论命名和评估的问题。 有些技术债很好，每个团队都需要有技术债。 9你的战略技术债组合，基于公司的成长阶段 另一个战略性地解决技术债问题的方法是基于技术债类型和组织规模来确定技术债组合。
40720编辑于 2023-04-01 - 来自专栏一个正经的测试
使用 ChatGPT 提高代码质量并减少技术债
此功能使 ChatGPT 成为多方面的软件开发工具，有助于确保代码质量并避免技术债务。 代码异味会产生技术债务——选择需要未来返工的快速、简单的解决方案而不是现在花精力寻找更有效的解决方案的隐性成本。 ChatGPT 使开发人员能够解决代码质量问题并有效管理技术债务。 结论 如果有效且谨慎地使用，ChatGPT 可以帮助您提高代码质量并最大程度地减少技术债务。它有助于识别代码异味，并简化各种编程语言的重构。 这种人工智能驱动的方法彻底改变了软件开发，提高了效率和创新，从而使代码更简洁并降低了技术债务。立即开始尝试使用 ChatGPT 来改变您的编码实践。
71310编辑于 2024-01-27 - 来自专栏Spark学习技巧
@程序员，技术债你还清了吗？
但是，我们所有人（包括Reis和他的朋友）也都认识到，全心全意提供面向客户的功能是一个错误；这是导致我们陷入熟悉的“技术债务”的罪魁祸首，接下来就是“技术破产”，最终我们在恐惧中承认失败，所有工作都白费 我们的技术负责人知道。我们的首席技术官常常说起，有时甚至连CEO都熟悉“技术负债”的概念、以及技术人员对此的恐惧。 然而，在现实中，我们工作的重点依然没有变。“我现在没有时间该这个问题。” 他们也知道而且很担心技术债务，他们也想避免这种情况。 而且即便他们不想这么做，我们还有技术人员，保持技术方面的健康是技术领导团队的工作。 其次，根据我们以上的观察，维护是你的工作的一部分。 ? 尽管他们的技术负责人、首席技术官和同事每天都在讨论技术债务的忧患。这是为什么呢？你（或同事）因为交付对客户非常有利的功能，而受到称赞的情况有多少次？ ? 如果维护代码没有切实的奖励，那么你就会陷入技术负债。 我们怎样才能将开发人员100%投入到价值的精力转移到0%的维护工作上呢？简单来说，经理不能只是动动嘴皮子；不要再喋喋不休地讨论，如何解决技术债务。
47420发布于 2018-08-01
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号