PHP でコードをリファクタリングする方法 - アイデアと方法

まず、私がこれまでに接したいくつかの古いプロジェクトの経験について話させてください。古いプロジェクトの場合、最初の接触プロセスでは、ほとんどの人が常に抵抗感を抱き、一部の人は軽蔑さえします。私はいつも、以前のコードに多くの問題を見つけてから、コードや以前の開発者について不満を言い始めるのが好きですが、憂鬱な苦情が続いた後、私は専門的な責任感を持ち、すべてを変えたいと考えています。良いと思う方法では問題が解決したので、次の仕事はコードをリファクタリングすることです。

おそらくほとんどの開発者はこれを経験したことがあると思いますが、この経験は苦いものです（なぜならリファクタリングは重要であるにもかかわらず、あまり評価されていないからです。現在、国内ではユーザビリティが重視されており、コードの品質は注目されていません。人々はそれに注目します）そしてそれはまた甘いものでもあります（嵐の後には必ず虹がかかります）。若い開発者にとって、虹を見るまでのプロセスは苦痛で長いものです。彼らは皆、経験に加えて、失敗を通じて成長します。これらの失敗は主に、成功を達成することに熱心すぎて、やみくもに再構築することが原因です。

視覚障害は主に以下に反映されます:

1. システム アーキテクチャ全体を明確に理解する前に、それを新しいテクノロジまたはアーキテクチャと考えられるものに置き換える必要があります。

2. 既存のシステムアーキテクチャやプログラムの欠点をまったく分析せず、ただ闇雲にデザインパターンについて話し、固有のデザインパターンのセットで再構築します（再構築では、それは参照としてのみ使用され、Aは使用されません） )

3. リファクタリングは比較的カジュアルで、各バージョンの開発はアーキテクチャを超えて、新しい設計アイデアを自由に取り入れます。

この種のやみくもな再構築は、システムにさらなる問題をもたらすでしょう:

リファクタリングを行うと、システムの運用効率が低下することがわかります。

システムには複数のアイデアが同時に存在するため、新しいメンバーが引き継ぐのがより困難になります。

システムを完全に理解していないため、リファクタリングに多くの重複コードを持ち込んでいます。

最も悲劇的なのは、リファクタリングされたコードが他の人からもゴミとみなされ、リファクタリングされてしまうことです。

それでは、どうすれば失明をなくすことができるのでしょうか。 ?

まず、現在のプロジェクトに問題があるかどうか、どのような問題があるのか​​、そしてそれらの問題が再構築によって解決できるかどうかを理解し、再構築する時間を会社から与える必要があります。上司はあなたのせいでそれをするわけではありません。強い依存性と偶然性の低さについては、問題を通してのみ上司に知らせる必要があり、あなたの仕事は問題を通してのみ得られるということです。これは非常に現実的な状況です。

次に、リファクタリング オブジェクトがアーキテクチャ用かローカル コード用かを判断し、理想的な目標を設定する必要があります (なぜ理想的なのか? 1 つのステップで正しく行うことはできないため、理想と現実の間にはギャップがあります) , しかし、私たちがしなければならないのは、理想に近づくために最善を尽くすことです）。

アーキテクチャをリファクタリングしている場合、これは簡単な作業ではありません。実際に始める前に、次のことを行う必要があります。

1. 以前のアーキテクチャ/技術的背景やビジネス要件を含む、システムの過去に関する包括的な理解

2. 保守性の低さ、既存のニーズを満たさなくなった側面など、以前のアーキテクチャの問題を分析します。

3. コア コードの少なくとも 80% を確認する。以前のコードに基づいて、一定期間実際のコーディング経験があることが最善です。

上記の点を行う目的は、明確に理解し、自分自身と敵について知ることです。次は実質的な段階に入ってもいいでしょうか？いいえ、非常に重要なことがまだ 1 つありません。それは再建計画です。

この種の大規模なリファクタリングでは、実際の状況では、通常、上司から与えられた時間と実際にリファクタリングに必要な時間は大きく異なるため、リファクタリング作業を後で遅らせる必要があります。再構築と新しい要件の開発が必要であり、この作業は 1 人の作業ではなく、複数の人の協力が必要となるため、共通の目標に加えて、一定のレビューのメカニズムも必要です。リファクタリングの方向が一貫していることを確認するなど。これらの要素の下でリファクタリングを適切に行うことが、リファクタリング計画が必要な理由です。

ローカル コードをリファクタリングする方がはるかに簡単かもしれませんが、注意する必要があるのは、既存のアーキテクチャの考え方に従い、その範囲内で考える必要があるということです。

実際、この方法での再構築のほとんどは、メソッドを抽出したり、実際のビジネスプロセスに基づいて既存のコードの実行プロセスを再構築したりして、理解しやすくしたり、プログラム間の依存関係を軽減したりすることです。

これを行うには非常に重要な考え方があります:

1. 物事の本質とは何か、物事の外部環境は何かを分析するのが得意です。

2. さまざまなものの中から共通点を見つけ、その共通点を抽象化します (簡単な例を挙げると、BMW とアウディの場合、それらを車に抽象化する必要があります)。

なぜこんなことを言うのかというと、これらはコードのリファクタリングに必要なものをもたらす可能性があるからです:

1. コードの作成プロセスにおける依存関係を削減します。

2. 抽象的なものは再利用可能です

上記をすべて実行すると、リファクタリングが完了したことになります。不可能です。これは良いスタートにすぎません。アジャイルで述べたように、継続的なリファクタリングを実現する必要があります。

プロジェクトマネージャーは各バージョンサイクルにこの時間を与えないので、それは非現実的だと考える人もいるかもしれません。実際、私は混乱しています。 ！ 1 週間以上かかると予想している場合、リファクタリングにこれほどの時間がかかることに同意する人はいないでしょう。本当に必要です。それは、あなたの初期の設計が非常に貧弱であることを意味します。非常に狭い範囲の変更に限定されているため、所要時間は 2 日程度であると考えています。

これをうまく実行できれば、プロジェクトは非常に保守しやすくなるはずです。これは理想的なことではありませんが、一貫して実行する限り、実際には非常に簡単です。

上記はリファクタリングに関する私の個人的な考えの一部であり、言葉だけでは空虚に見えるかもしれませんが、後で参考とコミュニケーションのために実際のリファクタリングの事例をいくつか紹介します。

アーキテクチャのリファクタリング:

1.再建計画

2.交差部分を抽出するアルゴリズム

3. オブジェクトのレプリケーションを簡単かつ柔軟に実装します