Answers:
以下是评估第三方模块的一些想法：
基本：
当前的Magento版本支持-它是否支持Magento的最新版本（包括我们正在为其开发的最新版本）？
如果某个模块不支持Magento的最新版本，则可能不花宝贵的开发时间就很难使其工作。
支持-创建模块的开发人员是否支持该产品？
健康模块的标志之一是开发人员积极支持它。如果他们不支持它是一个危险信号，那么如果产品好，他们为什么不支持该产品呢？
此外，如果支持某个模块，通常我们可以通过简单的电子邮件从开发人员那里获取重要信息（例如，该模块是否使用jQuery或Prototype）。
评论-其他用户在说什么？他们的经历如何？
通过阅读评论，我们可以更好地了解全局，是否存在安装问题？开发人员是否及时，有帮助地做出回应？它是否如广告所示运作？
退款-如果无法正常使用，他们会退还您的钱吗？
很多时候，我们希望尝试该模块，以便我们对其进行测试（如果它可以正常工作并符合我们的规范）！但是，如果没有，我们希望选择退还并获得退款。
中间：
类覆盖-模块是否覆盖任何核心类？
一般来说，一个好的模块不应覆盖任何核心类，而应使用观察者。
原因之一是，这可能会使Magento升级变得困难。此外，其他模块可能取决于给定功能的一个输出，并且此模块提供的功能有所不同。
有时这是不可能的，如果是这种情况，应该有一个很好的理由来说明它要覆盖核心类。
布局更新-模块是否更改了某些布局设置？
某些模块会更改您网站的布局设置（例如：产品页面），确保它不会破坏您的当前布局，以及确保它满足您的要求（请阅读：需要多少时间才能解决） 。
模板更改-模块是否包含更改我当前设计的模板？
这个模块会引入新的模板吗？如果是，他们会破坏我的设计吗？按照我们想要的方式进行设计需要多少时间？
依赖关系-该模块是否依赖于其他模块？
如果模块依赖于其他模块，我们需要确保它们在那里并已安装。另外，我们需要问自己，将来是否要关闭其依赖的模块？
高级：
SQL升级脚本-模块是否以某种方式更新数据库？
模块更新数据库后，我们需要确定一些事项。
它会更新核心表吗？如果是，那就不好了，我们希望我们的数据库干净并可以升级。
它是否以明智的方式存储信息？如果我们想自己从数据库中获取原始数据，我们是否可以理解它？
事件-模块是否观察或调度任何事件？
如果模块调度或观察事件，我们想知道：
它观察/调度哪些事件？这会影响系统中另一个工作的模块吗？例如，如果我们的一个模块将负载商品的名称更改为大写，并且此模块在负载商品的名称上添加了“免费”一词，它将如何工作？“免费”一词也会大写吗？
代码审查-模块是否使用可接受的编码技术？
与Magento相比，这更多与PHP编码技术有关。
代码是否使用Try / Catch块？
代码是否会转义用户输入？
具体细节确实取决于我们的技能水平/要求。
潜在问题-安装此模块会导致哪些潜在问题？
试想一下，如果我们安装此模块，可能会遇到的五个最主要的问题，可能令人惊讶，它确实使您对整个项目有了深入的了解。
底线：
在理想的世界中拥有所有这些东西真是太好了，在现实世界中，我们需要做被称为“妥协”的事情:)
此外，这些准则旨在为我们提供帮助，而不是阻碍我们，因此，如果我们仅安装一个模块（例如社交共享模块），并且该模块适用于需要简单站点设置的客户，做大量研究是没有意义的。
换句话说：这与我们的时间效率有关，如果使用此准则（项目中的准则）可以帮助我节省长期使用的时间，即使不放弃它也可以节省理智。
一些Magento特定的“不良做法”危险信号是：
app/code/local/Mageapp/design已经存在于核心中）catalog/product。总的来说，我会仔细检查每一次重写，看看是否可以避免Mage::getModeltemplate目录中的任何出现通常都是不好的迹象）一些与PHP相关的危险信号（这是一个非常有选择性和不完整的列表）：
E_STRICT）@操作员的用法一些与性能相关的危险信号：
还应注意一般的Code Smells，这些不是必需的危险信号，但有助于估计总体质量。
步骤＃1 —如果开发人员使用AWOL，您的客户能否负担得起该扩展程序的费用？
如果否，则无法使用扩展名。
如果是，请继续进行扩展评估。
Inchoo的优秀人员撰写了一篇有关分析第三方模块代码的文章。本文提到了类重写，cron作业，布局更新和事件观察器。
我发现事件观察者代码具有获得最高性能的潜力。请注意为频繁调度的事件运行的资源密集型第三方代码。诸如controller_action_predispatch或集合加载之类的事件。
我使用Prattski的此实用程序模块对重写和观察者进行了很好的概述。
*_after事件而不是*_before事件。在性能方面，根本没有关于观察者的声明。
controller_action_predispatch每个请求发送一次，所以这也许不是最好的例子。但是，尽管您只提到了出现性能问题的高可能性，并且每个请求分配了很多次事件，但我不同意：观察者与其他任何代码相比都不太可能出现性能问题。如果您执行诸如加载所有产品之类的会真正影响性能的事情，那么无论它发生在哪里，这都是一个问题。
你是对的。
不幸的是没有魔术：您必须测试它们，检查代码以查看其是否开发完善，由于其论坛或快速回答您的问题，因此对商业模块具有良好的支持...
Magento Connect上有一些评论，扩展的受欢迎程度可以帮助您知道它是否有价值，但是说实话，您可以找到非常流行的模块，其中包含很多错误。上周我有一个关于MailChimp模块的很好的例子，基本上做得很好，但是我不得不修复一些错误并将其提供给开发人员。总是有风险，您必须进行测试。
WebShopApp的想法是朝这个方向发展，我的意思是提供一个平台来获取有关模块的良好信息。这个想法是将Magento推向这个方向。因此，模块质量是一个实际的问题。
我的建议：要特别注意那些具有安装/升级脚本的模块，这些模块会更改核心表中的值，因为回退这种更改并不总是那么容易。
我可以提出的＃1测试是在他们的代码中找到一个零日漏洞利用（通常对于Magento扩展来说不是很难），仅向其安全团队报告模拟漏洞造成的破坏（没有表明哪个漏洞）代码的一部分很容易受到攻击），然后启动秒表-因为这正是您的网站遭到黑客入侵时将要发生的情况。当他们的支持人员要求全局FTP和mysql访问时，婉言拒绝指出它违反了PCI-DSS，并提议让他们对您的源代码存储库具有只读访问权限。
我执行的＃2测试是呼叫供应商并使其措手不及。询问他们进行哪种行为/单元测试，使用哪种源代码控制系统，测试哪种PHP版本，测试哪种Magento版本，测试哪种Web服务器，是否使用浏览器-用于测试前端组件等的堆栈...如果供应商不知道您在说什么，保持沉默或想要“请专家给您发电子邮件”，请像地狱一样运行，因为他们最有可能使用编号用于“版本控制”的zip文件，仅在客户报告错误后3个月内修复错误。
说到PCI-DSS，还需要对所有系统进行修改以具有恢复策略。使用将不可为空的列添加到核心表的模块，这几乎是不可能的，同时仍保持可通过审核的恢复策略。在禁用时会导致问题（阅读：SQL错误）的任何模块都可以像地狱般运行。
PCI-DSS v3
6.4.5.4退出程序。
验证是否为每个样本变更都准备了退出程序。
对于每次更改，应记录有记录的退出程序，以防更改失败或对应用程序或系统的安全性产生不利影响，以使系统恢复到以前的状态
除了其他答案之外，这也是。海事组织（IMO）应该为在该平台上产生的一些危险废话而感到羞耻。