随机“关注”文件夹和“ . keep”文件

我在学铁轨。

随着时间的推移,我注意到看似随机的文件夹和文件出现在我的 Rails 应用程序的目录中。在一些文件夹中有一个 concerns文件夹,其中包含一个 .keep文件。.keep文件似乎为空。在其他文件夹中没有 concerns文件夹,但存在一个空的 .keep文件。

有人知道这些文件/文件夹是怎么处理的吗?

18969 次浏览

.keep files are 0 byte files that are there to stop empty folders from being ignored by all sorts of processes. Nothing to worry about.

.keep files are especially helpful when you want to commit empty directories with git.

Fun fact, the name .keep or .gitkeep is meaningless. you can call the file .foo for the same effect, its merely a readable convention.

The .keep files are also there to aid portage from one vcs to another, preventing the deletion of important directories when you un-merge something that would cause those directories to be empty.

For example, consider a script which attempts to cd dir into a directory that is untracked by git.

It's a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.

Concerns is a simple but powerful concept. It exists for code reusability. Basically, the idea is to extract common and / or context specific chunks of code in order to clean up the models and avoid them getting too fat and unmanageable.

I would like to specify explicitly that you should use service objects to provide functionality that's not the concern of the specific object. Eg a organisation has many users. Now the admin of organisation needs to export a CSV of all users for this organisation. This code can be placed in organisation model but since its not the responsibility of the organisation object, this code should be placed in a class where u just pass the organisation object and it returns the CSV of all users.

 class Services::GenerateCsv
def self.get_users org
#add logic the fetch users for the org and generate the CSV and return the CSV data
end
end

Whenever you need CSV generation, u can place to that logic in the above class. This approach keeps the object (in this case, the organisation model) clean from the code that shouldn't be its responsibility. A general principle that I follow is: if the code it's modifying the self object, move the code to a service object.

Note: Your question was regarding concerns but I thought of adding some extra stuff that I follow to keep the code base clean and manageable since it might help fellow programmers. That above approach is debatable.