verb + noun - разумный шаблон. Если конкретный актер является значимым, то мне нравится использовать соглашение типа verb + noun + actor, такое как PublishArticleAsAuthorJob, однако это полезно только в том случае, если различие в том, какой актер отвечает за работу, является значительным. Например, я мог бы ожидать, что, если есть также PublishArticleAsAdminJob или может быть в будущем. Кроме того, я часто переименовываю материал, поэтому я, скорее всего, просто назову его PublishArticleJob, а затем, если позже я сделаю PublishArticleAsAdminJob, я переименую существующий в PublishArticleAsAuthorJob.
Я также склоняюсь к упорядочению слов в терминах иерархии, поэтому это может быть resource + verb. Это так, когда я сканирую алфавитный список файлов / модулей, я могу быстро увидеть связанные элементы, такие как ArticlePublishJob и ArticleCreateJob рядом друг с другом в списке.
Мне нравится хранить свои глаголы в ограниченном наборе, например Build (создавать без сохранения) Create (создавать и сохранять), Save (сохранять экземпляр, созданный в другом месте), Find (найти в локальной базе данных, файловой системе или структуре данных), Fetch (вернуть, если присутствует, иначе сгенерировать или получить, обеспечить немедленное присутствие в следующий раз и вернуться).
Нестандартный глагол, такой как Publish, должен соответствовать определенному переходу на рассматриваемом ресурсе, поэтому я ожидаю, что в модели Article будет метод publish!. Если модель Article не знает, как publish сама, и если, например, публикация состоит из создания записи в списке опубликованных статей, то работа будет выглядеть примерно так: CreatePublishingEntryJob (publishing_entries неудобно название ресурса, которое заслуживает большего внимания, но это не относится к делу), что возвращает меня к стандартной территории глагола.
Я не могу утверждать, что мое соглашение здесь «правильное», но эти детали предназначены для того, чтобы дать некоторые идеи. Идея конечного набора глаголов возникла из изучения архитектуры REST, где вместо PATCH до /article/:id/publish я мог бы сделать POST до /publish_article_jobs, потому что ресурс, над которым я на самом деле действую, не является Articles, это Работа.
Другим примером превращения нестандартных глаголов в стандартные глаголы будет замена tag an article на create a tagging на соответствующих маршрутах, контроллерах, заданиях и т. Д. c.
Еще раз, просто набор идей. Не претендует на статус «праведности» здесь.
Мое общее эмпирическое правило для именования таково: если я могу придумать два или более возможных имени для вещи, я должен продолжать думать об этом наименовании, пока для него не будет только одного возможного имени. Это замечательно, потому что позже, если мне понадобится что-то, и я использую тот же процесс именования, чтобы разрешить одно возможное имя, я могу просто напечатать полученное имя файла в открывателе файлов моего редактора и вуаля, есть файл. Даже если я написал код пять лет go, я могу подумать: «Интересно, у меня есть ... create_tagging_job.rb, и наличие файла отвечает на вопрос для меня.