我想知道Active Job类是否有任何命名约定。我看到了不同的变体。例如,像verb + noun job
,SendNotificationJob
之类的SendNewUserInvitationJob
或像anything + noun
,TweetNotifictorJob
之类的GuestsCleanupJob
。您的职位命名规则是什么?
verb + noun
是一个合理的模板。如果特定的角色很重要,那么我喜欢使用诸如verb + noun + actor
之类的约定,例如PublishArticleAsAuthorJob
,但这仅在区分哪个角色负责工作的情况下才有用。例如,我可能希望将来也有PublishArticleAsAdminJob
。另外,我还对很多东西进行了重命名,所以我很可能只是将其命名为PublishArticleJob
,然后如果以后再创建一个PublishArticleAsAdminJob
,则将现有的名称重命名为PublishArticleAsAuthorJob
。
我也倾向于按照层次结构对单词进行排序,因此可能是resource + verb
。因此,当我按字母顺序扫描文件/模块列表时,可以快速看到列表中彼此相邻的相关项目,例如ArticlePublishJob
和ArticleCreateJob
。
[我喜欢将动词限制为一个有限的集合,例如Build
(实例化而不持久化)Create
(实例化并持久化),Save
(保存在其他地方构建的实例),Find
(查找在本地数据库,文件系统或数据结构中),Fetch
(如果存在则返回,否则生成或获取,确保下次立即存在并返回)。
Publish
之类的非标准动词应对应于所讨论资源上的已定义过渡,因此我希望publish!
模型上存在Article
方法。如果Article
模型不知道如何publish
本身,并且例如,如果发布包含在已发布文章列表中创建记录,则工作将类似于CreatePublishingEntryJob
(publishing_entries
很尴尬资源名称值得更多思考,但它不在这里),这使我回到了标准动词领域。
我不能在这里声明我的约定是“正确的”,但是这些详细信息旨在提供一些想法。动词集有限的想法来自研究REST体系结构,其中我可能不对/article/:id/publish
进行PATCH,而对/publish_article_jobs
进行了POST,因为我实际使用的资源不是Articles,而是职位。
将非标准动词变成标准动词的另一个示例是在相应的路线,控制器,作业等上将tag an article
替换为create a tagging
。>
再次,只是一组想法。这里不要求“正确”状态。
我命名的一般经验法则是这样的:如果我可以为一个事物想到两个或多个可能的名称,那么我应该继续考虑该命名,直到只有一个可能的名称为止。这很棒,因为以后如果我需要一个东西,并且使用相同的命名过程将其解析为一个可能的名称,我只需将生成的文件名键入编辑器的文件打开器中,瞧,就有文件了。即使我在五年前编写了代码,我也可以认为“我想知道我是否有... create_tagging_job.rb
,并且文件的存在为我解答了这个问题。