コードの一部をリファクタリング/レビューする時期はいつわかりますか? さらに良いことに、いつそれを行いますか?
おそらく他の人たちと同じように、何かにリファクタリング/レビューが必要であることはわかっていましたが、締め切りと管理のためにその時間がありませんでした。また、一般的な開発プロセスにコード レビューをどのように組み込んでいるかについてもお聞きしたいと思います。
最近、私は新しい機能/コードに取り組む前にそれをやっていることに気づきました。たとえば、アプリケーションのモジュール X で何か新しいものを開発したり、何かを変更したりする必要がある場合、そのモジュールのコード レビューを行います。また、モジュールをよりよく理解するのにも役立つことがわかったので、変更をより簡単に行うことができます。
では、いつその時が来たかを知り、いつ実行しますか? そして何よりも、それをプロジェクトの計画にどのように含めますか?
リファクタリングは、私が時間を割いて個別に行うものではありません。新しいコードを開発するとき、または古いコードを保守するとき、私は常にこれを行っています。通常のルーチンに組み込み、コードで改善できる点を常に探してください。
この質問に対するあなた自身の回答に追加した特定のケースに対応するには、あなたの状況は、完全な書き直しではなくリファクタリングすることをお勧めする完璧な例だと思います。コード行を変更する前に、問題のコードの適切なテスト ケース セットを作成してください。コードがいくつかのテストに失敗した場合、コードは 3 つの目的を果たします。まず、集中して取り組むべき特定の領域が示されます。第二に、コードに取り組むための (上司に対する) 確固たる正当な理由を与えてくれます。3 つ目は、コードをリファクタリングするときに備えておきたい標準の単体テスト セーフティ ネットです。
標準的な TDD の方法は Red-Green-Refactor です。失敗するテストを作成し、テストに合格するコードを記述し、テストに合格しながら既存のコードをリファクタリングします。リファクタリングは、テストに合格した後、複雑すぎるコードや不適切なパターンを使用しているコードを見つけたときに発生します。リファクタリングは、開発サイクルの最後のアドオンではなく、通常の日常の開発プロセスの一部であるべきです。リファクタリングを小さくしておく方がうまくいくと思います。通常のアクティビティの一部としてこれを行うことで、少なくとも理想的には、リファクタリングが行われる前に貧弱なコードが大きくなりすぎないようにします。
私は、同じコードを何度も繰り返しているような「コードのにおい」や、「これを行うためのより良い方法が必要で、それを見つけに行く」と思わせる何かを目にする傾向があります。それは私がコードを書く方法の一部であり、完成までに少し時間がかかるかもしれないが、はるかに簡単にスケーラブルで保守可能である、または他の誰かにそれを取ってもらうと費用がかからない良いコードを持つことは、いくらか良いことだと思います.コードで何をしていたのかを理解するのに何日もかかりました。
コードを継承している場合、それをどうするかについて 2 つの考え方があると私は考える傾向があります。
1) 距離を保つ。ここで、機能を組み込むために必要な変更を行いますが、それ以上行う必要はありません。モジュールがすぐに交換されることがわかっている場合、または年に 1 ～ 2 回しか作業しない場合は、修正に多くの時間を費やしたくないという論理がわかります。
2) 没頭して、今すぐ修正してください。あなたが行っていることがかなり広範囲にわたる変更であるか、定期的に作業するコードの一部である場合、リファクタリングやドキュメントを行うためのメンテナンスの一部と見なされるか、悪いコードの場所を説明したいと思うかもしれません後で時間を節約できるので、それほど悪くないコードに変換されます。
リファクタリングは、私が計画するものではなく、開発を通じて継続的に行うものです。なんらかの方法でより適切に構造化できる可能性があるとコードが示唆する場合はいつでも、適切な変更を加えます。
設計が正確に正しく行われることは決して期待できません。実際のニュアンスは実装中に明らかになり、常にリファクタリングを行うことで、より優れた設計およびファクタリングされたコードに到達するよう常に努力します。
正解は「常に！ 」だと思います。新しい機能に取り組んでいるときに、リファクタリングできるコードを見つけたら、それを実行します。私は TDD を使っているので、古い機能が使えなくなる心配はありません。
コードのにおいがするとき
あなたの質問の一部だけに答えるために：私はすでにここで他の何人かによってなされたポイントを繰り返します-一般的に、あなたが変更したものがないことを確認するために実行できるテストの繰り返し可能なセットがない場合コードを壊した-それならおそらくリファクタリングはまったくすべきではない。
あなたはコードがすでに壊れていると言いました。それを「機能させる」ために、最初は可能な限り小さな変更を加えたくなるかもしれません。問題は、テストなしで、それが本当に「機能している」とどのように言うことができますか？
頑張って！
コードを複製することがわかっている場合を除き、通常は行いません。そのため、新しい機能を作成するときに、「うーん、どこかでこんなことをした...」と思ったら、元の機能をリファクタリングして、できるだけ多くのコードを再利用できるようにしようとします。
そのコードを変更する必要がない場合 (動作し、拡張する必要がない場合) は、変更しないでください。なるがままに。他の方法で、変更が必要な場合は、リファクタリングのテストを作成し、変更を含めます。
私は自分自身を初心者プログラマーと考えています (現時点で生計を立てるためにプログラミングを行っているのは 6 か月だけです)。コードを見るだけで、リファクタリングが必要かどうかがわかるはずです。
私が理解している限り、これを「コードの匂い」と呼んでいる人もいますが、注目しているコードで最善を尽くしていないというのは、もっと不当な感覚だと思います。何をすべきか、またはコードを改善する方法がわからない場合がありますが、コードが完全ではないという疑いが少しでもある場合は、おそらくそうではありません。
多くの場合、スコープをモジュールよりもさらに小さくすることができます。ローカル変数の名前を変更したり、コード自体を説明することでコメントの必要性を取り除いたりするだけであっても、単一の関数が単独でリファクタリングする明らかな候補になることがあります。
変更が必要な領域を特定できる場合は、変更を行う前と変更中にその領域をクリーンアップします。コードを十分に理解して変更を加えるには、リファクタリングを実行する必要があることがよくあります。
ただし、コードに何らかのテストをラップするように言う他のすべての人に私の声を追加します. 少なくとも「通常の」ケースの合理的なセットをカバーし、いくつかの自動化を行うようにしてください (ほぼすべての言語で利用可能なフレームワークがあります)。これにより、小さな変更のたびにテストを簡単かつ迅速に実行できます。コードクリーニング活動を最初に始めたときに、フレームワークのテストについて考えていた/知っていたらよかったのに...
私は作業を進めながらリファクタリングを行い、それを迅速かつ安全に保つように努めています。コードのその領域が適切にテストされればされるほど、より多くのことを迅速かつ安全に行うことができます。
さらに、より大きなオーバーホールが必要だと思われる領域またはアーキテクチャの問題をマークし、それらの大きなセッションを個別にスケジュールしようとします。通常、それらを大きくするのはテストの欠如です。つまり、必要なテストを追加するために時間を費やす必要があります。 .
特定の問題に取り掛かるには: 数か月の間に、いくつかの悪いコードが (もう会社にいない人によっても) 書かれたプロジェクトがあります。完全な書き直しは不可能であり、クライアントにも経営陣にも説明できませんでした。
そのため、そのモジュールに変更を加える前に特定のモジュールをリファクタリングすることが、その状況で受け入れられるかどうか疑問に思っていました。
これが最善のシナリオではないことはわかっていますが、コンテキストは特殊なケースです (コードは既に壊れており、すべてを書き直すことはできません)。
バグを修正するときに同じコードに何度もアクセスし続ける場合は、それをリファクタリングする時期だと判断します。新しいプロジェクトに参加したり、新しいコードの責任者になったりした場合も、座ってリファクタリングを開始します。何かを拡張する場合は、大きな変更を行う前に、まず古い問題をすべてリファクタリングします (問題が根強くなりすぎる前に)。
正規化の目標レベルに達したら、リファクタリングは終了です。一般的なクリーンアップだけの場合: 1、2、または 3 で十分です。コードを拡張する場合は、4 または 5 の方が適切です。長期にわたって既存の作業を本当に活用しようとしている場合は、6 が最適です。
ポール。
コードの匂いも探していると言いますが、もっと具体的にしたいと思います。私は、プロジェクトごとに成長し、進化しているデザインのフレームワークを使用しています。私はプロジェクトの早い段階で大幅にリファクタリングと再設計を行う傾向があります (これらを別々に保つように自分自身を訓練することは、私がまだ取り組んでいることです)。締め切りが近づき、問題やコードのにおいがあれば解決に近づくにつれて、手を緩めて、私の特定の実装に焦点を当てます。これを行うと、通常、機能的ではあるものの、完全には満足できないものをさらにいくつか見つける (または作成する) ことになります。これらをログに記録し、プロジェクトの次のイテレーションでこれらの問題に対処します。
コードに戻ると、状況を処理するためのよりエレガントな方法があることに気づき、すぐにそれを確認できなかったことに自分自身を蹴ることがあります。もっと良い方法があると思うこともありますが、それは私が当初思い描いていた方法ではありません。そのままでいいのに、それを変えるのは過剰な設計になると思うこともあります。また、何か他のものを修正する際に、元の問題が消えていることに気付くこともあります。
コードに機能的な変更 (機能、バグ修正、パフォーマンスなど) を加える準備をするとき、私はまず、コードがその変更を行うのに理想的な構造になっているとしたらどうなるかを自問します。
次に、その方向にリファクタリングします
ここで、機能の変更を行います。
最後に、もう一度リファクタリングして、変更によって生じた醜さをクリーンアップします。
私は常に、リファクタリング作業と他の要因 (締め切り、このコードの重要性、テスト カバレッジの品質など) とのバランスを取りたいと考えています。