3

私の職場では、コア製品であるいくつかの「モジュール」を備えたWebアプリケーションの主要なリファクタリングを計画しています。それが私たちの主な関心事の1つであるため、モジュールは実際にはモジュールではないため、すべてがモノリシックであると引用しました。このアプリケーションはPHPで作成されており、MySQLデータベースにアクセスするためにPearを賢くテンプレート化して使用しています。データベースの独立性についてはあまり関心がありませんが、実装に数か月もかからないのであればいいのですが。

私たちの主な懸念は、無関係な場所でバグが発生し、最も一般的な機能を取得するために依存する健全な共通アーキテクチャがないため、開発時間/コストが指数関数的に増加していることです（各モジュールは基本的に前のモジュールからコピー/貼り付けされます）適応する）。

主にASP.NETMVCで、WebMVCの原則についてある程度の経験があります。私はそれが提供するきれいな分離とテスト容易性が好きです。ただし、ローカルマシンでこれを試すと、アプリは本来よりもはるかに遅くなります。

さて、十分な紹介ですが、質問に移ります：-キャッシングモジュールに依存する必要がありますか？これにより、優れたアーキテクチャが提供するオーバーヘッドのほとんどが削除されますか？APCのようなもの。

  • アプリケーションは主に読み取られます。書き込みは主に単一の値です（レコードの単一のフィールドを変更します）。これが得意なPHPのOR/Mはありますか？
  • また、柔軟なMVCフレームワークを探しています。Zend、CakePHP、多分Symfonyを知っていますか？

トリッキーな部分は、完全な書き換えを実行できるという贅沢がないことです。現在非常に厄介なコードベースを段階的に改善する必要があります。これは、新しいコードを記述しているとき、またはバグを修正しているときに実行する必要があります。私が本当にやりたいことの1つは、新しいバグを修正する前に回帰テストを作成して、後で再び発生しないようにすることです（これはときどき発生します）。

私が現在検討しているスタックには、次のものが含まれています。

  • 選択したMVCフレームワーク
  • ロギング（log4php？）
  • 選択したOR/M（動的である必要はなく、コード生成も問題ありません）
  • 選択したIoCコンテナ
  • Smarty Templating、おそらく抽象化されているので、必要に応じて切り替えることができます。
  • 選択したオペコードキャッシュ（現在使用していますが、どれを忘れたか、sysadminに問い合わせる必要があります）

私が心配している主なポイントは、PHPでクリーンなコードを作成することのパフォーマンスへの影響です。.NET / Java Webスタックのようなものとは対照的に、解析された言語であるため、インラインコードの抽象化を作成すると（異なるファイルでの分離が義務付けられます）、別のレベルで新しい問題が発生する可能性があります。

注：より適切なタグを思いついた場合は、タグを付け直してください。現在のタグについてはわかりません。

4

5 に答える 5

3

通常、クリーンなセットアップを行うことはパフォーマンスの問題ではありません。ほとんどのパフォーマンスは、話しているデータベースまたはその他の外部システムで費やされます。

これらを除いて、通常、最適化する価値のある1つまたは2つのホットスポットがありますが、そのためには、クリーンな設計から始めて、プロファイラー（XDebugやZendDebuggerなど）を使用してボトルネックを特定する必要があります。

クリーンなソフトウェア設計は、「最適化された」設計による0.01％のパフォーマンス向上よりもはるかに重要です。通常、保守不可能な「最適化された」コードベースについて心配するよりも、より多くのハードウェアを購入して実行する方が安価です。

于 2009-11-27T14:59:50.553 に答える
2

テストを構築するための予算を立てることを強調したいと思います。経営陣には次のように主張します。

  1. 開発者がバグを修正したら、バグのテストを作成できるようにします。バグはおそらく必要以上に頻繁に再発しますが、これはそれを完全に止める安価で効果的な方法です。
  2. 開発者が新しい機能を構築するときは、その下にテストを記述できるようにします。彼らはその時点で機能に完全に慣れているため、自動テストの「セーフティネット」を構築するのに 最も費用がかからない時期です。

テストにどれくらいの時間がかかるかを甘やかしてはいけません。それがあなたの時間の 1% であろうと 50% であろうと、それをマネージャーに直接伝えますが、セーフティ ネットとして自動化されたテストを構築することで、ユーザーが多くのバグに遭遇するのを防ぎ、開発者がバグ修正ではなく新しい開発に費やす時間を節約できることを強調してください。

于 2009-11-27T15:43:53.163 に答える
2

スパゲッティ コード コンポーネントを使用して MVC コンポーネントを管理する限り、大規模なプロジェクトで同様の問題が発生しました。うまく機能したのは、ディレクトリを取得して、MVC アプリ (この場合は Zend Framework) の新しい docroot を次のようにすることでした。

古い部分:
http://site.com/data.php
http://site.com/other.php

新しい部分: http://site.com/app/controller/action/ ...

認証については、いくつかの選択肢があります。おそらく最も論理的な方法は、login.php スクリプトを MVC ログインにリダイレクトし、必要な情報を GET パラメーターとして渡して、目的の元のページに戻すことです。これにより、レガシー システムと新しいシステムが同時に透過的に存在できるようになります。

遅さについては、XDebug を取り出す前に、問題のある部分を切り分けて、所要時間を出力するようにしました。より速い私見。

于 2009-11-28T16:48:24.803 に答える
1

適切に構造化されたオブジェクト指向コードが、データベース駆動型Webアプリケーションのsapghettiphpコードよりも大幅にパフォーマンスが低下する理由はありません。ボトルネックがどこにあるかを見つけ、それに応じて最適化するために、いくつかのプロファイリングを行う必要があります。

于 2009-11-27T15:00:21.223 に答える
0

あなたは厳しい（しかし珍しいことではない）状況にあります。

バグを最小限に抑えるためにコードを整理する限り、私にできることは DRY の上限のヒントだけです。

パフォーマンスの問題については、この手法によって非常に遅いことがわかるため、簡単に見つけることができます。

于 2009-11-27T15:35:51.577 に答える