ボーイスカウトルールと日和見的リファクタリングとコードレビューの調整

私はボーイスカウトルールを大いに信じています。

オリジナルの作者が誰であっても、モジュールを改善するためにどんなに小さな努力をしたとしても、結果はどうなるでしょうか？すべてがその単純なルールに従っており、ソフトウェアシステムの容赦ない劣化の終わりが見えますが、代わりに、システムが進化するにつれて徐々に改善されていきます。自分の小さな部分を気遣うだけの個人よりも。

私はまた、日和見的リファクタリングの関連するアイデアを強く信じています。

いくつかのスケジュールされたリファクタリングの努力のための場所がありますが、私は、いつでもどこでもコードをクリーンアップする必要があるとき、誰によってでも行われる日和見的な活動としてリファクタリングを奨励することを好みます。これが意味することは、誰かがそれほど明確でないコードを見たときはいつでも、すぐにそれを修正する機会をとるべきだということです-少なくとも数分以内に

特に、リファクタリングの記事からの次の抜粋に注意してください。

私は日和見的リファクタリングの摩擦を引き起こす開発慣行には警戒しています...私の感覚では、ほとんどのチームは十分なリファクタリングを行っていないので、人々がそれを行わないよう注意を払うことが重要です。これを洗い流すのを助けるために、小さなリファクタリングを行うことを思いとどまるときはいつでも気をつけてください。確かに1、2分しかかかりません。そのような障壁は、会話を促す匂いです。そのため、落胆のメモを取り、チームに報告してください。少なくとも、次の回顧展で議論する必要があります。

私が働いているところでは、大きな摩擦を引き起こす開発プラクティスが1つあります。それは、コードレビュー（CR）です。「割り当て」の範囲にないものを変更するたびに、レビュー担当者に非難され、変更をレビューしにくくします。これは、リファクタリングが関係する場合に特に当てはまります。「行ごと」の比較比較が困難になるためです。このアプローチはここでの標準です。つまり、日和見的リファクタリングはめったに行われず、「計画された」リファクタリング（通常は少なすぎる、遅すぎる）が行われます。

私は、メリットはそれだけの価値があり、3人のレビュアーが少し一生懸命に働くと主張しています（変更された行の狭い範囲を見るのではなく、実際に前後のコードを理解するために-レビュー自体はそれだけで良いでしょう） ）コードを読んで保守する次の100人の開発者が恩恵を受けるように。この論点をレビューアーに提示すると、同じCRにない限り、リファクタリングに問題がないと彼らは言います。しかし、私はこれが神話だと主張しています：

（1）ほとんどの場合、課題の最中に何をどのようにリファクタリングしたいかを認識するだけです。マーティン・ファウラーが言うように：

機能を追加すると、追加するコードに既存のコードとの重複が含まれていることに気付くため、既存のコードをリファクタリングしてクリーンアップする必要があります...何か機能するかもしれませんが、既存のクラスとの相互作用が変更された場合に優れています。自分が完了したと考える前に、その機会にそれを行ってください。

（2）実行するはずのない「リファクタリング」CRをリリースすることを好む人はいません。CRには一定のオーバーヘッドがあり、マネージャーはリファクタリングに「時間を浪費する」ことを望んでいません。行うべき変更にバンドルされている場合、この問題は最小限に抑えられます。

問題はResharperによって悪化します。変更に追加する各ファイル（および最終的にどのファイルが変更されるか正確に知ることはできません）には、通常、エラーと提案が散らばっています。修正。

最終的な結果は、ひどいコードが表示されることであり、そのまま残します。皮肉なことに、このようなコードを修正しても私の地位が向上するだけでなく、実際にはそれらを下げて、仕事をする代わりに誰も気にしないものを修正する時間を無駄にする「焦点のない」男として描く 私は本当に悪いコードを軽deし、それを見て我慢できず、私のメソッドからそれを呼び出すことができないので、私はそれについて悪いと感じています！

この状況をどのように解決できるかについての考えはありますか？

さて、ここにはコメントにふさわしいものよりも多くのものがあります。

tl; dr

あなたがすべきこと（あなたが行くにつれてリファクタリング）についてのあなたの直感は正しいです。

