Magentoは多くの「すぐに使える」機能を提供しますが、サードパーティの拡張機能を必要とするクライアントストアには、必然的に機能や機能が必要になることがわかりました。
しかし、媒体の性質を考えると、商業取引を扱うこのような複雑なシステムに「外国の」コードを導入することは危険な命題になる可能性があります。
Magentoの拡張機能を評価する際に何を探しますか？あなたが出くわした「レッドフラッグ」とは何ですか（パフォーマンスの悪用、セキュリティリスク、アーキテクチャの悪い習慣）？
回答:
サードパーティモジュールの評価に関するいくつかの考えを次に示します。
基本：
現在のMagentoバージョンのサポート-最新バージョンのMagento（現在開発中のMagentoを含む）をサポートしていますか？
モジュールがMagentoの最新リリースをサポートしていない場合、貴重な開発時間を費やさずにモジュールを機能させることはおそらく困難です。
サポート-モジュールを作成した開発者は製品をサポートしていますか？
健全なモジュールの兆候の1つは、開発者が積極的にサポートしていることです。彼らがそれをサポートしていないなら、それは赤い旗です、なぜ彼らはそれが良ければ製品をサポートしないのですか？
さらに、モジュールがサポートされている場合、通常、開発者から簡単な電子メールで重要な情報を取得できます（たとえば、このモジュールはjQueryまたはPrototypeを使用します）。
レビュー-他のユーザーは何と言っていますか？彼らの経験はどうでしたか？
レビューを読むことで、全体像をよりよく理解できますが、インストールの問題はありますか？開発者はタイムリーかつ有用な方法で応答しますか？広告どおりに機能しますか？
払い戻し-意図したとおりに機能しない場合、返金されますか？
うまく機能し、仕様を満たしている場合は、テストできるように何度もモジュールを試してみたいと思います！ただし、返されない場合は、返品して払い戻しを受けるオプションが必要です。
中級：
クラスオーバーライド-モジュールはコアクラスをオーバーライドしますか？
一般的に、優れたモジュールはコアクラスをオーバーライドすべきではなく、オブザーバーを使用する必要があります。
この理由の1つは、Magentoのアップグレードが困難になる可能性があることです。さらに、他のモジュールは特定の関数からの1つの出力に依存している可能性があり、このモジュールは異なるモジュールを提供しています。
これが不可能な場合もありますが、その場合は、コアクラスをオーバーライドする非常に良い理由が必要です。
レイアウトの更新-モジュールはレイアウト設定の一部を変更しますか？
一部のモジュールは、サイトのレイアウト設定を変更し（例：製品ページ）、現在のレイアウトを壊さないことを確認し、それが必要な場合は修正します（読む：どれくらい時間がかかりますか） 。
テンプレートの変更-モジュールには、現在のデザインを変更するテンプレートが含まれていますか？
このモジュールは新しいテンプレートを導入しますか？はいの場合、彼らは私のデザインを壊しますか？デザインを思い通りにするにはどれくらい時間がかかりますか？
依存関係-モジュールは他のモジュールに依存していますか？
モジュールが他のモジュールに依存している場合、それらが存在し、インストールされていることを確認する必要があります。さらに、私たちは自分自身に尋ねる必要がありますが、今後依存するモジュールをオフにしたいのでしょうか？
高度：
SQLアップグレードスクリプト-モジュールは何らかの方法でDBを更新しますか？
モジュールがデータベースを更新したら、いくつかのことを確認する必要があります。
コアテーブルを更新しますか？はい、それは良くない場合、私達は私達のデータベースがきれいで、アップグレードの準備ができていることを好みます。
賢明な方法で情報を保存しますか？データベースから生のデータを取得したい場合、それを理解できるでしょうか？
イベント-モジュールはイベントを監視またはディスパッチしますか？
モジュールがイベントをディスパッチまたは監視する場合、次のことを知りたいと思います。
どのイベントを監視/ディスパッチしていますか？これは、システムで動作する別のモジュールに影響しますか。たとえば、モジュールの1つがロード中の製品名を大文字に変更し、このモジュールがロード中の製品名に「無料」という単語を追加した場合、どのように機能しますか？「無料」という単語も大文字になりますか？
コードレビュー-モジュールは受け入れ可能なコーディング技術を使用していますか？
これは、MagentoよりもPHPのコーディング技術に関係しています。
コードはTry / Catchブロックを使用しますか？
コードはユーザー入力をエスケープしますか？
これの詳細は本当に私たちのスキルレベル/要件に依存します。
潜在的な問題-このモジュールをインストールすると、どのような潜在的な問題が発生する可能性がありますか？
このモジュールをインストールした場合に発生する可能性のある上位5つの問題を想像してみてください。意外かもしれませんが、プロジェクト全体の洞察を本当に与えてくれます。
ボトムライン：
これらはすべて理想の世界にあるのは素晴らしいことです。現実の世界のシナリオでは、「妥協」と呼ばれるこのことを行う必要があります:)
さらに、これらのガイドラインは、1つのモジュール（ソーシャル共有モジュールなど）をインストールするだけで、簡単なサイトのセットアップが必要なクライアントのために、結果として私たちを妨げるものではなく、私たちを助けることを目的としていますたくさんの研究をする意味がありません。
言い換えれば、このガイドラインの項目を使用することで長期的に時間を節約できれば、それを落とさずに正気を保つことができれば、時間を効率的に使うことがすべてです。
Magento固有の「悪い習慣」の赤旗は次のとおりです。
app/code/local/Mageapp/design既にコアに存在します）catalog/product。一般的に、書き直されるたびに注意深く調べて、回避できたかどうかを確認しますMage::getModelテンプレートディレクトリでの発生は通常、悪い兆候です）PHP関連のレッドフラグ（これは非常に選択的で不完全なリストです）：
E_STRICT）@演算子の使用法パフォーマンス関連のレッドフラグ：
また、一般的なCode Smellsにも注意してください。これらは必須ではありませんが、全体的な品質を推定するのに役立ちます。
ステップ＃1 —開発者がAWOLに移行した場合、クライアントはこの拡張機能をサポートする余裕がありますか？
いいえの場合、拡張機能を使用できません。
はいの場合、拡張機能の評価に進みます。
Inchooの優秀なユーザーには、サードパーティのモジュールコードの分析に関する記事があります。この記事では、クラスの書き換え、cronジョブ、レイアウトの更新、イベントオブザーバーについて説明しています。
イベントオブザーバーコードには、最高のパフォーマンスヒットが発生する可能性があることがわかりました。頻繁にディスパッチされるイベントに対して実行される、リソースを集中的に使用するサードパーティコードを探してください。controller_action_predispatch、またはコレクションのロードなどのイベント。
Prattskiのこのユーティリティモジュールを使用して、書き換えとオブザーバーの概要を把握します。
*_after、*_beforeイベントの代わりにイベントを使用することが常に優先されるべきであるということです。パフォーマンスに関しては、オブザーバーに関する記述はまったくありません。
controller_action_predispatchリクエストごとに1回ディスパッチされるため、これが最良の例ではない可能性があります。ただし、パフォーマンスの問題が発生する可能性が高いことに言及しているだけで、リクエストごとに何度もディスパッチされるイベントがありますが、私は同意しません。すべての製品をロードするなど、パフォーマンスに本当に影響を与えることを行う場合、これはそれがどこで発生するかに関係なく、単独で問題となります。
base / defaultの代わりにdefault / default（またはproまたはenterprise）にテンプレートとスキンアセットを配置するのはかなり面倒です。
難読化されたコードには注意が必要です。eval（）、base64_decode（）などの呼び出しを検索してください。これは多くの場合、ライセンスの検証に使用されますが、悪意のあるものや怖いものになる可能性があります。RSSフィードから任意のコードを評価するコンポーネントを少なくとも1つ見ました。
dl（）呼び出しを探してください-私が見た少なくとも1つの支払いゲートウェイコンポーネントは、その接続を行うためにPHP拡張をインストールする必要があります！
あなたが正しいです。
残念ながら魔法はありません：それらをテストし、コードが十分に開発されているかどうかを確認し、フォーラムまたは質問への迅速な回答のおかげで商用モジュールを適切にサポートする必要があります...
Magento Connectにはいくつかのレビューがあり、拡張機能の人気はそれが価値があるかどうかを知るのに役立ちますが、正直なところ、多くのバグがある非常に人気のあるモジュールを見つけることができます。先週、MailChimpモジュールの良い例がありました。主によくできていましたが、いくつかのバグを修正し、それらを開発者に提供しなければなりませんでした。常にリスクがあり、テストする必要があります。
WebShopAppには、この方向にプッシュするというアイデアがありました。つまり、モジュールに関する優れた情報を取得するためのプラットフォームを提供するということです。アイデアは、Magentoをこの方向に進めることでした。したがって、モジュールの品質は実際の問題です。
私のアドバイス：コアテーブルの値を変更するインストール/アップグレードスクリプトを含むモジュールには特に注意してください。そのような変更をロールバックするのは必ずしも簡単ではないからです。
私が思いつく一番のテストは、コードにゼロデイのエクスプロイトを見つけることです（通常、Magento拡張機能ではそれほど難しくありません）。コードの一部に脆弱性があります）、ストップウォッチを開始します-これはまさにあなたのサイトがハッキングされたときに起こることだからです。サポートスタッフがグローバルなFTPおよびmysqlアクセスを要求した場合、PCI-DSSに違反していることを丁寧に断り、ソースコードリポジトリへの読み取り専用アクセスを許可します。
私が行う2番目のテストは、ベンダーに電話をかけて、不意を突くことです。実行する動作/単体テストの種類、使用するソース管理システム、テストするPHPのバージョン、Magentoのバージョン、テストするWebサーバー、ブラウザを使用するかどうかを尋ねますフロントエンドコンポーネントなどをテストするためのスタック。ベンダーが何を話しているのかわからない場合、沈黙する場合、または「専門家にメールを送り返す」場合は、ほとんどの場合、番号付き「バージョン管理」用のzipファイルを作成し、顧客が報告してから3か月後にバグを修正します。
PCI-DSSといえば、すべてのシステムの変更には復帰戦略も必要です。null不可の列をコアテーブルに追加するモジュールを使用すると、監査に合格する復帰戦略を維持しながら、これはほとんど不可能になります。無効にすると問題を引き起こすモジュール（読み取り：SQLエラー）から地獄のように実行します。
PCI-DSS v3
6.4.5.4バックアウト手順。
サンプリングされた変更ごとにバックアウト手順が準備されていることを確認します。
変更が失敗するか、アプリケーションまたはシステムのセキュリティに悪影響を与える場合に備えて、システムを以前の状態に復元できるように、変更ごとに文書化されたバックアウト手順が必要です。
これは、他の答えに加えて。IMOは、このプラットフォームで発生したいくつかの危険ながらくたに対する恥の壁があるはずです。