問題が発生した場合、特に性質が複雑な場合は、時間をかけて問題を解決するためのアプローチについて考えます。これにもかかわらず、よくあることは、ソリューションをプログラミングしているときに、見逃した問題の詳細について考え始め、それに応じてコードを調整することです。
結果は、リファクタリングする必要があるコードの混乱です。
私は「リファクタリング」をしたいのですが、簡単に聞こえますが、それを実行するのは本当に大変です。見逃した細部が小さい場合、すでに書いた内容を消去して本来の方法で書くのではなく、デザインに小さな更新を加えたくなります。
それは明白な答えのある質問のように聞こえますが、「あなたが行くにつれてリファクタリング」をよりよくするために使用するテクニックはありますか？これは良い原則であることは知っていますが、何度も何度も失敗します。
回答:
おそらく、Fowler's Refactoring本の基本的な観察は、コードの動作に影響を与える変更とそうでない変更を分離する方がはるかに良いことです。後者のカテゴリのものは、「リファクタリング」と呼ばれます。これらの変更を混在させると、失敗するので注意してください。コーディングモードとリファクタリングモードを切り替えることができますが、同時に両方を行うことはできません。あなたがしようとすると、あなたはあなたが間違ったことを知りません。
動作を変更する変更を導入しようとして、動作が変更されない場合：何か間違ったことをしました。確認して修正してください。多分ちょうどそれをロールバックします。
リファクタリングを導入しようとして、動作が変更された場合：何か間違ったことをした。確認して修正してください。多分ちょうどそれをロールバックします。
両方の変更を同時に試みた場合、その単純な評価を行うことはできません。単体テストがない場合も同様です。それらを書く。そして、一度に1つのことを行います。
私がよく行うことは次のとおりです。自分自身のコメントをコメントとして残すか、コメントアウトされたコードを残します。ずさんなコードが機能するようになったら、簡単に再編成できます。
また、リファクタリングに固有の問題はありません。先に進む前に、リファクタリングされたコードが新しいバグを導入しないことをテストする方法があることを確認してください。
別の経験則では、すべてのメソッドは1つのことだけを実行する必要があります。
実装しようとしているものの処理を小さな個別のステップに分解し、それらのステップをメソッドとしてコード化すると、リファクタリングするときは、意味のある唯一のリファクタリングがメソッドが呼び出されるようにするか、一部のメソッドを実行パスから除外する。
また、メソッドは個別であるため、返された値が本来あるべきものである限り、任意の単一のメソッドを自由にリファクタリングできます。他のコードは、変更が加えられたより賢明ではありません。
これにより、メソッドをあちこちに最適化するだけで、コードを徐々に改善していくための準備が整います。全体的なロジックは変更されず、特定のステップの詳細のみが変更されます。
これをメソッドからクラスにフォローアップすると、クラスが単一のオブジェクトのみを実行または表す場合、メソッドの場合と同様に、リファクタリングは、クラスが作成および使用される順序の再編成にすぎないことがわかります。 、そして実際に詳細ロジックを変更することについてはあまり触れません。
プログラムの仕様が大幅かつ突然変更されたときにスイートスポットに到達したことはわかっていますが、内部の実装をまったく変更することなく、オブジェクト間の関係を変更するだけで、必要なほぼすべての変更に対応できます。突然ニルヴァーナを手に入れたような気がします！
幸運を祈ります。すべてのコードにバグがないようにしてください。
ロドニー
問題を解決するためにトップダウンのアプローチを取るかのようにインターフェイスを作成しているが、ボトムアップで実装している可能性はありますか？もしそうなら、私はそれが問題を引き起こしている論理的なミスマッチだと思います。
あなたが説明していることに基づいて、あなたがする必要がある少なくとも一つのことを考えることができるように問題を分解し、そしてそれだけを実装するほうが良いかもしれません。あなたがする必要がある別のことを考え、それだけを実装してください。続けて、最初に絶対的な基礎を記述し、次にその上にあるビルディングブロックを記述して、実際のソリューションが確定するまで上に向かってソリューションを構築します。私は、困難な問題に対してさえ、完全な解決策があなたに忍び寄り、そのようなアプローチに従うと突然飛び出す傾向があることに気付く傾向があります。
中間のビルディングブロックを論理的にフォーカスし、コードの各セグメントを意図的に閉じて制限している場合、実行する必要があるリファクタリングの量は常に小さく孤立している必要があります。
...すでに書いた内容を消去して、本来あるべき方法で書くのではなく、デザインを少し更新するのは魅力的です。
何も想定されていません。唯一想定されていることは、
なんでしょう？1つは完全に完璧なsuper-duper-excellent-clean-codeプロジェクトを終了しましたか、それとも3つ終了しました。コードエレガンスは前者に比べて70％だけですが、ユーザーの観点から95％の3倍ですか？世界、あなたの人々、あなたの使命のためにより役立つものは何ですか？
なんでしょう？
もちろん、長期的には、リファクタリングに成功する可能性があります（mtce時間の短縮など）。私たちプログラマーは、必要以上に早くリファクタリングして最適化しようとすることがよくあります。多くの場合、それ以上開発されないコードをリファクタリングします。つまり、時間の無駄になります。
私は2-3の独自の黄金律を使用します。特定のコードを初めて使用するときは、できるだけ早くそれを実行します。ユースケースの可能性に関する十分な情報がまだないため、それのより一般的な使用法について考えることはほとんど効果がありません。また、コードのこの部分は二度と使用されない可能性があります。コードが2度必要になると、最初のコードをより一般的にしてこのケースにも適用するか、またはコピーすることを選択します（ただし、これは好きではありません）。3番目の使用法では、リファクタリングするのに十分な情報があると感じています。また、コードのこの部分は実際に使用されているように見えるので、それが報われると感じています。