Cartelle 'preoccupazioni' casuali e file '.keep'

Question

I am learning rail.

Da qualche parte lungo la linea, ho notato che cartelle e file apparentemente casuali appaiono nella directory dell'app dei miei binari. In alcune cartelle c'è una cartella concerns con un file .keep al suo interno. Il file .keep sembra essere vuoto. In altre cartelle non è presente la cartella concerns ma è presente un file vuoto .keep.

Qualcuno sa qual è l'accordo con questi file/cartelle?

Answer 1

.keep I file sono file di 0 byte che sono lì per impedire che le cartelle vuote vengano ignorate da tutti i tipi di processi. Nulla di cui preoccuparsi.

Answer 2

.keep file sono particolarmente utili quando si desidera eseguire il commit di directory vuote con git.

Il fatto è che il nome .keep o .gitkeep non ha significato. puoi chiamare il file .foo per lo stesso effetto, è semplicemente una convenzione leggibile.

I file .keep sono anche lì per facilitare il portage da un vcs a un altro, impedendo la cancellazione di directory importanti quando si unifica un elemento che causerebbe la svuotamento di tali directory.

Ad esempio, si consideri uno script che tenta di cd dir in una directory che non è tracciata da git.

È un paradigma di progettazione software che cerca di ridurre il numero di decisioni che gli sviluppatori devono prendere, ottenendo semplicità, ma non necessariamente perdendo flessibilità.

Answer 3

La preoccupazione è un concetto semplice ma potente. Esiste per la riusabilità del codice. Fondamentalmente, l'idea è di estrarre pezzi di codice comuni e/o specifici al contesto per ripulire i modelli ed evitare che diventino troppo grassi e ingestibili.

Desidero specificare esplicitamente che è necessario utilizzare gli oggetti di servizio per fornire funzionalità che non riguardano lo specifico oggetto. Ad esempio, un'organizzazione ha molti utenti. Ora l'amministratore dell'organizzazione deve esportare un CSV di tutti gli utenti per questa organizzazione. Questo codice può essere inserito nel modello di organizzazione ma poiché non è la responsabilità dell'oggetto dell'organizzazione, questo codice deve essere inserito in una classe in cui si passa solo l'oggetto dell'organizzazione e si restituisce il CSV di tutti gli utenti.

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 

Ogni volta che hai bisogno della generazione CSV, puoi inserire quella logica nella classe precedente. Questo approccio mantiene l'oggetto (in questo caso il modello organizzativo) pulito dal codice che non dovrebbe essere di sua competenza. Un principio generale che seguo è: se il codice sta modificando l'oggetto autonomo, sposta il codice su un oggetto servizio.

Nota: la domanda riguardava problemi, ma ho pensato di aggiungere alcuni elementi aggiuntivi che seguo per mantenere il codice base pulito e gestibile in quanto potrebbe aiutare gli altri programmatori. Questo approccio sopra è discutibile.