これを実装する難しさ-貧弱なコードレビューシステムを回避しなければならないことを考えると-は、ソースコードとVCSを操作する難しさに帰着します。複数の人が、変更を（ファイル内でも）複数のコミットに分割することができるし、そうすべきだと言っていますが、これを信じるのは難しいようです。

あなたは本当にこれを行うことができます。それが本当に私たちが提案していることです。編集、ソース操作、およびバージョン管理ツールを最大限に活用することを本当に学ぶ必要があります。それらを上手に使用する方法を学ぶことに時間を費やせば、人生はずっと楽になります。

ワークフロー/オフィスの政治問題

私は基本的にGlenH7と同じ推奨事項を作成し、2つのコミットを作成することをお勧めします。1つはリファクタリングのみを行い（明らかにまたは明らかに）機能の変更を行わず、もう1つは問題の機能の変更を行います。

ただし、多くのエラーが見つかった場合は、単一のCR内で修正する単一のカテゴリのエラーを選択すると便利です。次に、「重複除去コード」、「type-Xエラーの修正」などのコメントを含む1つのコミットがあります。これにより、おそらく複数の場所で単一のタイプの変更が行われるため、レビューするのは簡単です。見つけたすべてのエラーを修正できるわけではありませんが、密輸するのが簡単になります。

VCSの問題

作業中のソースに加えられた変更を複数のコミットに分割することは困難ではありません。使用しているものは言っていませんが、可能なワークフローは次のとおりです。

1. gitを使用している場合、このための優れたツールがあります

   • git add -iコマンドラインからインタラクティブなステージングに使用できます
   • git gui個々のハンクと行を使用して選択してステージングできます（これは、コマンドラインよりも実際に好む数少ないVCS関連のGUIツールの1つで、もう1つは優れた3ウェイマージエディターです）
   • たくさんの小さなコミット（個々の変更、または同じクラスのバグを複数の場所で修正）を作成し、それらを再配列、マージ、または分割できます。 rebase -i

2. gitを使用していない場合、VCSにはこの種のツールがまだあるかもしれませんが、どのシステムを使用しているか知らずにアドバイスすることはできません

   TFSを使用していると述べましたが、TFS2013以降はgitと互換性があると思います。リポジトリのローカルgitクローンを使用して試してみる価値があります。これが無効になっている場合、または機能しない場合は、ソースをローカルgitリポジトリにインポートし、そこで作業して使用することができます最終コミットをエクスポートします。

3. diffやなどの基本的なツールにアクセスできる場合は、任意のVCSで手動で実行できますpatch。もっと痛いですが、確かに可能です。基本的なワークフローは次のとおりです。

   1. すべての変更、テストなどを行います。
   2. diff最後のコミット以降のすべての変更を含む（コンテキストまたは統合）パッチファイルを作成するために使用します
   3. それを2つのファイルに分割します。リファクタリングを含む1つのパッチファイルと、機能の変更を含む1つのパッチファイルになります。
      • これは完全に簡単ではありません-emacs diffモードなどのツールが役立つ場合があります
   4. すべてをバックアップする
   5. 最後のコミットに戻りpatch、パッチファイルの1つを再生するために使用し、それらの変更をコミットします
      • NB。パッチがきれいに適用されなかった場合は、失敗したハンクを手動で修正する必要がある場合があります
   6. 2番目のパッチファイルに対して5を繰り返します

これで、2つのコミットがあり、変更が適切にパーティション分割されました。

おそらくこのパッチ管理を簡単にするツールがあることに注意してください-gitが私のためにそれを行うので、私はそれらを使用しません。

私はあなたの会社で変更要求が大きくて正式であると仮定します。そうでない場合は、（可能な場合）変更を多くの小さなコミットに変更します（想定どおり）。

この状況をどのように解決できるかについての考えはありますか？

あなたがやっていることを続けますか？

つまり、あなたの考えや推論はすべて完全に正しいです。表示されているものを修正する必要があります。人々は計画的なリファクタリングを十分に行いません。そして、グループ全体にとっての利益は、いくつかの不便さよりも重要です。

