¿Qué ventajas y desventajas habría para save el código de forma más detallada a nivel de file?

¿Qué piensas de este tipo de mapeo de código a file?

~/proj/MyClass.ext ~/proj/MyClass:constructors.ext ~/proj/MyClass:properties.ext ~/proj/MyClass:method-one.ext ~/proj/MyClass:method-two:int.ext ~/proj/MyClass:method-two:string.ext 

En un lenguaje que es más funcional orientado:

 ~/proj/definitions.ext ~/proj/function-one.ext ~/proj/function-two:int.ext ~/proj/function-two:string.ext ... 

El punto sería que cuando estamos trabajando en nuestro proyecto, no vemos esta multiplicidad de files.

Es posible que tengamos algún tipo de process de daemon que mantenga un file MyClass.ext perfectamente sincronizado con este grupo de files, o nuestro editor de código favorito los ve a todos, pero los muestra como su agregación lógica, o este tipo de conversión solo ocurre como un set de ganchos pre + post-commit.

Ahora, dado que no estaríamos interesados ​​en la implementación de esta idea si no es una buena idea, no nos molestemos con sus detalles de implementación (el cómo); supongamos que tenemos la implementación perfecta que haría que esta idea funcione bien para nosotros.

Lo que me gustaría que encontráramos juntos es una buena list de pros y contras de este enfoque , tanto a un alto nivel como a niveles bajos más específicos de su preocupación.

Cuando terminemos la lluvia de ideas y veamos los votos de cada respuesta, deberíamos ver fácilmente si esta es una buena idea o no. Por lo tanto, por favor escriba un pro / con por respuesta.

EDITAR

De todas las respuestas y especialmente de Scott, deduje que la única forma real en que mi idea podría ser útil sería la de poder include una list automática de class:method modificadas class:method parejas de class:method en la parte detallada de cada post commit-to-vcs. Esto podría lograrse mucho más fácilmente con scripts pequeños que se ejecutan antes de los commits, para actualizar la plantilla del post en consecuencia.

Quizás la mejor pregunta para responder es: ¿Cuál es el problema que esperarías resolver con este enfoque?

Los lenguajes .NET admiten cierto nivel de esta idea con classs parciales, aunque nunca lo he visto llevado hasta ese extremo y la experiencia de edición no es tan fluida como usted describe en su "implementación perfecta".

Realmente no puedo ver la utilidad de tal escenario. Sí, tener varios files significa less riesgo potencial de un cambio que afecte a otras partes del código, pero no creo que supere el impacto en el performance de analizar los files para mostrarlo como un file editable.

ESTAFA

La class por file te permite envolver tu cerebro en toda la class como un todo. Si sus classs son grandes hasta el punto de ser muchas monstruosidades de varias páginas, es posible que deba dividir los methods en files separados, pero también podría refactorizarse y ahorrarse un poco de dolor de cabeza por el mantenimiento. Este es uno de los arguments en contra de #region también.

Creo que, como todo, tiene que ser un equilibrio, y parece que los Frameworks suelen estar a ambos lados del espectro.

alias Camping vs. Rails et al.

El nivel de granularidad que trazaste arriba parece un poco exagerado para mí. Preveo que refactorizar es una pesadilla. Incluso en frameworks como ASP.net y Ruby on Rails, me encuentro constantemente limpiando mi espacio de trabajo porque tengo demasiados files abiertos y está causando problemas de productividad.

  • con: muchos files abiertos al desarrollar
  • con: refactorización sería complicado y desorientador
  • con: más propenso a los files que rompen las convenciones de nomenclatura e interferencia con los errores de syntax reales
  • Con: para los lenguajes interpretados, los arneses de testing deberían include muchos más files. Tendría que haber algunos methods inteligentes de inclusión para get todo lo que se necesitaba para interpretar una class.
  • con: el sistema de files es less representativo de la orientación de un object; a veces es agradable poder determinar fácilmente las classs en una carpeta determinada.

Lo siento, quiero ofrecer un profesional aquí, pero simplemente no me viene

