在我目前的项目中，我注意到一些事情，
这些点遵循良好的编码惯例吗？如果没有，你能否建议我提高性能的最佳编码标准？
答案 0 :(得分：3)
首先，惯例本身与性能无关。
业务逻辑的最大部分被移动到帮助者。
我会说这很糟糕。其中一个流行的习语是“肥胖的模特，瘦小的控制者”，大部分时间都在工作。将您可以使用的所有业务逻辑放在您所属的模型中。如果您想要简化您真正复杂的视图，请使用装饰器（例如draper gem），然后将业务逻辑（模型）和视图逻辑（装饰器）分离到相应的位置。
在lib目录下的模块中包含所有帮助程序文件，并将该模块包含在应用程序控制器中。
好的，我想。只要你有一个地方可以维护这条链，感觉还可以。如果它导致误解/误解/黑客攻击，那么：不行。
在许多方法中，没有传递参数，而是使用了实例变量
如果您正在讨论模型中的方法：这很好，因为该方法的目标是您的实例范围，而不是您的类。
每个动作都会调用一个辅助方法来执行业务逻辑，该方法将调用其他一些辅助方法。
听起来很奇怪。控制器负责准备视图中使用的数据。如果您正在帮助程序中准备特定数据以将它们分配给您的视图以供使用，请考虑将它们放入装饰器中（如上所述）。但几乎在每一个动作中都要求助手听起来像是做错了。
所有方法都是公共的，没有受保护的私有方法。
非公开方法不应公开。从ActionController查看helper_method和hide_action。
模型仅用于验证。
错误。如上所述，模型包含业务逻辑。如何在控制台中修改内容？您想要手动更新所有逻辑相关数据吗？你现在在控制器中“手动”执行此操作（看起来像这样）？当你介绍一个API时，你是否将代码复制粘贴到那里以免错过某些逻辑？当逻辑发生变化时，您是否确实手动并且独立处理该逻辑所需的所有端点也会更新？
模型有关系，回调和实例方法是有原因的。使用它们！
答案 1 :(得分：1)
表现与你的论点无关;他们是关于项目组织的。
业务逻辑的最大部分被移动到帮助者
这不应该发生，你应该在模型中移动业务（aka模型）逻辑。 Rails并没有强迫你这样做，因此保持逻辑组织取决于开发人员。
模型仅用于验证
这是将业务（又称模型）逻辑置于模型之外的结果。您应该将它从控制器/帮助器移动到模型。同样，Rails并没有强迫你这样做，所以开发人员可以这样做。
在lib目录下的模块中包含所有帮助程序文件，并将该模块包含在应用程序控制器中。
在许多方法中，没有传递参数，而是使用实例变量（在调用方法中创建实例变量并在被调用方法中使用该实例变量）。
每个动作都会调用一个辅助方法来执行业务逻辑，该方法将调用其他一些辅助方法。
所有方法都是公开的，没有受保护的私有方法。
我认为这些要点（更多，更少）与Rails Helper设计有关。 Rails的一个缺陷是Helper设计：它们违背了OO模式，通常最终成为一堆无组织的函数，àla PHP。
出于这个原因，有些人使用装饰器。装饰者“添加OO层的表示逻辑”（来自Draper），允许更好地组织与视图相关的方法。
如果您想检查参数，我建议您使用以下链接：