助けになるのは戦闘性を低くすることです。コードレビューは「なぜそれをしたのですか？」という戦闘的なものではなく、「みんな、私がここにいる間にこのすべてを修正しました！」その文化を変えるために（可能であればあなたのリード/マネージャーと）働くことは難しいですが、高機能の開発チームを作るためには非常に重要です。

同僚と一緒にこれらのアイデアの重要性を高めるために、（可能であればリード/マネージャーと）協力することもできます。「なぜ品質を気にしないのか」と尋ねてください。「なぜあなたはいつもこれらの役に立たないことをしているのか？」と尋ねる代わりに。

私はあなたの状況に多くの同情を持っていますが、具体的な提案はほとんどありません。他に何もなければ、状況が悪いほど悪化する可能性があると納得するでしょう。常に悪化する可能性があります。:-)

まず、あなたは（少なくとも）あなたの文化に関して、1つだけではなく2つの問題を抱えていると思います。1つの問題はリファクタリングへのアプローチですが、コードレビューは別の問題のようです。考えを分けようとします。

コードレビュー

私はコードレビューをHATEDしたグループにいました。グループは、会社の別々の部分の2つのグループを統合することによって形成されました。私は数年間コードレビューを行ってきたグループから来ましたが、一般的には良い結果が得られました。私たちのほとんどは、コードレビューが私たちの時間をうまく利用していると信じていました。私たちはより大きなグループに統合しましたが、私たちが知る限りでは、「他の」グループはコードレビューを聞いたことがありませんでした。今、私たちはすべて「彼らの」コードベースに取り組んでいました。

合併したとき、物事はうまくいきませんでした。新機能は、毎年6〜12か月遅れでした。バグのバックログは巨大で、成長し、生命を奪いました。コードの所有権は強く、特に最も上級の「達人」の間では強かった。「機能ブランチ」は時々数年続き、いくつかのリリースにまたがりました。時にはNOBODYですが、1人の開発者がメインブランチに到達する前にコードを見ました。実際には、「機能ブランチ」は、コードがリポジトリのどこかにあったことを示唆しているため、誤解を招きます。多くの場合、それは開発者の個々のシステムでのみ行われていました。

経営陣は、品質が許容できないほど低くなる前に「何かをする」必要があることに同意しました。:-)彼らの答えはコードレビューでした。コードレビューは、すべてのチェックインの前に、公式の「hou」アイテムになりました。使用したツールはレビューボードでした。

私が説明した文化ではどのように機能しましたか？何よりも優れていますが、それは苦痛であり、コンプライアンスの最小レベルに到達するのに1年以上かかりました。私たちが観察したいくつかのこと：

1. 使用するツールは、特定の方法でコードレビューに集中する傾向があります。これは問題になる可能性があります。Review Boardは、素敵でカラフルな行ごとの差分を提供し、コメントを行に添付できます。これにより、ほとんどの開発者は、変更されなかったすべての行を無視します。小さな、孤立した変更には問題ありません。大きな変更、大量の新しいコード、または名前が変更された関数のインスタンスが500行あり、10行の新機能が混在しているコードにはあまり適していません。
2. かつてほとんどレビューされたことのない古い病気のコードベースにいましたが、レビュー担当者が変更行ではないものにコメントしたり、明らかなバグを指摘したりすることは「不適切」になりました。「気にしないでください。これは重要なチェックインであり、バグを修正する時間がありません。」
3. 「簡単な」レビュー担当者を探してください。一部の人は、2000行変更された10ファイルのレビューを3分間見て、「Ship It！」をクリックします。誰もがすぐにそれらの人々が誰であるかを学びます。コードをそもそもレビューしたくない場合は、「簡単な」レビュアーに送信してください。チェックインが遅くなることはありません。彼のコードの「簡単な」レビュアーになることで好意を返すことができます。
4. コードレビューが嫌いな場合は、レビューボードから受け取ったメールを無視してください。チームメンバーからのフォローアップを無視します。数週間。キューに3ダースのオープンレビューがあり、グループ会議に数回名前が表示されるまで。その後、「簡単な」レビュアーになり、昼食前にすべてのレビューをクリアします。
5. 「ハード」レビューアにコードを送信しないでください。（このような質問をしたり、答えたりする開発者のようなものです。）簡単なレビューを学ぶのと同じように、誰もが「ハード」レビュアーが誰であるかをすぐに学びます。コードレビューが時間の無駄（™）である場合、自分が所有するコードに関する詳細なフィードバックを読むことは、時間の無駄（™）であると同時にin辱でもあります。
6. コードレビューが苦痛なとき、人々はそれらを延期し、より多くのコードを書き続けます。コードレビューの数は少なくなりますが、それぞれが大規模です。より多くの、より小さなコードレビューが必要です。つまり、チームは、できる限り痛みを伴わない方法を見つける必要があります。

コードレビューについていくつかの段落を書くつもりだと思っていましたが、ほとんどは文化について書いていたことがわかりました。要するに、コードレビューはプロジェクトに適している可能性がありますが、チームには得られるメリットしかありません。

リファクタリング

私のグループは、コードレビューを嫌う以上にリファクタリングを軽んじましたか？もちろん！すでに述べたすべての明白な理由のために。あなたは厄介なコードレビューで私の時間を無駄にしていて、機能を追加したりバグを修正したりすることすらありません！

しかし、コードは依然としてリファクタリングを切実に必要としていました。どうやって進める？

1. リファクタリングの変更と機能の変更を混同しないでください。多くの人がこの点に言及しています。コードレビューが摩擦点である場合、摩擦を増加させないでください。もっと手間がかかりますが、別のレビューと別のチェックインを計画する必要があります。
2. 小さく始めます。非常に少ない。それよりもさらに小さい。非常に小さなリファクタリングを使用して、リファクタリングとコードレビューは純粋な悪ではないことを徐々に人々に教えます。1週間に1回の小さなリファクタリングであまり苦痛なくこっそりできるなら、2、3か月で1週間に2回のリファクタリングが可能になるかもしれません。そして、彼らは少し大きくすることができます。何もないよりマシ。
3. 基本的に単体テストはありませんでした。リファクタリングは禁止されていますよね？必ずしも。いくつかの変更については、コンパイラが単体テストです。テストできるリファクタリングに焦点を合わせます。テストできない場合は、変更を避けてください。代わりに、単体テストの作成に時間を費やすかもしれません。
4. 一部の開発者は、すべてのコード変更が怖いため、リファクタリングが怖いです。このタイプを認識するのに長い時間がかかりました。コードのチャンクを作成し、それが「機能する」までいじってから、決して変更したくない。彼らは必ずしもそれがなぜ機能するのか理解していない。変更は危険です。彼らは自分自身を信じて何の変化ももたらさず、確かにあなたを信頼しません。リファクタリングは、振る舞いを変えない小さな安全な変更に関するものと想定されています。「振る舞いを変えない変更」という考えが考えられない開発者がいます。これらの場合に何を提案すればよいかわかりません。あなたは彼らが気にかけない分野で仕事をしようとしなければならないと思います。このタイプが長くなる可能性があることを知ったとき、私は驚きました、

なぜあなたは両方をしませんが、別々のコミットでですか？

あなたの仲間にはポイントがあります。コードレビューでは、他の人によって変更されたコードを評価する必要があります。 あなたはそれが校閲としての役割をバイアスとして、あなたが他の誰かのために見直しているコードには触れてはいけません。

しかし、いくつかの明白な問題が見られる場合は、2つの選択肢があります。

1. コードレビューがそれ以外の場合は問題ない場合は、レビューした部分をコミットしてから、2回目のチェックインでコードをリファクタリングします。

2. コードレビューに修正が必要な問題がある場合は、Resharperの推奨事項に基づいてリファクタリングするよう開発者に依頼してください。

個人的には、コミット後のコードレビューのアイデアが嫌いです。コードを変更すると、コードのレビューが行われます。私がここで話しているのはもちろんペアプログラミングです。ペアリングすると、レビューが無料で取得でき、コードレビューが向上します。今、私はここで私の意見を表明しています、他の人がこれを共有していることを知っています、おそらくこれを証明する研究があります。

