Estou aprendendo trilhos.
Em algum lugar ao longo da linha, percebi que pastas e arquivos aparentemente aleatórios estão aparecendo no diretório do meu aplicativo Rails. Em algumas pastas, há uma concernspasta com um .keeparquivo dentro dela. O .keeparquivo parece estar vazio. Em outras pastas, não há concernspasta, mas um .keeparquivo vazio está presente.
Alguém sabe o que está acontecendo com esses arquivos / pastas?
Respostas:
.keepos arquivos são arquivos de 0 byte que impedem que pastas vazias sejam ignoradas por todos os tipos de processos. Nada para se preocupar.
.gitignore? Prefiro não enviar arquivos vazios.
Os arquivos .keep são especialmente úteis quando você deseja comprometer diretórios vazios com o git.
Curiosidade, o nome .keepou .gitkeepnão tem sentido. você pode chamar o arquivo .foopara o mesmo efeito, é apenas uma convenção legível.
Os .keeparquivos também estão lá para ajudar a portagem de um vcs para outro, evitando a exclusão de diretórios importantes quando você desfaz a mesclagem de algo que faria com que esses diretórios ficassem vazios.
Por exemplo, considere um script que tenta cd direntrar em um diretório que não é rastreado pelo git.
É um paradigma de design de software que busca diminuir o número de decisões que os desenvolvedores precisam tomar, ganhando simplicidade, mas não necessariamente perdendo flexibilidade.
Preocupações é um conceito simples, mas poderoso. Ele existe para reutilização de código. Basicamente, a ideia é extrair pedaços de código comuns e / ou específicos do contexto para limpar os modelos e evitar que fiquem muito gordos e incontroláveis.
Gostaria de especificar explicitamente que você deve usar objetos de serviço para fornecer funcionalidade que não é a preocupação do objeto específico. Por exemplo, uma organização tem muitos usuários. Agora, o administrador da organização precisa exportar um CSV de todos os usuários desta organização. Este código pode ser colocado no modelo de organização, mas como não é de responsabilidade do objeto da organização, este código deve ser colocado em uma classe onde você apenas passa o objeto da organização e ele retorna o CSV de todos os usuários.
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
Sempre que você precisar de geração de CSV, você pode colocar essa lógica na classe acima. Essa abordagem mantém o objeto (neste caso, o modelo de organização) limpo do código que não deveria ser de sua responsabilidade. Um princípio geral que sigo é: se o código está modificando o objeto self, mova o código para um objeto de serviço.
Observação: sua pergunta era sobre preocupações, mas pensei em adicionar algumas coisas extras que sigo para manter a base de código limpa e gerenciável, pois pode ajudar outros programadores. Essa abordagem acima é discutível.