Questions tagged «technical-debt»

技术债务只是隐喻代码库中不良软件体系结构和软件开发最终结果的隐喻。

16
项目已接近完成，但程序上有意粉代码。我要重写还是继续尝试发送？[关闭]
我是一名初学者Web开发人员（一年的经验）。 毕业几周后，我得到了一份工作，为一家所有者不是很多技术人员的公司构建Web应用程序。他招募我是为了避免他的想法失窃，服务公司收取高昂的开发成本，并希望他有一个年轻的人来长期维护该项目（我被录用后很久才得出这些结论）。 当时我还是Cocky，拥有计算机科学文凭，我接受了这个提议，认为我可以构建任何东西。 我在做主。经过一些研究，我选择了PHP，并从纯PHP开始，没有对象，只有丑陋的过程代码。两个月后，一切都变得混乱了，很难取得任何进展。Web应用程序非常庞大。因此，我决定检查一个MVC框架，这将使我的生活更轻松。那就是我偶然发现PHP社区中一个很酷的孩子的地方：Laravel。我喜欢它，它很容易学习，因此我立即开始编码。我的代码看起来更简洁，更有条理。看起来很好。 但是同样，Web应用程序非常庞大。该公司迫使我交付第一个版本，显然他们希望部署该版本并开始寻找客户。 因为Laravel很有趣，所以让我想起了为什么我首先选择了这个行业-在陷入糟糕的教育体系时我忘记了这一点。 因此，我从晚上开始从事小型项目，了解方法和最佳实践。我回顾了OOP，然后进行了面向对象的设计和分析，并阅读了Bob叔叔的书Clean Code。 这使我意识到我真的一无所知。我不知道如何正确地构建软件。但是到现在为止为时已晚，现在我快完成了。我的代码根本不是干净的，仅仅是意大利面条式的代码，是修复错误的真正痛苦，所有逻辑都在控制器中，并且几乎没有面向对象的设计。 我一直坚持认为我必须重写整个项目。但是，我做不到……他们一直在问什么时候才能完成。 我无法想象此代码部署在服务器上。另外，我仍然对代码效率和Web应用程序的性能一无所知。 一方面，公司正在等待产品，不能再等待了。另一方面，我看不到实际代码会更进一步。我可以完成，总结并部署，但是上帝只知道人们开始使用它时会发生什么。 我要重写还是继续尝试发送，还是错过了另一个选择？
17
我如何说服管理层处理技术债务？
与开发人员一起工作时，我经常会问自己一个问题。到目前为止，我已经在四家公司工作，并且我意识到缺乏对保持代码干净和处理技术债务的关注，这些债务阻碍了软件应用程序的未来发展。例如，我工作的第一家公司是从头开始编写数据库，而不是使用MySQL之类的东西，并且在重构或扩展应用程序时给团队造成了麻烦。当经理讨论预测时，我一直试图与我的经理保持诚实和坦率，但是管理层似乎对修复已经存在的问题不感兴趣，并且看到它对团队士气的影响令人震惊。 您对解决此问题的最佳方法有何看法？我所看到的是人们收拾行装离开。然后，公司成为旋转门，开发人员进出，使代码变得更糟。您如何与管理层沟通，以使他们有兴趣解决技术债务？
19
处理无法看到用户无法立即看到的改进中的价值的管理
我能理解进度压力。您想取悦用户，因为它们是公司的生命线。但是，某些更改确实可以使以后的一切变得更容易。不幸的是，我组织中的管理层对这种变化有一种本能的抵制，而这种抵制是如此之强以至于阻碍了长期的改进。 例如，Apple最近为iOS程序引入了自动引用计数。这是对以前必须使用的手动保留/释放调用的重大改进。该代码更易于编写和维护。转换本身可能会导致某些崩溃。但是，一旦解决了这些问题，随机怪异崩溃的数量就可能减少。 我最近向老板提到，我想切换到自动引用计数。他的回答是他想专注于明显的改进。反过来，这种反应很可能是由于他从自己之上所承受的压力所驱动的-也许恰恰是来自首席执行官的压力。 有很多类似的例子。共同点是需要修复某些问题，但是修复的短期成本超过了短期收益，其中“短期”被定义为“未来几周内”。 我应该如何处理这种情况？ 编辑：感谢您的答复。让他们来。因为这与我的情况有关，所以我应该明确说明我的经理和CEO都是程序员-尽管CEO现在可能已经忘记了这是什么样子。显然，他们的程序员方面被其他压力所淹没。
11
DRY是软件项目管理的敌人吗？
DRY是软件开发中最基本且被广泛接受的原则之一（请不要重复自己）。同样清楚的是，大多数软件项目都需要某种管理。 现在有哪些易于管理的任务（估算，计划，控制）？正确的重复性任务，正是按照DRY应该避免的任务。 因此，从项目管理的角度来看，最好通过将现有代码复制100次并根据需要对每个副本进行一些较小的改动来解决任务。在任何时候，您都确切知道您已经完成了多少工作，还剩下多少。所有的经理都会爱你。 相反，如果您应用DRY原理并尝试找到某种或多或少消除重复代码的抽象，则情况有所不同。通常情况下有很多可能性，您必须做出决定，进行研究，发挥创造力。您可能会在较短的时间内提出更好的解决方案，但是您也可能会失败。大多数时候，您无法真正说出还剩下多少工作。您是项目经理的噩梦。 我当然在夸张，但显然存在两难选择。我的问题是：决定开发人员是否过度使用DRY的标准是什么？我们如何找到一个妥协的解决方案？还是有一种方法可以完全克服这一难题，而不仅仅是找到折衷方案？ 注意：此问题基于与我上一个主题相同的思想，即软件开发中的日常工作量及其对估计的影响，但我认为这使我的观点更加清楚，非常抱歉重复我的一遍:)。
11
如何量化项目中存在的技术债务金额？
有谁知道是否有某种工具可以将某种代码基础的技术债务作为一种代码指标？如果不是，是否有人知道它的算法或启发式方法？ 如果到目前为止这些东西都不存在，那么我将对如何开始使用这种东西感兴趣。也就是说，如何量化由方法，类，名称空间，程序集等引起的技术债务。 我对分析和评估C＃代码库最感兴趣，但也请随时注意其他语言，尤其是在概念是语言超越的情况下。
21
您如何向非技术人员解释重构？
您如何向非技术人员（通常是PHB或客户）解释重构（和技术债务）？（“什么，这要花我一个月的时间而没有明显的区别？！”） 更新感谢到目前为止的所有回答，我认为此列表将提供一些有用的类比，我们可以向相应的人员指出（尽管删除对PHB的引用可能是明智的！）
7
如何衡量重构的潜在价值
在具有技术债务的旧的大型项目中，如何可靠地估算或衡量重构代码的收益？ 例如，假设您在软件堆栈解决方案中有一些组件是用较旧的语言编写的，而某些较后的组件是用较新的语言编写的。开发团队将不断向该解决方案添加新功能和错误修复。 开发人员建议用新版本替换现有的旧语言组件将是“一件好事”。但是，这项工作不会增加任何额外的功能，这将花费x开发日。 销售人员建议添加“一项很棒的新功能”。公司通过使用公式来衡量他的建议的价值。即。它将在t年内以x开发日的工作成本为公司赚取F百万英镑。 公司如何以有意义的方式增加重构建议的成本？在什么情况下，这可能是公司最赚钱的选择？
6
您从处理技术债务中看到了什么收获？
关于技术债务的这篇文章有一些优点，包括： 当故事驱动时，处理“技术问题”最有效。代码库可能在任何地方都需要工作，但是由于面向用户的原因，只有在要处理代码的地方才能收到回报。如果没有故事要经过某个棘手的领域，那么在这方面的工作就会被浪费掉。 因此，我更喜欢像往常一样拍摄故事（但可能更少），并遵循“童子军规则”，使故事比您发现的更好。换句话说，无论故事指引到哪里，让我们编写更多测试，让我们更积极地重构。 这种方法至少具有以下优点： 保持“最明智”的故事流； 提供所有团队人才的帮助； 让整个团队学习如何保持代码干净； 将改进的重点放在需要的地方； 不会浪费“可能”需要的改进； 我已经看到代码质量对长期生产力有很大的影响，所以我相信应该处理技术债务。我认为上面的帖子很有道理，但是我对最后两点不太确定。我有兴趣了解清除技术债务带来的收益的真实经验，即使这与用户故事无关。 通过清理代码库和消除技术债务，您看到了哪些积极的好处？您使用什么方法来完成工作？
2
历史增长的软件是否有命名的反模式？[关闭]
是否有一种反模式来描述一个历史悠久的软件系统，其中多个开发人员只是向系统添加了新功能，但没有人真正关注整个体系结构，也从未进行过重构？ 我认为，当管理人员/客户不断要求新功能并且没有人重构任何东西而只是增加其他开发人员以前所做的事情时，就会发生这种情况。 原因还可能是开发人员对软件系统不知所措，并不真正了解它当前的工作方式，然后只是在最后添加/粘上了他的代码（而不是重构和更改代码）。 因此，随着时间的推移，维护系统变得越来越困难。 （我想知道是否有针对这种反模式的图片，以使所有编程人员都无法清楚了解它-就像一辆通过添加越来越多的功能而无需考虑整体设计而制造的汽车。就像有人需要拖曳拖车时向后骑，然后工程师只是将牵引杆焊接到汽车的前部。工作已经完成。但是现在，前围不再打开了。）
5
作为“最低开发商”与技术债务作斗争？
假设您在一家公司工作，而您所要做的就是为他们开发软件。您不了解总体情况，也可能不了解。您所拥有的是通过问题跟踪系统分配给您的任务。您得到了任务，使它们按照任务描述它们的方式工作，然后将其发回。像加2个整数： function add(a,b){return a + b;} 但是后来，随着项目的进行，您注意到随着add变得越来越复杂，您意识到它应该需要某种形式的体系结构，而不仅仅是添加参数并返回值的函数。但是，您不知道。首先，他们所需要的就是这么简单add。您没想到add会变得如此复杂。 该项目具有更多功能，而您最初没有想到这些功能。最后，您将不断堆积各种技巧和功能，以免破坏/重写现有代码。 您如何处理这些情况？作为“最低开发商”，您如何应对技术债务？ 澄清： 您是层次结构中最低的“实施者”。 您看到了问题，但对此没有发言权。 我不是在量化技术债务或寻找工具。 关于第三个“重复” 重构和重写-您被锁定在任务上。您无需支付额外费用。 体系结构概述-您了解整个系统，但不了解体系结构。 代码冻结-不是您的电话。您不是管理者。 模块化-不了解架构。模块随需求的变化而变化。 自动化测试-不存在。
6
“定制软件公司”如何处理技术债务？
此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 7年前。 什么是“定制软件公司”？ 所谓“定制软件公司”，是指主要通过构建定制的，一次性的软件来赚钱的公司。例如代理商或中间件公司，或像Redify这样的承包商/顾问。 “定制软件公司”的反面是什么？ 与上述业务模型相反的是专注于长期产品的公司，无论它们是可部署的台式机/移动应用程序还是SaaS软件。 确定技术债务的可靠方法： 我为一家试图专注于SaaS产品套件的公司工作。但是，由于某些限制，我们有时最终会屈从于某些客户的意愿，而我们最终会构建只能用于该客户的定制软件。 这是招致技术债务的肯定方法。现在，我们需要维护一些软件，这对我们的核心产品没有任何影响。 如果定制工作是增加技术债务的可靠方式，那么代理机构应如何处理呢？ 所以这让我开始思考。没有核心产品作为其业务模型中心的公司，他们总是在进行自定义软件工作。他们如何应对技术债务的概念？怎么不使他们陷入技术破产？
4
是否应该将技术债务安排为功能或杂项（或错误）？
我在Pivotal Tracker板上添加了一些解决一些技术问题的用户案例。我应该将它们视为特征（保持速度水平）还是杂务/虫子（降低速度）？我知道，如果我坚持一贯做下去，从长远来看不会有任何区别，但是每次我添加技术债务的故事时，我都必须做出决定。 一些想法： 它们实际上不是错误，它们不会破坏任何东西 用户没有要求任何东西，因为它是不影响他们的低级实施，但是它将使长期开发变得更容易 如果您将功能定义为能够为用户增加价值的故事，那么a）他们不会，因为用户不会看到任何直接的利益，但是b）它们会这样做，因为它们使将来的开发/维护成为可能，从而确实可以增加价值，只是现在不行 我不决定是否真正进行这项工作，或何时安排它，我只是想知道我应该在项目管理工具中称其为技术债务的原因，以及原因。
6
在可怕的数据库上编写好的代码是否有希望？
这是我的困境。我最近继承的几个程序之一是在后端使用可怕的数据库构建的。尊敬的创作者显然不喜欢关系概念。每个客户的表，称为唯一客户ID。八十三个隐式命名的字段。该代码都是带有数十个串联的内联SQL语句的程序性代码。 由于没有为我们提供可在同一数据库上运行的重要辅助应用程序，因此我不得不从头开始重新创建它。我是唯一的开发人员，这甚至都不是我的主要职责，因为我至少有一半的时间被操作员占用。从现在开始，不可避免的期限是30天。 尽管我没有经验，但是我敢肯定我可以设计出比以前更好的数据库和现有应用程序，但是我真的认为改变数据库，调整现有应用程序并确保我没有这样做是不现实的。在需要快速创建附加应用程序的同时不要破坏任何内容。 因此，假设我陷入了可怕的数据库。需要使用这样一个糟糕的结构，我写的任何符合它的东西，是否只会增加堆积如山的技术债务，直到一些事情完全崩溃或需要新功能时才被搁置？除了可以运行的应用程序之外，我该如何处理这种情况并从中获得好处？ 编辑：如果有人感兴趣，我们最终将这个可怕的数据库及其上运行的应用程序报废了。我们将辅助应用程序的创建（我没有参与设置）外包给了最终两个不同的承包商，他们最终都落在了我们头上，却一无所获。我最终不得不在三天之内赶出一个恐怖的，具有部分功能的修补程序，而该修补程序至今仍在使用。
9
总体而言：我们将如何维护遗留系统？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 纽约-爆炸使摩天大楼震颤，一条已有83年历史的蒸汽管发出了强有力的信息，即纽约和美国其他城市下方的管道，电线和铁条的英里数正在老化，并且可能变得危险地不稳定。 2007年7月关于曼哈顿爆裂的蒸汽管的故事 我们听说过软件腐烂和技术债务。 我们已经收到以下消息： “鲍勃叔叔”马丁-谁警告过我们“ 弄乱的后果 ”。 迈克尔·C·费瑟斯（Michael C. Feathers）-谁为我们提供了“有效使用旧版代码”的指南。 因此，软件工程界当然可以意识到这些问题。 但是，我觉得我们整个社会都不喜欢这些问题如何困扰工作系统和应用程序。 正如史蒂夫·麦康奈尔（ Steve McConnell）所说： ...与金融债务不同，技术债务不那么明显，因此人们可以轻松地忽略它。 如果这是真的，我相信是这样，那么我担心政府和企业可能会推迟对黑客的定期维护和防御，直到为时已晚。[很像纽约市和蒸汽管。] 我的问题： 有没有一种方法可以避免使用等效于NYC和蒸汽管道的软件？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.