Question

当你看到这样的事情时，你会重构吗？或者你只是堵住鼻子继续前进？

    public Collection<DataValidationRuleBase> GetFieldValidationRules(String key)
    {
        Collection<DataValidationRuleBase> found = null;
        try
        {
            this.mRules.TryGetValue(key, out found);
        }
        catch (ArgumentException ex)
        {
            //log the error
            Log.Error(ExceptionHandling.BuildExceptionMessage(ex));
            return null;
        }
        return found;
    }

Answer 1

如果你是新人，那么继续前进。

如果你开始成为一名牛仔并在整个地方重构一些东西，特别是如果它与你正在做的事情无关，那么就不太可能好好看待它。即使你“知道”它会改进代码库，你可能会觉得自己“主动”，第一次搞砸它并引入之前工作的代码中的错误，对你来说看起来很糟糕。

我会记下你认为需要重构的所有事情，当你建立自己的声誉和对公司的信任时，你会有更多回归和改进的余地。

Answer 2

糟糕的程序员：

重构它，检查它，然后继续说下去。

优秀的程序员：

“嘿Neil，我遇到了这个方法，并且想知道为什么它是这样编写的......这里的返回null似乎是多余的，请注意我是否放弃它来清理代码一点点？或者是否有一个特定的原因你这样写的吗？“

Answer 3

如果它正在工作然后就这样离开，你永远不会知道如果你改变东西会发生什么

Answer 4

请勿在没有充分理由的情况下更改工作代码。

如果您认为某些代码存在问题，请将其指出给您的团队负责人，并让他决定如何处理该代码。

原因：

你不知道为什么原来的程序员做了些什么。这可能是白痴，或者他们可能有充分的理由去做。这可能是你是白痴，并没有掌握一些细微的代码（尽管其他程序员应该清楚地评论它，如果是这样的话！）
对代码的任何更改都需要重新测试，并且可能会在其他工作代码中引入新的错误。这不应该阻止我们重构以提高代码质量，但我们不应该在不仔细考虑的情况下改变我们认为错误的一切。
如果你“纠正”其他人的代码，你很有可能与你的队友产生怨恨和编码“战斗”。
你的团队负责人可以适当地处理它（让原来的程序员去完成任务，给团队讲课，或者让他们安静地修复等等），而且没有人知道你“指责”他们。并且你会得到老板的褐色点来指出这个缺陷......除非这是他的代码： - ）

（您还可以检查源代码管理以查看编写代码的人员）

Answer 5

删除任何标识贵公司（或之前的编码人员）的内容并将其发送至The Daily WTF：）

Answer 6

是的，如果你的新人，那么你不重构的东西，你只是做团队领导告诉你的事情

Answer 7

当你是新手时，请注意你告诉谁“垃圾”代码。他们极有可能编写它，或者他们以相同的方式编写代码。这是一个通过新工作摆脱错误的好方法。

Answer 8

经验法则：如果没有损坏，请不要修复它！

如果您是新手，并且您碰巧遇到了一些有臭味的代码，我建议不要更改代码，除非这样做是您目前正在进行的任何增强的一部分。

如果它似乎是一个主要问题，更可接受的替代方案是尝试为失败的案例编写单元测试，然后，根据您的公司通常如何处理这些问题，要么返回并修复它，或让测试人员遇到它并将其分配给适当的开发人员。

这种方法可能会让你获得一些布朗尼点，因为它表明你正在注意并积极主动，而不会在代码中引入潜在的副作用。

Answer 9

除非你在Dilbert-world工作，否则你要和你的经理谈谈。 “嘿，我觉得我发现了一个问题，这就是我想解决的问题。”随后进行讨论。您可以继续与原始开发人员交谈并进行一些人工接触。

这是一个复杂的问题？

Answer 10

我会根据我的假设编写一些单元测试（希望这不是你公司的外国想法），并留待它。

偶尔有（有效的？）原因，为什么代码写得奇怪，只能从失败的单元测试中看到，或者当新员工进行更改时才会看到。

后来，当我不是新人并且对代码库有了更好的理解时，我会进行重构。

这也有一个额外的好处，就是学习代码如何工作而不是牛仔 - 不管它有多么诱人：）

Answer 11

（差不多）每个公司员工人数都比工作量小的公司都会有技术债务或杂乱的代码。不幸的是，（几乎）每家公司都是这样的。

除非你是一个敏捷的组织或一个以低技术债务开始的项目，并且保持这种方式，否则对抗这种情况几乎是没有希望的。在时间压力下，我们都会编写这样的代码。事实上，即使是鲍勃叔叔在将它发布到书中之前，还有时间将bejesus重构出来之前，就会编写丑陋的代码。

如果你开始重构，你就有可能破坏某些东西。如果您的组织没有全面的单元测试，那么这不是您应该承担的风险。

清理技术债务是整个组织的决定，或者至少是项目方面的决定。不幸的是，它并不是以新人开始的。

Answer 12

TryGetValue做什么？

您是否需要始终跟踪错误？（记录事物）

有很多东西可以用这个东西有效

Answer 13

你对代码中对白痴的定义有点模糊。

如果是因为TryGetValue没有抛出 ArgumentException 而是抛出 ArgumentNullException ，那么你应该可以安全地修复它。

MSDN Dictionary.TryGetValue Method

当你是新人并且你一直看到愚蠢的事情时 - 你会重构它们吗？

13 个答案: