ボーイスカウトルールと日和見的リファクタリングとコードレビューの調整
私はボーイスカウトルールを大いに信じています。 オリジナルの作者が誰であっても、モジュールを改善するためにどんなに小さな努力をしたとしても、結果はどうなるでしょうか？すべてがその単純なルールに従っており、ソフトウェアシステムの容赦ない劣化の終わりが見えますが、代わりに、システムが進化するにつれて徐々に改善されていきます。自分の小さな部分を気遣うだけの個人よりも。 私はまた、日和見的リファクタリングの関連するアイデアを強く信じています。 いくつかのスケジュールされたリファクタリングの努力のための場所がありますが、私は、いつでもどこでもコードをクリーンアップする必要があるとき、誰によってでも行われる日和見的な活動としてリファクタリングを奨励することを好みます。これが意味することは、誰かがそれほど明確でないコードを見たときはいつでも、すぐにそれを修正する機会をとるべきだということです-少なくとも数分以内に 特に、リファクタリングの記事からの次の抜粋に注意してください。 私は日和見的リファクタリングの摩擦を引き起こす開発慣行には警戒しています...私の感覚では、ほとんどのチームは十分なリファクタリングを行っていないので、人々がそれを行わないよう注意を払うことが重要です。これを洗い流すのを助けるために、小さなリファクタリングを行うことを思いとどまるときはいつでも気をつけてください。確かに1、2分しかかかりません。そのような障壁は、会話を促す匂いです。そのため、落胆のメモを取り、チームに報告してください。少なくとも、次の回顧展で議論する必要があります。 私が働いているところでは、大きな摩擦を引き起こす開発プラクティスが1つあります。それは、コードレビュー（CR）です。「割り当て」の範囲にないものを変更するたびに、レビュー担当者に非難され、変更をレビューしにくくします。これは、リファクタリングが関係する場合に特に当てはまります。「行ごと」の比較比較が困難になるためです。このアプローチはここでの標準です。つまり、日和見的リファクタリングはめったに行われず、「計画された」リファクタリング（通常は少なすぎる、遅すぎる）が行われます。 私は、メリットはそれだけの価値があり、3人のレビュアーが少し一生懸命に働くと主張しています（変更された行の狭い範囲を見るのではなく、実際に前後のコードを理解するために-レビュー自体はそれだけで良いでしょう） ）コードを読んで保守する次の100人の開発者が恩恵を受けるように。この論点をレビューアーに提示すると、同じCRにない限り、リファクタリングに問題がないと彼らは言います。しかし、私はこれが神話だと主張しています： （1）ほとんどの場合、課題の最中に何をどのようにリファクタリングしたいかを認識するだけです。マーティン・ファウラーが言うように： 機能を追加すると、追加するコードに既存のコードとの重複が含まれていることに気付くため、既存のコードをリファクタリングしてクリーンアップする必要があります...何か機能するかもしれませんが、既存のクラスとの相互作用が変更された場合に優れています。自分が完了したと考える前に、その機会にそれを行ってください。 （2）実行するはずのない「リファクタリング」CRをリリースすることを好む人はいません。CRには一定のオーバーヘッドがあり、マネージャーはリファクタリングに「時間を浪費する」ことを望んでいません。行うべき変更にバンドルされている場合、この問題は最小限に抑えられます。 問題はResharperによって悪化します。変更に追加する各ファイル（および最終的にどのファイルが変更されるか正確に知ることはできません）には、通常、エラーと提案が散らばっています。修正。 最終的な結果は、ひどいコードが表示されることであり、そのまま残します。皮肉なことに、このようなコードを修正しても私の地位が向上するだけでなく、実際にはそれらを下げて、仕事をする代わりに誰も気にしないものを修正する時間を無駄にする「焦点のない」男として描く 私は本当に悪いコードを軽deし、それを見て我慢できず、私のメソッドからそれを呼び出すことができないので、私はそれについて悪いと感じています！ この状況をどのように解決できるかについての考えはありますか？