Cartelle "preoccupazioni" casuali e file ".keep"

Sto imparando i binari.

Da qualche parte lungo la linea, ho notato che cartelle e file apparentemente casuali appaiono nella directory della mia app di rails. In alcune cartelle è presente una concernscartella con un .keepfile al suo interno. Il .keepfile sembra essere vuoto. In altre cartelle non c'è nessuna concernscartella ma .keepè presente un file vuoto .

Qualcuno sa qual è il problema con questi file / cartelle?

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

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

Fatto divertente, il nome .keepo non ha .gitkeepsignificato. puoi chiamare il file .fooper lo stesso effetto, è semplicemente una convenzione leggibile.

I .keepfile sono anche lì per aiutare il portage da un vcs a un altro, impedendo la cancellazione di directory importanti quando unisci qualcosa che renderebbe quelle directory vuote.

Ad esempio, si consideri uno script che tenta di accedere a cd diruna directory non tracciata da git.

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

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

Vorrei specificare esplicitamente che è necessario utilizzare oggetti di servizio per fornire funzionalità che non sono di interesse per l'oggetto specifico. 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 è responsabilità dell'oggetto dell'organizzazione, questo codice deve essere inserito in una classe in cui si passa semplicemente l'oggetto dell'organizzazione e 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 sopra. Questo approccio mantiene l'oggetto (in questo caso, il modello di organizzazione) pulito dal codice che non dovrebbe essere di sua responsabilità. Un principio generale che seguo è: se il codice sta modificando l'oggetto self, sposta il codice in un oggetto servizio.

Nota: la tua domanda riguardava le preoccupazioni, ma ho pensato di aggiungere alcune cose extra che seguo per mantenere la base di codice pulita e gestibile poiché potrebbe aiutare gli altri programmatori. Questo approccio di cui sopra è discutibile.