リバースエンジニアリングPHP（醜い）コードを読まないアプリケーション
PHP App。という新しい顧客がいます。これは、2005年に「さらに別のフレームワークを作りたい」と考えていた単一の開発者によって書かれました。約3年後、開発者は会社を辞めました、そして彼と一緒に、このことが実際に何をしているかについてのすべての知識。
現在、アプリはすでに稼働しているので、マネージャーは数人の開発者/フリーランサー（もう利用できなくなります）を雇って、あちこちでバグを修正し、いくつかの機能を開発しました。文書化されていないソフトウェアのガイドラインに従おうとした人もいましたが、従わなかった人もいます。
コードが今日どのように見えるか想像できるかもしれません...それは全くの混乱です！
私はマネージャーと話し、彼のソフトウェアについて私がどう思うかを彼に話し、なんとかして彼がいまいましいことを書き換えることについて本当に考えさせることができました。
しかし、ここで私の問題が発生します。書き換えに必要な労力を見積もることができるように、私は事が何をしているかを知る必要があります。マネージャーは彼の視点からそれが何をしているのかを知ることができますが、それについての技術的な知識はありません。そして、長年にわたって成長してきたすべてのソフトウェアと同様に、これらの「特別なEdgeケース」があります。
基本的に、私の考えは、実際に数週間にわたってライブシステムを「記録/ログ」して、実際にほとんど何をしているのか、ほとんど触れられない/使用されないことについて、技術的でやや完全な結論を得ることです。例えば。リクエストとは何か、結果をレンダリングするためにどのルートを使用したか。コードを読んで理解しようとすることは不可能です。ただし、どのクラス/関数が呼び出されているかを確認し、それらを読み取って理解すると役立ちます。
それで、Httpリクエスト/レスポンスをログ/記録するツールと、それがトリガーしたphpアプリのどのコールグラフですか？できれば、コードに書き込む必要がないものは何ですか？私はPHP数年前に捨てて、私のPHPユーティリティと標準ライブラリツールセットと一緒に、ここで私を助けることができる何かを知るために少し錆びています。
それで、Httpリクエスト/レスポンスをログ/記録するツールと、それがトリガーしたphpアプリのどのコールグラフですか？できれば、コードに書き込む必要がないものは何ですか？
xdebug の コードカバレッジ分析機能 は、各リクエストで何が実行されるかを理解するのに役立ちます。
コードカバレッジは、リクエスト中に実行されたスクリプトの行（またはスクリプトのセット）を示します。この情報を使用して、たとえば、単体テストがどの程度優れているかを確認できます。
xdebugのプロファイラー は、Cachegrind互換ファイルの形式でプロファイリング情報を出力します。したがって、php.iniおよびhtaccess。
これは実用的なアプローチです。ここで止めないでください。 ChrisF および Morons によって与えられるアドバイスに従う必要があります。
アプリケーションを書き直したい場合は、howが行うことを知っている必要はありませんが、whatは知っている必要があります。
マネージャーと一緒に座って、システムに必要な機能を強調してシステムを調べます。これにより、機能のリストが表示されます（たとえば、アプリケーションがブログシステムであると想定）。
- ユーザーを作成
- ブログ投稿を追加
- 将来のある時点でブログ投稿を公開します。
- ブログ投稿へのコメント
- 等.
各ページのスクリーンショットを撮って、システムがどのように見えるかのドキュメントを用意します。これにより、データモデルに必要なオブジェクトとフィールドも提供されます。
次に、離れて、選択したフレームワークを使用してこれらの関数を実装するのにかかる時間を指定します。
どの段階でも、既存のコードを確認する必要はありません。 system機能ではなく、ser機能をマッピングしています。
あなたは年を間違えました。それは2001年でした...待ってください、あなたは私の古い同僚ではありません。これはどこでも起こります。
フランケンシュタインを書き直すかパッチを適用するかを選択しなければならないとき、書き直しが起こらないことは絶対に明らかでした。とにかく、一度にすべてではありません。代わりに、ページごとにリファクタリングを上から下に行っていました（これは正確にモデル駆動型のアーキテクチャではなかったため、サイトをページのコレクションと考えるのが妥当でした）。私たちの場合の「フレームワーク」は簡単に始まりました。 Draw_Info_Box(some_object)。しかし、特殊なケースが発生したため、この関数はDraw_Info_Box(some_object, true, true, true, false, "Non-default header", true)...になりました。これらをリファクタリングして、一度に1つの追加パラメーターを削除することから始めました。一部では、コードを複製して2つのバージョン間の特殊なケースを排除することを決定しました（「DoSomethingOrSomethingElse」のような名前は「DoSomething」と「DoSomethingElse」に分割されます）。他のものについては、それらを単純なオブジェクトでラップし、追加のパラメーターをオブジェクト状態変数に変換しました。これにより、後で簡単にリファクタリングできるようになりました。
システムを管理可能な単位（この場合は個別のページ）に分割することで、システムの使用中にシステムの一部をより管理しやすくすることができました。これにより、リファクタリングが行われている間も、より簡単なバグ修正が可能になりました（これは、書き直しに対する反対でした-使用されているシステムに対して行う必要があることがまだありました）。
システム全体が書き直される前に、私は実際に立ち去りました。その時までに、一部は実際には2回以上書き直されていました（組織の混乱の1つのレベルをクリアすると別のレベルが明らかになることがよくありましたが、それを処理できる方法論的なアプローチがありました）。
今日同じようなことを始めていたら、実際にはアプリケーションのSeleniumテストから始めて、テストからある種のコードカバレッジメトリックを取得しようとします。次に、同じリファクタリングジョブを実行しますが、間違いや動作の違いがキャッチされることをもう少し自信があります。
基本的には、ユースケース\ユーザー画面の観点からシステムを文書化する必要があります。少なくともユースケースの中で、システムのすべての画面をカバーするようにしてください。
次に、DBプロファイルの実行中にすべての画面とユースケースを確認する必要があります。各画面にすべてのDbトランザクションを記録します。データ検証のためにすべてのフィールドをテストします。
システムの統合についてユーザーに尋ねます。基本的に、UIに反映されていない、またはDbインタラクションでは画面の背後で発生している可能性のあるすべてのことです。 （送信とメール。何かをFTPで送信するなど）
スケジュールに沿った実行について質問します。システムの主要なレポートの背後にあるすべてのSQLを見てください。 ERDを作成します。
ドキュメント、ドキュメント、ドキュメント..最後に、すべての情報を取得したら、この方法で実行できます。明確にする必要がある領域のコードを調べ始めます。
ChrisFとMoronsがすでに言ったことに基づいて構築したいと思います。
から ChrisFの答え ：
アプリケーションを書き換えたい場合は、アプリケーションの動作を知る必要はありませんが、アプリケーションの動作を知る必要があります。
100％同意します。
から Moronsの答え ：
システム統合についてユーザーに尋ねます。基本的に、UIに反映されていない、またはDbインタラクションでは画面の背後で発生している可能性のあるすべてのことです。 （送信とメール。何かをFTPで送信するなど）
スケジュールに沿った実行について質問します。システムの主要なレポートの背後にあるすべてのSQLを見てください。
同意した。スケジュールされたジョブについての素晴らしい点。
ドキュメント、ドキュメント、ドキュメント..最後に、すべての情報を取得したら、この方法で実行できます。明確にする必要がある領域のコードを調べ始めます。
正しい。
データ検証のためにすべてのフィールドをテストします。
OK。
次に、DBプロファイルの実行中にすべての画面とユースケースを確認する必要があります。各画面にすべてのDbトランザクションを記録します。
同意しません。
- データベースを徹底的にプロファイリングすることは、時間を有効に活用するものではありません。
- また、誤解を招く可能性があります。
- 強調：ChrisFが言ったように、-方法ではなく、アプリケーションが行う内容に焦点を当てます。
また、次のことも知っておいてください。間違いを犯します！ ：）
もちろん、テクニカルリードとして、新しいシステムが古いシステムのコア機能を模倣する範囲でこれらの間違いを最小化するのはユーザーの責任です。
そうは言っても...
- このように見えますやりがいのある作業になりますシステムを保守可能にし、大量の技術的負債を消去しているためです。
- 私は、この仕事に対して過度に完璧主義的な態度で自分自身に負担をかけることが、有用で、生産的で、効率的で、財政的にさえ責任があるとは思いません。