活动作业的命名约定

Question

我想知道 Active Job 类是否有任何命名约定。我看到了不同的变体。例如，verb + noun job喜欢SendNotificationJob，SendNewUserInvitationJob或anything + noun喜欢TweetNotifictorJob，GuestsCleanupJob。你们给工作命名的规则是什么？

Answer 1

verb + noun是一个合理的模板。如果特定的参与者很重要，那么我喜欢使用像 的约定verb + noun + actor，PublishArticleAsAuthorJob但是只有当负责该工作的参与者的区别很重要时，这才有用。例如，我可能期望PublishArticleAsAdminJob将来是否还有 a 或 might be 。另外，我经常重命名一些东西，所以我很可能只是命名它PublishArticleJob，然后如果我以后制作一个，PublishArticleAsAdminJob我会将现有的重命名为PublishArticleAsAuthorJob.

我也倾向于按照层次结构对单词进行排序，所以可能是这样resource + verb。因此，当我扫描按字母顺序排列的文件/模块列表时，我可以快速查看列表中彼此相邻的 相关项目，例如ArticlePublishJob和。ArticleCreateJob

我喜欢将动词保留在有限集合中，例如Build（实例化而不持久化）Create（实例化并持久化）、Save（保存在其他地方构建的实例）、Find（在本地数据库、文件系统或数据结构中查找）、Fetch（如果存在，否则生成或获取，确保下次立即存在，然后返回）。

像这样的非标准动词Publish应该对应于相关资源上定义的转换，因此我希望模型publish!上有一个方法Article。如果Article模型本身不知道如何publish，并且例如，如果发布包括在已发布文章列表中创建记录，那么该工作将类似于CreatePublishingEntryJob(publishing_entries是一个尴尬的资源名称，值得更多思考，但这不是这里的重点），这让我回到了标准动词领域。

我不能声称我的约定在这里是“正确的”，但这些细节旨在提供一些想法。有限动词集的想法源于对 REST 架构的研究，在 REST 架构中/article/:id/publish，我可能会对 执行 POST /publish_article_jobs，而不是对 进行 PATCH，因为我实际操作的资源不是文章，而是作业。

将非标准动词变成标准动词的另一个例子是在相应的路线、控制器、工作等中 tag an article替换为。create a tagging

再说一遍，只是一组想法。不在这里声称“正确”地位。

我命名的一般经验法则是：如果我能想到一个事物的两个或多个可能的名称，我应该继续考虑该命名，直到只有一个可能的名称为止。这很棒，因为以后如果我需要一个东西，并且我使用相同的命名过程来解析为一个可能的名称，我只需将生成的文件名输入到编辑器的文件打开器中，瞧，文件就出来了。即使我五年前编写了代码，我也可以想“我想知道我是否有......create_tagging_job.rb并且该文件的存在回答了我的问题。