Questions tagged «technical-debt»

我已经编程了几年，并且随着时间的流逝对C＃和JavaScript变得非常熟悉。我有一些较大的C＃和JavaScript项目，可以轻松浏览。我最近开始了一个PHP＆AngularJS项目，该项目以前没有使用PHP的经验。 PHP方面的流程变得越来越难以跟踪（JavaScript方面更大，但很容易实现），当我尝试通过它进行思考时，我想象一个纠结的线程。一开始我犯的主要设计错误就开始堆积起来，影响着我的设计。实施任何新技术都将花费越来越长的时间。 我的工作期限很紧，发现编写好的DRY SOLID代码变得越来越困难。随着设计时间的增加，复制/粘贴代码块以使其行为略有变化变得越来越具有吸引力。每当我必须进行上下文切换（从一个项目然后回到这个项目）时，也需要很长时间才能回到代码库，每当我回到该项目上工作时，我都会感到恐惧。 我可以采取什么步骤来解决这个问题？另外，还可能需要花费额外的时间来证明其合理性，因为我的老板不是开发人员，也不熟悉开发或软件的生命周期，因此解释起来可能比平时更为困难。

14 php  javascript  web-applications  code-smell  technical-debt 

我在两个月前加入了六个开发团队。人很好，一切都很好。但是越来越多的我观察到一种特别的心态。东西很快就被修复了，但以将来的可用性为代价，几乎没有测试，两个人高兴地承认，他们喜欢把知识带到脑海中，而不是写下来。 该如何处理？我想以身作则，但时间有限-我喜欢架构和实际实现这些东西。但是我担心，临时的心态会感染我，而不是在设计和代码上力求清晰，简单（这并不容易建立），我被无休止的黑客循环激化了-这没有局外人可以解耦-仅出于进度和管理的考虑。

13 architecture  coding-style  management  technical-debt 

我有一个朋友”。是的，我知道是个好的开始，但老实说，这不是我！ 基本上，他已经在一个成功的项目上工作了大约4年，困难之处在于技术债务已经赶上了，他发现几乎不可能停止对产品的支持（对此进行反复讨论）并实际进行实际开发。 我提出了各种建议，记录您的所有时间，创建故障单，不回复电子邮件等。与此相关的问题是，这似乎只是在提醒他，他没有完成任何“有用的”事情。 之所以发生技术债务，是因为首先要给产品带来很大的好处，即接受用户的请求和电话并迅速实施它们。 我想知道的是，有没有人建议他如何摆脱这种发车状态，其中很大一部分将改变用户的看法，以使他们不会以为自己会发声并期望得到一些东西。然后在那里做。 最好说计划得更好，尽管我知道考虑到支持的需求和用户的相对压力（见上文），很难计划实际的开发。

13 users  technical-debt  product-management 

我们工作时遇到一个主要问题，它的名称是“定制”。我们有一个旧的（超过10年的）供应商软件系统，我们的IT和会计部门以前喜欢对其进行自定义。沿线某个地方，该软件开始出现漏洞。然后，在完成大部分自定义之后，我被录用了。 我在系统中发现的几乎每个问题都是定制的直接结果。我们所做的一切更改都有破坏关键业务财务软件的风险。但是，会计部门一直在建议更改（因为我们总是说“是”！），似乎很少有人会对更改的影响程度有所尊重。 某些更改不会引起任何问题。可以在供应商软件中自定义表单，也可以将其自定义，我们可以在表单字段中移动，删除它们，等等。但是，对于像这样的每一个无害的自定义，它们还建议诸如存储过程和触发器之类的更改，以操纵供应商应用程序数据库中的数据。 我最近（勉强）让他们停止尝试将客户从一个供应商程序导入另一个供应商程序，因为这些信息是完全不兼容的。解决该问题的原因是因为我发现系统无法在用户端正常运行。任务比他们想象的要复杂，所以他们放弃了。无论用户端任务多么简单，都不应执行他们想要的操作。 我如何传达这种改变该系统工作方式的风险，尤其是在数据有效性受到威胁时？我是一名新员工（6个月），现在已经成为现状，但是这冒着我们财务数据和支持合同的有效性的风险-一旦供应商的支持人员听到“ X已被自定义”，这使他们有很多理由不这样做支持我们或告诉我们这是我们的错。

12 management  communication  technical-debt 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 每年吸吮更少-杰夫·阿特伍德 我看过这篇有见地的文章，直接从帖子中引用 我经常认为，每年吸吮更少是程序员谦虚的进步。您应该对一年前编写的代码不满意。如果不是，则意味着A）一年没有学到任何东西，B）您的代码无法改进，或C）您从不重访旧代码。所有这些对于软件开发人员来说都是垂死的吻。 这种情况多久发生一次或不发生在您身上？ 您需要多长时间才能看到编码方面的实际改进？月，年？ 您是否曾经浏览过您的旧代码？ 您的旧代码多久困扰您一次？或者您必须多久处理一次技术债务。 修复旧的错误和肮脏的代码（这可能是很痛苦的），我们可能会为了快速地按时完成任务而执行这些快速修复，在某些情况下，我们可能不得不重写大多数应用程序/代码。没有争论。 我遇到的一些开发人员争辩说，他们已经处在进化阶段，他们的编码不需要改进或无法得到改进。 这会发生吗？ 如果是这样，那么人们期望这种情况会发生多少年？ 有关： 是否曾经回头看过您的某些旧代码和痛苦中的鬼脸？ 代码中的 “ 星球大战时刻”：“卢克！我是你的代码！” “不！不可能！不可能！”

10 self-improvement  technical-debt