コードレビュー担当者とペアを組めるようになれば、コードレビューの戦闘的な要素はなくなるはずです。理解されていない変更を行い始めると、変更点で議論され、議論され、より良いリファクタリングにつながる可能性のある代替案が探されます。ペアはより広い範囲の変更を理解することができ、サイドバイサイドコード比較で得られる行ごとの変更にそれほど集中することができないため、より高品質のコードレビューを取得できます。

もちろん、これはリファクタリングが作業中の変更の範囲外にあるという問題に対する直接的な答えではありませんが、変更を行ったときにどこにいるのであれば、変更の背後にある理由を同僚がよりよく理解することを期待します。

余談ですが、TDDまたは何らかの形の赤緑のリファクタリングを行っていると仮定すると、ピアからのエンゲージメントを確保する1つの方法は、ピンポンペアリングテクニックを使用することです。RGRサイクルの各ステップでドライバーが回転する、つまり、ペア1が失敗したテストを書き込み、ペア2がそれを修正し、ペア1がリファクタリングし、ペア2が失敗したテストを書き込みます。

おそらく、この問題は組織文化に関するはるかに大きな問題を反映しています。人々は製品をより良くするよりも「自分の仕事」に興味を持っているようです。おそらくこの会社は協調的な文化ではなく「非難」の文化を持ち、人々は製品/会社のビジョン全体よりも自分自身をカバーすることに興味があるようです。

私の意見では、あなたは完全に正しいです、あなたのコードをレビューする人々は、あなたが「あなたの割り当て」以外のことを「触れ」、それらの人々を説得しようとしますが、あなたの原則に決して反対しないために不満を持っている場合、完全に間違っています真のプロフェッショナルの最も重要な品質。

そして、あなたの仕事を評価するために、ばかげた企業のやり方で正しいことで悪い数字が得られたら、問題は何でしょうか、正気でない会社でこの評価ゲームに「勝ちたい」人は、それを変えてみてください！あなたは疲れている、別の場所を見つけるが、決してあなたの原則に反することはない、あなたが持っている最高のものです。

時々、リファクタリングは悪いことです。 ただし、コードレビュアーが提供している理由ではありません。彼らは本当にコードの品質を気にしていないように聞こえますが、あなたは気にします、それは素晴らしいです。しかし、そこにある2リファクタリングからあなたを停止する必要がありますな理由：1.あなたは自動テスト（単体テストまたは何でも）で行った変更をテストすることはできませんか2.あなたは非常に理解していないいくつかのコードに変更を作っているがまあ; つまり、あなたが変わるかを知るために、ドメイン固有の知識を持っていないはずですします。

1.自動テストで行った変更をテストできない場合は、リファクタリングしないでください。

コードレビューを行う人は、あなたが行った変更が、以前は機能していたものを壊さないことを確認できる必要があります。これが、動作するコードをそのままにする最大の理由です。はい、その1000行の長さの関数（本当に忌まわしい！）をたくさんの関数にリファクタリングするのは間違いなく良いでしょうが、テストを自動化できない場合、あなたがすべてをしたことを他の人に納得させるのは本当に難しいかもしれません右。前に間違いを犯したことがあります。

リファクタリングする前に、単体テストがあることを確認してください。単体テストがない場合は、いくつか書いてください！その後、リファクタリングを行うと、コードレビュアーは動揺する（正当な）言い訳ができなくなります。

持っていないドメイン固有の知識を必要とするコードをリファクタリングしないでください。

私が働いている場所には、化学工学に重点を置いたコードがたくさんあります。コードベースは、化学技術者に共通のイディオムを使用します。フィールドに慣用的な変更を加えないでください。と呼ばれる変数名前を変更するために素晴らしいアイデアのように思えるかもしれないxにしmolarConcentrationますが、何を思いますか？では、すべての化学のテキスト、モル濃度はで表されますx。名前を変更すると、その分野の人々のコードで実際に何が起こっているのかがわかりにくくなります。

慣用的な変数の名前を変更する代わりに、それらが何であるかを説明するコメントを入れてください。慣用的でない 場合は、名前を変更してください。放置しないでくださいi、j、k、x、y、など、より良い名前が動作するときの周りに浮い。

