0

当你看到这样的事情时,你会重构吗?还是你只是塞住鼻子继续前进?

    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;
    }
4

13 回答 13

31

如果你是新人,你继续前进。

如果您开始成为一名牛仔并到处重构东西,那么它不太可能被看好,特别是如果它与您正在从事的工作无关。即使您“知道”它会改进代码库,并且您可能会觉得自己“采取主动”,但当您第一次搞砸并在以前工作的代码中引入错误时,它看起来对您来说非常糟糕。

我会记下您认为需要重构的所有内容,当您在公司建立声誉和信任时,您将有更多的回旋余地来改进。

于 2009-09-03T19:10:37.717 回答
13

坏程序员:

重构它,检查它,然后一言不发地继续前进。

优秀的程序员:

“嘿,尼尔,我遇到了这个方法,想知道为什么要这样写..这里的 return null 似乎是多余的,介意我是否放弃它来清理代码?或者你写它有什么具体原因像那样?”

于 2009-09-03T19:57:50.753 回答
10

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

于 2009-09-03T19:10:56.513 回答
8

不要无故更改工作代码。

如果您认为某些代码有问题,请向您的团队负责人指出,并让他决定如何处理。

原因:

  • 你不知道原来的程序员为什么要这么做。这可能是愚蠢的,或者他们的所作所为可能有充分的理由。很可能你是个白痴并且没有掌握代码的一些微妙之处(尽管如果是这种情况,其他程序员应该清楚地评论它!)

  • 对代码的任何更改都需要重新测试,并且可能会在其他工作代码中引入新的错误。这不应该阻止我们进行重构以提高代码质量,但我们不应该只是改变我们认为错误的一切而不仔细考虑它。

  • 如果您“更正”其他人的代码,那么您很有可能会产生怨恨并与您的队友进行“战斗”。

  • 你的团队领导可以适当地处理它(让最初的程序员完成任务,给团队讲课,或者悄悄地修复它等),而没有人知道你“指责”他们。而且你会因为你的老板指出缺陷而获得布朗尼积分......除非这是他的代码:-)

(您也可以在源代码管理中查看代码是谁编写的)

于 2009-09-03T19:26:47.583 回答
5

删除任何可以识别您公司(或以前的编码员)的内容并将它们发送到The Daily WTF :)

于 2009-09-03T19:12:18.307 回答
2

是的,如果你是新人,那么你不要重构东西,你只要按照团队负责人告诉你的去做

于 2009-09-03T19:12:34.343 回答
2

当您是新手时,请注意您告诉谁“废话”代码。很有可能是他们编写的,或者他们以相同的方式编写代码。这是在新工作中走错路的好方法。

于 2009-09-03T19:15:49.077 回答
2

经验法则:如果它没有坏,就不要修理它!

如果您是新人,并且碰巧遇到了一些难闻的代码,我不建议您更改代码,除非这样做是您当前正在进行的任何增强功能的一部分。

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

这种方法可能会为您赢得一些布朗尼积分,因为它表明您正在关注并积极主动,而不会在代码中引入潜在的副作用。

于 2009-09-03T19:41:47.830 回答
1

除非你在呆伯特世界工作,否则你会和你的经理谈一谈。“嘿,我想我发现了一个问题,这就是我想解决的问题。” 讨论随之而来。您可能会继续与原始开发人员交谈,并且会进行一些人际接触。

这是一个复杂的问题吗?

于 2009-09-03T19:20:10.657 回答
1

我通常会根据我的假设编写一些单元测试(希望这在您的公司中不是一个陌生的想法),然后就这样了。

偶尔有(有效的?)为什么代码写得奇怪的原因只能从失败的单元测试或新员工进行更改时看到。

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

这还有一个额外的好处,那就是在不成为牛仔的情况下了解代码是如何工作的——不管它有多诱人:)

于 2009-09-03T19:48:56.970 回答
1

(几乎)每家员工人数少于其工作量的公司都会有技术债务或混乱的代码。不幸的是,(几乎)每家公司都是这样的。

除非你在一个敏捷的组织中,或者在一个以低技术债务开始并保持这种状态的项目中,否则与之抗争几乎是没有希望的。在时间压力下,我们都这样写代码。事实上,即使是 Bob 叔叔,在他有时间在把它写进书之前重构它之前,也写出了丑陋的代码。

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

清理技术债务是组织范围内的决策,或者至少是项目方面的决策。不幸的是,它不是从新人开始的。

于 2009-09-03T19:53:47.097 回答
0

TryGetValue 是做什么的?

您需要始终跟踪错误吗?(记录的事情)

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

于 2009-09-03T19:13:00.723 回答
0

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

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

MSDN Dictionary.TryGetValue 方法

于 2009-09-03T19:29:38.093 回答