コア機能 (データベース ルックアップなど) を提供するために 200 の静的メソッドを持つ 1 つのクラスを使用する C# コードベースを継承したとします。そのクラスの多くの悪夢の中で、ハンガリー語表記 (悪い種類) が多用されています。
ハンガリー語表記を削除するために変数名をリファクタリングしますか、それともそのままにしますか?
すべての変数を変更してハンガリー語表記を削除することを選択した場合、どのような方法になりますか?
コア機能 (データベース ルックアップなど) を提供するために 200 の静的メソッドを持つ 1 つのクラスを使用する C# コードベースを継承したとします。そのクラスの多くの悪夢の中で、ハンガリー語表記 (悪い種類) が多用されています。
ハンガリー語表記を削除するために変数名をリファクタリングしますか、それともそのままにしますか?
すべての変数を変更してハンガリー語表記を削除することを選択した場合、どのような方法になりますか?
放っておいてください。あなたの時間のより良い使い方があります。
リファクタリング -- この規模のハンガリー語表記法は、コードの自然な読みやすさを実際に妨げていることがわかりました。演習は、そこにあるものに慣れるための良い方法です。
ただし、コード ベースを知っている他のチーム メンバーがいる場合は、リファクタリングに関するコンセンサスが必要であり、変数のいずれかが 1 つのプロジェクトの外部に公開されている場合は、それらをそのままにしておく必要があります。
変数名を右クリックし、リファクタリング -> 名前の変更。
これを行うVSアドインもありますが、組み込みの方法は私にとってはうまく機能します。
ハンガリー語表記には 2 種類あることを忘れないでください。
元の Charles Simonyi HN は、後に App's Hungarian として知られるようになり、後に System Hungarian と呼ばれる嫌悪すべき人物は、ペッカーヘッド (専門用語です) がSimonyi の元の論文を完全に読み違えてしまいました。
残念なことに、システム HN は Petzold などによって広められ、今日では正当に認められているより支配的な中絶になりました。
元の Apps Hungarian Notation の意図に関するJoel の優れた記事を読んで、急いで失われたことをお詫びします。
あなたが持っているのが App のハンガリー語である場合、元の Charles Simonyi の記事と Joel の記事の両方を読んだ後、おそらくそれを保持したいと思うでしょう。
System Hungarian の蒸し暑い山に着陸した場合は?
すべての賭けはオフです!
うわー!(鼻をつまんで言う) (-:
どうしましょう?コードを維持するだけで、重要な方法で書き直さなければならないと仮定しますか? よく放っておきましょう。コードを追加するときは、既存のスタイルを使用します。つまり、醜いハンガリー語の表記法を使用します (汚いと感じるほどです)。
しかし、ねえ、本当にリファクタリングをしたいのなら、一度に少しずつやってください。作業するたびに、変数の名前を変更するのに 10 分かかります。少し整理整頓。数か月後、口笛のようにきれいになっていることに気付くかもしれません....
運が良ければ、ハンガリー語をなくしたい場合は、使用されているハンガリー語の接頭辞を分離し、ファイル内で検索と置換を試みて、それらを何も置き換えずに、クリーンアップして再構築します。エラーの数が少ない場合は、修正してください。エラーの数が膨大な場合は、最初に戻って論理的な (ドメインごとの) クラスに分割してから、個別に名前を変更します (IDE が役立ちます)。
私はVB6の時代に宗教的にそれを使用していましたが、VB.NETが登場したときに停止しました.それは新しいVBガイドラインが言ったことだからです. 他の開発者はしませんでした。そのため、古いコードがたくさんあります。コードのメンテナンスを行うときは、触れた関数/メソッド/サブから表記を削除します。すべてに対して本当に優れた単体テストがあり、それらを実行して何も壊れていないことを証明でき ない限り、一度にすべてを削除することはありません。
これを行うと、どのくらい壊れますか?これは、自分自身に問いかける重要な質問です。そのライブラリを使用するコードが他にもたくさんある場合は、名前の変更作業を行うことで、人々 (おそらくあなた) のために作業を作成しているだけかもしれません。
リファクタリング時のやるべきことのリストに入れておきます。少なくとも、誰もがあなたがライブラリを (一時的に) 破壊することを期待しています。
とは言っても、私は名前が不十分なメソッドや変数に完全に不満を感じているので、関連付けることができます.
ハンガリー語表記を段階的に廃止する最善の方法は、コードを変更するときにコードをリファクタリングすることであることに同意します。この種のリファクタリングを行う最大の利点は、変更中のコードの周りに単体テストを記述して、既存の機能を壊さないことを期待する代わりにセーフティ ネットを作成する必要があることです。これらの単体テストを実施したら、コードを自由に変更できます。
もっと大きな問題は、200(!) 個のメソッドを持つ単一のクラスがあることだと思います!
これが非常に依存している/大幅に変更されたクラスである場合は、より使いやすくするためにリファクタリングする価値があるかもしれません。
この場合、Resharper は絶対に必要です (組み込みのリファクタリング機能を使用することもできますが、Resharper の方がはるかに優れています)。
関連するメソッドのグループを見つけてから、これらをリファクタリングして、まとまりのある小さなクラスにします。最新のコード標準に準拠するように更新します。
テスト スイートをコンパイルして実行します。
もっとエネルギーがありますか?別のクラスを抽出します。
使い古された - 問題ありません。明日戻ってきて、もう少しやります。ほんの数日で、あなたは獣を征服するでしょう.
@Boojiに同意します-他の正当な理由で既にコードにアクセスしている場合は、ルーチンごとに手動で実行してください。次に、最も一般的なものを邪魔にならないようにし、残りは誰が気にするかを説明します。
私は同様の質問をすることを考えていましたが、私の場合のみ、問題のあるコードは私自身のものです。私は、FoxPro の時代から「悪い種類の」ハンガリー語を使用するという非常に古い習慣を持っています (これは型付けが弱く、スコーピングが異常でした) — 最近やめたばかりの習慣です。
それは難しいです — コードベースで一貫性のないスタイルを受け入れることを意味します。やっと「ねじ込み」と言い、文字「p」なしでパラメーター名を始めたのは、ほんの 1 週間前のことでした。私が最初に感じた認知的不協和は、解放感に取って代わられました。世界は終わりませんでした。
私がこの問題に取り組んできた方法は、一度に 1 つの変数を見つけたら変更し、戻ってきてさらに詳細な変更を行うときに、さらに抜本的な変更を実行することです。あなたが私のような人であれば、変数の命名法が異なるため、しばらくの間、あなたは夢中になりますが、ゆっくりと慣れていくでしょう. 重要なのは、必要な場所にすべてが揃うまで、一度に少しずつ削ることです。
または、変数を完全に放棄して、すべての関数が 42 を返すようにすることもできます。
私はそれからプロジェクトを作りません。VS でリファクタリング ツールを使用し (実際には Resharper を使用しますが、VS は問題なく動作します)、変更を求められたメソッドのすべての変数を修正します。または、大規模な変更を行う必要がある場合は、理解するために呼び出されたメソッドで変数名をリファクタリングします。
削除して変更する正当な必要がある場合は、組み込みのリファクタリング ツールまたは Resharper などを使用します。
しかし、私はクリス・コンウェイに特定の観点で同意し、その理由を尋ねます。はい、それは迷惑ですが、同時に、多くの場合、「壊れていない場合は修正しないでください」という方法は本当に最高の方法です!
直接使用する場合のみ変更してください。また、適用できるテストベンチを用意して、引き続き機能することを確認してください。
より大きな問題は、その 200 メソッドのGod Objectクラスにあるように思えます。ハンガリー語の表記を削除するためだけのリファクタリングは、それ自体価値が低く、リスクの高いアクティビティであることをお勧めします。リファクタリングにある程度の自信を持たせるために、そのクラスの周りに大量の自動化された単体テストがない限り、それは本当にそのままにしておくべきだと思います。
そのような一連のテストが存在する可能性は低いと思います。なぜなら、TDD の実践に従う開発者は、(願わくば) そもそも神のオブジェクトを構築することを自然に避けているからです - 包括的なテストを書くことは非常に難しいでしょう。
ただし、神のオブジェクトを排除し、単体テストのベースを配置することには、より価値があります。私のアドバイスは、クラス自体をリファクタリングする機会を探すことです-おそらく、そのコードの変更を必要とする適切なビジネス要件/変更が発生した場合(したがって、システムと回帰テストの購入と支払いが伴うことを願っています)。一度にすべてをリファクタリングする努力を正当化することはできないかもしれませんが、機会があれば少しずつリファクタリングを行い、変更をテストドライブすることはできます。このようにして、スパゲッティ コードを包括的な単体テストを使用して、少しずつよりクリーンなコード ベースにゆっくりと変換できます。
必要に応じて、ハンガリー人を排除することもできます。
私は実際にここでアプリケーション拡張のために同じことをしています。私のアプローチは、VIM マッピングを使用して特定のハンガリー語表記の接頭辞を検索し、それらを削除して、必要に応じて大文字を修正することでした。
例 (vimrc に入る):
"" Hungarian notation conversion helpers
"" get rid of str prefixes and fix caps e.g. strName -> name
map ,bs /\Wstr[A-Z]^Ml3x~
map ,bi /\Wint[A-Z]^Ml3x~
"" little more complex to clean up m_p type class variables
map ,bm /\Wm_p\?[A-Z]^M:.s/\(\W\)m_p\?/\1_/^M/\W_[A-Z]^Mll~
map ,bp /\Wp[A-Z]^Mlx~
リファクタリングのためだけにコードを壊すつもりなら、そのコードに依存している可能性のあるチーム内の他の人に影響を与えるつもりなら、特に i を放っておくことを真剣に検討します。
あなたのチームがこのリファクタリングに問題がなく、これを行うことに時間を費やしている場合 (コードがより読みやすく/保守しやすいことを意味する場合、将来的に時間の節約になる可能性があります)、Visual Studio (または使用している任意の IDE) を使用します。 ) コードのリファクタリングに役立ちます。
ただし、このような大きな変更が、チームや上司が進んでリスクを負うものではない場合は、やや非正統的で中途半端なアプローチをお勧めします。すべてのリファクタリングを 1 回のスイープで行うのではなく、通常のメンテナンス中に変更する必要があるコードのセクション (具体的には関数) をリファクタリングしてみませんか? 時間の経過とともに、このゆっくりとしたリファクタリングによってコードがクリーンな状態になり、その時点で最終的なスイープでリファクタリング プロセスを終了できます。
HN を削除するには、次の Java ツールを使用します。
または、以下のように「replace」/「replace all」を正規表現で使用して、「c_strX」を「x」に置き換えます。
ハンガリー語表記が大好きです。なぜそれを取り除きたいのか理解できません。