Espacio en disco duro.

En una installation pnetworkingeterminada de Windows, cada file ocupa al less 4k. Otros filesystems pueden tardar más o less, pero casi siempre hay un tamaño mínimo. Pude ver un gran proyecto de software que de repente ocupaba una gran cantidad de espacio en disco con este sistema. Esto podría no ser un gran problema en las máquinas del desarrollador, pero me preocuparía el server de control de código fuente, ya que parece que los serveres nunca tienen suficiente espacio en disco.

Estoy de acuerdo, esto es demasiado detallado.

Sin embargo, he considerado separar miembros por scope:

 ClassA-interface.cs (miembros públicos)
 ClassA-implementation.cs (miembros no públicos)

Por supuesto, puedes ir más allá, pero incluso esta bifurcación no "resuelve un problema" que tengo. Si bien me haría más consciente de los cambios que puedan afectar el código del cliente, será mejor que lo aprenda a través de las testings.

PRO:

Me he dado count de que muchas bibliotecas de GNU C dividen su fuente en 1 function por cada file de unidad de traducción. De lo que deduzco es para ayudar a vincular estáticamente la biblioteca en un file binary. Aparentemente, al search un símbolo, el linker includeá toda la unidad de traducción en la que reside el símbolo (lo cual tiene sentido, ya que puede haber funciones estáticas y datos en la unidad de los que depende el símbolo). Por lo tanto, si divide su código en files granulares, es posible que pueda mantener los tamaños de files vinculados estáticos al mínimo.

Me imagino que en C ++ hay less beneficios, especialmente para las classs con miembros virtuales, ya que la tabla virtual introduciría múltiples dependencies de símbolos.


ESTAFA:

A less que tenga soporte IDE incorporado para este mapeo, parece que el mantenimiento de cualquier cosa a nivel de granularidad de los methods sería problemático ya que las personas realizan cambios al por mayor en las classs. En los proyectos en los que trabajo, las funciones get se renombrarán ocasionalmente para reflejar con mayor precisión su comportamiento cambiante. Agregar un nuevo nombre al nombre de la function es un paso más para que la gente lo arruine.

Algunos sistemas de control de versiones, especialmente Git (y probablemente BitKeeper), funcionan en este nivel por layout, en lugar de a nivel de file.

Pro: especialmente cuando se refactoriza (en las twigs), esto puede ser muy útil (pudiendo especificar que un método único se haya movido de una class a otra, o que una parte de una class se haya movido). Un sistema que funciona en un nivel inferior de granularidad que los files podría resolver los conflictos de combinación más fácilmente (porque puede rastrear dónde se ha movido un método y puede aplicar los cambios según corresponda a varios files).


Con: Creo que realmente necesita un VCS que lo admita por layout, en lugar de tratar de pegarlo con cinta adhesiva en un file basado en VCS (Git no funciona demasiado bien en Windows, y BitKeeper es un software comercial). Otro inconveniente es que probablemente no puedas hacerlo de una manera independiente del idioma. AFAIK, Git emplea heurística avanzada para rastrear las piezas individuales de un file, pero no es infalible, y puede haber algunos lenguajes con una syntax de function / método no estándar (no similar a C) donde la heurística convencional puede fallar (pnetworkingicados de Prolog) .

Personalmente, encontraría que ese tipo de separación, aunque posible en algunos idiomas, sería una pesadilla para mantener, y haría muy difícil seguir el código. Personalmente encuentro que con los idiomas .NET las regiones en el código son mucho más útiles.

Me preocuparía en proyectos grandes con la gran cantidad de files.

Con un punto de vista de performance, todas estas E / S de file podrían costar mucho en grandes treees de trabajo.

Los sets de cambios Pro Commit deben contener mucha más información sobre lo que realmente sucedió para que este compromiso cobre vida sin tener que mostrar un diff:

  • Muchos files enumerados para la misma class sugieren que se haya refactorizado;
  • Por el contrario, solo un cambio de file listdo para una class sugeriría que su comportamiento solo ha sido ligeramente modificado.
    Intereting Posts