Carpetas aleatorias de 'preocupaciones' y archivos '.keep'

Estoy aprendiendo rieles.

En algún momento a lo largo de la línea, me di cuenta de que aparecen carpetas y archivos aparentemente aleatorios en el directorio de mi aplicación rails. En algunas carpetas hay una concernscarpeta con un .keeparchivo dentro. El .keeparchivo parece estar vacío. En otras carpetas no hay concernscarpeta pero hay un .keeparchivo vacío .

¿Alguien sabe cuál es el problema con estos archivos / carpetas?

.keepLos archivos son archivos de 0 bytes que están ahí para evitar que las carpetas vacías sean ignoradas por todo tipo de procesos. Nada de que preocuparse.

Los archivos .keep son especialmente útiles cuando desea confirmar directorios vacíos con git.

Dato curioso, el nombre .keepo no .gitkeeptiene sentido. puede llamar al archivo .foopara obtener el mismo efecto, es simplemente una convención legible.

Los .keeparchivos también están allí para ayudar a la transferencia de un vcs a otro, evitando la eliminación de directorios importantes cuando se deshace algo que haría que esos directorios estuvieran vacíos.

Por ejemplo, considere un script que intenta cd diringresar a un directorio que git no rastrea.

Es un paradigma de diseño de software que busca disminuir la cantidad de decisiones que los desarrolladores deben tomar, ganando simplicidad, pero no necesariamente perdiendo flexibilidad.

Preocupaciones es un concepto simple pero poderoso. Existe para la reutilización del código. Básicamente, la idea es extraer fragmentos de código comunes y / o específicos del contexto para limpiar los modelos y evitar que se vuelvan demasiado gordos e inmanejables.

Me gustaría especificar explícitamente que debe utilizar los objetos de servicio para proporcionar una funcionalidad que no es de interés para el objeto específico. Por ejemplo, una organización tiene muchos usuarios. Ahora, el administrador de la organización debe exportar un archivo CSV de todos los usuarios de esta organización. Este código se puede colocar en el modelo de organización, pero como no es responsabilidad del objeto de la organización, este código debe colocarse en una clase en la que simplemente se pasa el objeto de la organización y devuelve el CSV de todos los usuarios.

 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

Siempre que necesite la generación de CSV, puede colocar esa lógica en la clase anterior. Este enfoque mantiene el objeto (en este caso, el modelo de organización) limpio del código que no debería ser su responsabilidad. Un principio general que sigo es: si el código modifica el objeto self, mueva el código a un objeto de servicio.

Nota: Su pregunta era sobre inquietudes, pero pensé en agregar algunas cosas adicionales que sigo para mantener la base del código limpia y manejable, ya que podría ayudar a otros programadores. Ese enfoque anterior es discutible.