私は開発者のチーム内で働いています。同じことがすでにコードベースに実装されている場合、誰もがあまり多くのことを行わずに変更を加えています。これにより、クラスが絶えず成長し、深刻な重複が発生します。
開発者がこのクラスの内容を判断できるように、クラス定義にラインアイテムを追加したいと思います。
それが役立つだろう?
VisualStudioでそれを行う方法は?
それが役に立たない場合、それを実装する前に何かが存在するかどうかを開発者に確認するように促すためのより良い代替手段は何でしょうか?
原因であるいくつかの問題があるかもしれません。
クラスが一般的すぎる/大きすぎる。
クラスUtils
がある場合、時間の経過とともに成長する可能性があります。怠惰によって、明らかに別のクラスに属していないすべてのものがこのクラスに入れられます。たとえば、誰かがStringToByteArray
メソッドを作成した場合、_static Utils
_クラスがあるのに、なぜその適切な場所を探すのに苦労するのでしょうか。
クラスが非常に大きくなると、何かがすでに実装されているかどうかを見つけることはほぼ不可能なので、人々はそれに独自のコードを追加するだけです。
コードは文書化されていません。
ドキュメントがない=どこにあるのかを知るのが難しい=どこにでも新しいメソッドを配置する。
命名規則はありません。
文字列をバイト配列に変換するメソッドの例を見てみましょう。変換に_X.ToY
_という名前を付けることを指定する命名規則ドキュメントがある場合(Xはソースタイプ、Yは宛先タイプ)、拡張メソッドpublic static ToByteArray(this string text)
を作成する必要があることは明らかです。 。作成する前に、拡張メソッドがすでに存在するかどうかを確認する(IntelliSenseに感謝)ことは明らかです。
命名規則がない場合は、次のようになる可能性があります。
this.BytesFromString("Hello")
"Hello".ToBytes()
"Hello".ConvertToArrayOfBytes()
Conversions.FromStringToByteArray("Hello")
new TypeConverter<string>("Hello").Convert<byte[]>()
と他の数十の亜種。どうやってそれらを見つけますか?
間違ったアーキテクチャの選択は元々行われました。
これ以上説明する必要はありません。アーキテクチャがナンセンスである場合、従うのは困難です。つまり、特定の方法がどこにあるべきかを推測することはほとんどできません。
コピー&ペーストはリファクタリングよりも優先されます。
リファクタリングの代わりに、コードがコードベース全体にコピーアンドペーストされると、メンテナンスが悪夢になるだけでなく(そして物事を見つけることも悪夢です)、最終的にコードをリファクタリングすると、少し違う動きをすることがあります。同じクラスのコードであり、2つのメソッドは同じことを行うことを目的としていますが、外観が大きく異なり、内部のコードを調べる時間がない場合は、両方のメソッドを保持します。
潜在的なバグを伴う不適切に記述されたコードは、コードベースで頻繁に発生します。
文字列からバイト配列への変換の例をもう一度見てください。開発者は変換を実行したいと考えており、コードベースで適切なメソッドConvertStringToByteArray
を見つけます。それでも、このメソッド内のコードは正しく記述されておらず、一部の文字列では失敗しているようです。製品は2日で配信される必要があるため、開発者はコード(メソッド内のコードと呼び出し元のコード)の調査に時間を費やしたくありません。代わりに、この開発者は独自のメソッドConvertStringToByteArrayCorrectly
を実装します。
開発者間のコミュニケーションの欠如または管理の問題があります。
開発者がConvertStringToByteArray
にバグがあることに気付いたと想像してみてください。彼はチケットを開いたり、ソースコードを書いた開発者と直接話したりすることができましたが、コードは、誰かが自分のコードのバグに気づいたときに嫌いで、誰かが自分のコードに触れるたびに悲鳴を上げる無能なジャークである主任開発者によって書かれています。彼の許可。このリード開発者は、会社のCEOの兄弟です。
開発者にとっての唯一の方法は、彼自身のメソッドを実装することです。
これらすべての場合において、重複は避けられず、VisualStudioは問題の解決に役立ちません。根本原因を最初に解決する必要があり、重複がなくなる可能性があります。
上記の内容を要約した2つの例を次に示します。
例1
あなたはプロセスや慣習などの重大な変更を必要とする会社で働き始めます。締め切りは近く、誰もがストレスを感じています。この配列をメソッドにストリーミングする前に、文字列をバイトの配列に変換する必要があるコードを記述するように求められます。コードベースを検索して、やりたいことを実行しているように見える4つのメソッドを見つけます。それらにはドキュメントがまったくなく、実装方法も大きく異なります。
i
とは何か、またリストを作成する理由がわからないため、最初のList<byte> ToBytes(string s, int i)
をスキップすることにしました。 2つ目は魅力的に見えますが、テストすると「ランダムに」失敗します。 3つ目を試してみますが、毎回Exception
がスローされます。この例外は、コードの172行目、3つの埋め込みループと4つのifの奥、gotoの直前で発生します。
最後に、4番目のものは良さそうですが、エンコーディングを指定する必要があります。
Stack Overflowから、 このような変換にはエンコーディングが必要ないことがわかります 。面白い。最後のメソッドをリファクタリングすることにしましたが、単体テストはまったくなく、メソッドはコードベースを介して数十回呼び出されるため、既存の機能が損なわれないかどうかはわかりません。
あなたはリード開発者にメソッドをリファクタリングできるかどうか尋ねることにしましたが、彼は忙しすぎて、そのような基本的な質問で彼を邪魔してはいけないとあなたに叫びます:彼の時間はそのためにはあまりにも重要です。
締め切りが迫っているので、独自のメソッドを作成することにしました。コードベースで物事にどのように名前を付けるかを理解しようとしますが、ロジックがまったくないようです。最終的に、新しいメソッドに最も適切と思われる名前を付けることになります。
例2
あなたは彼らの従業員と製品の品質を気にする会社で働き始めます。文字列をバイト配列に変換するコードを書くように求められます。
あなたは少し迷っていますが、同僚に質問しても大丈夫だということを知っています。巨大なコードベースから既存のコードをどのように検索するかを尋ねます。同僚は、命名規則のドキュメントを読む必要があること、およびアーキテクチャを説明するwikiもあることを親切に説明しています。
命名規則の文書から、変換は特定の工場を通じて行われているようです。賢明な選択ではありませんが、このドキュメントでは、これには歴史的な理由があり、コードベース全体を変更するにはコストがかかりすぎると説明されています。
変換は次のように行う必要があることが簡単にわかります。
_new Conversions
.Factory
.Create<byte[], string>()
.Convert("Hello")`
_
また、変換を行う既存のメソッドがあることもわかります。一方、既存のメソッドがエンコードを処理している間は、エンコードについて気にする必要がないという関連するStackOverflowの記事を読んだことがあります。
既存のコードを変更する必要があるかどうかを同僚に尋ねます。彼らは、コードを調査し、メソッドを効果的に改善できるとあなたに言うリード開発者を呼びます。
それは簡単な作業です。既存のコードは十分に明示的であり、正しく文書化されています。すばやく変更し、単体テストを再実行して、変更によって何も壊れていないことを確認します。その後、QA部門は、すべてが正常であることを確認します。
あなたはすでにその状況にあるように思われるので、私は提案します:
Visual Studio 2012の新機能 コードクローン検出 を使用します。
すべての同一および類似の上位25%をバックログに入力します。
複製を作成する人々にそれをクリーンアップさせます。
これを数回行うと、人々はもっと注意する必要があることに気づき始めます。
UltimateまたはPremiumエディションをお持ちでない場合は、CodeRushまたはResharperをご覧ください。同様の機能があります。