略語の経験則：人々が話しているときに略語を使用する場合、コードでその略語を使用してもかまいません。作業中のコードベースの例：

次の概念があります。「懸念領域」は「AOC」に、「蒸気雲爆発」はVCEになります。私たちのコードベースでは、誰かがaocと呼ばれるすべてのインスタンスをAreaOfConcernに、VCEをvaporCloudExplosionに、nPlanesをconfiningPlanesCount ...にリファクタリングしました。私もこのようなことをすることに罪を犯しました。

これは実際にはあなたの状況にはまったく当てはまらないかもしれませんが、この問題に関する私の考えはあります。

現在、この質問には2つの明確な問題があります。コードレビューの変更のレビューの容易さと、リファクタリングに費やされる時間です。

私が働いているところでは、大きな摩擦を引き起こす1つの開発プラクティスがあります-コードレビュー（CR）。「割り当て」の範囲にないものを変更するたびに、レビュー担当者に非難され、変更をレビューしにくくします。

他の回答が言っているように、リファクタリングチェックインをコード変更チェックインから分離できますか（必ずしも個別のレビューとしてではありません）？コードレビューを行うために使用しているツールによっては、特定のリビジョン間の差分のみを表示できるはずです（アトラシアンのCrucibleは間違いなくこれを行います）。

（2）実行するはずのない「リファクタリング」CRをリリースすることを好意的に見ている人はいません。CRには一定のオーバーヘッドがあり、マネージャーはリファクタリングに「時間を浪費する」ことを望んでいません。行うべき変更にバンドルされている場合、この問題は最小限に抑えられます。

リファクタリングが簡単で、コードを理解しやすくする場合（リファクタリングする場合に行うべきことはこれだけです）、コードレビューは完了するのに長くはかからず、最小限のオーバーヘッドである必要があります。将来、コードをもう一度見直さなければなりません。上司がこれを理解できない場合は、ボーイスカウトルールがコードとの生産性の高い関係につながる理由を議論するリソースに向けて優しく微調整する必要があります。「あなたの時間の無駄」が、あなたや他の誰かがそのコードでより多くの仕事をするために戻ってきたとき、2、5、10倍も節約できると彼らに確信させることができれば、問題はなくなるはずです。

この問題はResharperによって悪化します。変更に追加する新しいファイル（そして、最終的にどのファイルが変更されるかを正確に知ることはできません）には、通常、エラーと提案が散らばっています。修正。

これらの問題を同僚の注意を引き付け、なぜ修正する価値があるのか​​を議論したことがありますか？また、それらのいずれかを自動的に修正できます（自動リファクタリングで問題が発生していないことを確認するのに十分なテスト範囲があると仮定します）？本当につまらないものである場合、リファクタリングを実行することは「あなたの時間に値しない」場合があります。チーム全体でReSharperを使用していますか？もしそうなら、どの警告/ルールが実施されているかについて共有ポリシーを持っていますか？そうでない場合は、おそらく将来の痛みの原因となる可能性のあるコードの領域を特定するのにツールがどこで役立つかを示す必要があります。

25年ほど前に、たまたまコメントブロックとタブ/列の配置を再フォーマットしてコードを簡潔にし、理解しやすくすることで（実際の機能変更なし）、他の目的で作業していたコードの「クリーンアップ」を思い出すことができます。私はたまたま好きなきちんとして整然としただコードを。まあ、上級開発者は激怒しました。ファイルの個人的なコピーと比較して、何らかのファイル比較（diff）を使用して何が変更されたかを確認し、さまざまな誤検出を行っていたことが判明しました。私たちのコードライブラリはメインフレーム上にあり、バージョンコントロールがありませんでした-あなたは基本的にそこにあるものを上書きしました、そしてそれはそれでした。

物語の教訓は？私は知らないよ。自分以外の人を喜ばせることができない場合もあると思います。私は時間を無駄にしませんでした（私の目には）-クリーンアップされたコードは読みやすく、理解しやすいものでした。他の人が使用している原始的な変更制御ツールは、それらにいくつかの特別なワンショット作業を加えるだけです。ツールは、スペース/タブとリフローされたコメントを無視するにはあまりにも原始的でした。

