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

悪いプログラマー:

リファクタリングしてチェックインし、一言も言わずに先に進みます。

優れたプログラマー:

「ねえニール、私はこのメソッドに出くわし、なぜこのように書かれたのか疑問に思いました。ここでnullを返すのは冗長なようです。コードを少しクリーンアップするためにドロップしてもかまいませんか?それとも、あなたが書いた特定の理由がありますか?そんな?」

于 2009-09-03T19:57:50.753 に答える
10

それが機能している場合は、このままにしておきます。何かを変更した場合に何が起こるかを知ることはできません。

于 2009-09-03T19:10:56.513 に答える
8

正当な理由なしに動作中のコードを変更しないでください。

コードに何か問題があると思われる場合は、チームリーダーに指摘し、チームリーダーにそのコードをどうするかを決定させます。

理由:

  • 元のプログラマーがなぜ何かをしたのかわかりません。それはばかかもしれません、あるいは彼らは彼らがしたことの確かな理由を持っているかもしれません。あなたがばかで、コードの微妙な部分を把握していない可能性があります(ただし、その場合は、他のプログラマーが明確にコメントしているはずです!)

  • コードに変更を加えると、再テストが必要になり、他の方法で機能するコードに新しいバグが発生する可能性があります。それはコード品質を改善するためのリファクタリングを止めるものではありませんが、慎重に検討せずに間違っていると思うものすべてを変更するだけではいけません。

  • 他の人のコードを「修正」すると、恨みを生み出し、チームメイトとの「戦い」をコーディングする可能性が高くなります。

  • チームリーダーは、あなたが「指を向けた」ことを誰も知らなくても、適切に対処できます(元のプログラマーにタスクを任せたり、チームに講義したり、静かに修正したりするなど)。そして、あなたは欠陥を指摘するためにあなたの上司と一緒にブラウニーポイントを得るでしょう...それが彼のコードでない限り:-)

(ソース管理をチェックインして、誰がコードを書いたかを確認することもできます)

于 2009-09-03T19:26:47.583 に答える
5

あなたの会社(または以前のコーダー)を識別するものをすべて取り除き、それらをTheDailyWTFに送信します:)

于 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:48:56.970 に答える
1

(Almost) Every company that has a smaller headcount than its workload warrants will have technical debt or messy code. Unfortunately, (almost) every company is like that.

Unless you're in an agile organization or in a project that started out with low technical debt, and kept it that way, fighting this is almost hopeless. Under time pressure, we all write code like that. In fact, even Uncle Bob writes ugly code before he has the time to refactor the bejesus out of it prior to posting it in a book.

If you start refactoring things, you're running the risk of breaking something. If your organization does not have comprehensive unit tests, that's not a risk you should be taking.

Cleaning up technical debt is an organization-wide decision or at least project-side. It doesn't start with the new guy, unfortunately.

于 2009-09-03T19:53:47.097 に答える
1

ディルバートの世界で働いていない限り、上司と話をします。「ねえ、私は問題を見つけたと思います、そしてこれは私がそれを修正したい方法です。」議論が続きます。元の開発者と話をするために進むかもしれません、そして、いくらかの人間の接触が起こります。

これはどのように複雑な問題ですか?

于 2009-09-03T19:20:10.657 に答える
0

TryGetValueは何をしますか?

常にエラーを追跡する必要がありますか?(伐採物)

このことで有効になる可能性のあることがたくさんあります

于 2009-09-03T19:13:00.723 に答える
0

あなたはコードでのばかげた定義について少し漠然としています。

TryGetValueがArgumentExceptionをスローせず、代わりにArgumentNullExceptionをスローすることが原因ある場合は、安全に修正できるはずです。

MSDNDictionary.TryGetValueメソッド

于 2009-09-03T19:29:38.093 に答える