@ Useless、@ Telastynなどで指摘されているように、要求された変更と要求されていないリファクタリングを（多くの）個別のコミットに分割できる場合は、それが最善です。「リファクタリング」CRを作成するための管理オーバーヘッドなしで、引き続き単一のCRで作業します。コミットを小さくして集中するだけです。

方法をアドバイスする代わりに、専門家からのより大きな説明（実際には本）を紹介したいと思います。これにより、より多くのことを学ぶことができます。「レガシーコードを効果的に使用する（Michael Feathers著）」をお読みください。この本は、リファクタリングを行う方法を教えてくれますが、機能の変更がインターリーブされています。

取り上げるトピックは次のとおりです。

• ソフトウェア変更のメカニズムの理解：機能の追加、バグの修正、設計の改善、パフォーマンスの最適化
• レガシーコードをテストハーネスに取り込む
• 新しい問題の発生を防ぐテストを作成する
• Java、C ++、C、およびC＃の例を使用して、任意の言語またはプラットフォームで使用できる手法
• コードの変更が必要な場所を正確に識別する
• オブジェクト指向ではないレガシーシステムへの対処
• 構造を持たないように見えるアプリケーションの処理

この本には、プログラム要素を分離して作業し、より安全な変更を行うのに役立つ、24の依存関係を破るテクニックのカタログも含まれています。

私も、ボーイスカウトのルールと日和見的リファクタリングを信じています。問題は多くの場合、経営陣が買収することです。リファクタリングにはリスクとコストの両方が伴います。経営陣がしばしば見落としているのは、技術的な負債もそうだということです。

それは人間の本性です。私たちは実際の問題に対処することに慣れており、それらを防止しようとはしていません。私たちはプロアクティブではなく、リアクティブです。

ソフトウェアは無形であるため、車のように修理が必要であることを理解するのは困難です。理にかなった人は車を買わず、修理もしません。このような過失は、その寿命を縮め、長期的にはよりコストが高くなることを受け入れます。

多くのマネージャーがこれを理解しているという事実にもかかわらず、彼らは生産コードへの変更に対して責任を負います。一人で十分に去ることを容易にする政治があります。多くの場合、説得力が必要な人は実際にあなたの上司であり、彼は単にあなたの「素晴らしいアイデア」を生産に持ち込むために戦いたくないのです。

正直に言うと、上司はあなたの治療が実際にあなたが思っているほど素晴らしいといつも確信しているわけではありません。（蛇油？）セールスマンシップがあります。彼が利益を見られるようにするのはあなたの仕事です。

経営陣はあなたの優先事項を共有しません。経営陣の帽子をかぶって、経営陣の目で見てください。より適切な角度を見つけることができます。しつこい。最初の否定的な反応があなたを思いとどまらせないようにすることで、より多くの変化をもたらします。

@ GlenH7で示されているように、要求された変更と要求されていないリファクタリングを2つの個別の変更要求に分割できる場合は、それが最善です。その場合、あなたは「時間を浪費する人」ではなく、「2倍熱心に働く人」です。

要求された作業をコンパイルするために要求されていないリファクタリングが必要になったため、それらを分割できない状況に頻繁に気づく場合は、ここで概説した引数を使用して、コーディング標準を自動的にチェックするツールを用意することを強くお勧めします（Resharper警告そのものは良い候補かもしれませんが、私はそれをよく知りません。これらの引数はすべて有効ですが、利点として使用できる余分なものが1つあります。これらのテストを使用すると、各コミットでテストに合格する義務があります。

あなたの会社が「リファクタリングに時間を浪費する」ことを望まない場合（彼らの悪いサイン）、あなたはもうあなたに悩まされないように「警告抑制」ファイル（各ツールには独自のメカニズムがあります）を提供すべきですそのような警告。最悪の場合でも、さまざまなシナリオのオプションを提供するためにこれを言います。また、それぞれの側の暗黙の仮定よりも、予想されるコード品質に関して、あなたとあなたの会社との間の合意を明確に述べた方がよいでしょう。