TD; DR:
Hubo cierta confusión en cuanto a lo que estaba preguntando, así que aquí está la idea principal detrás de la pregunta:
Siempre quise que la pregunta fuera qué es. Puede que no lo haya articulado bien originalmente. Pero la intención siempre ha sido " es un código modular, separado, desacoplado, desacoplado y refactorizado " notablemente más lento por su propia naturaleza que el código " monolítico de una sola unidad, hacer todo en un solo lugar, un archivo, estrechamente acoplado ". El resto son solo detalles y varias manifestaciones de esto que encontré entonces o ahora o lo haré más tarde. Es más lento con seguridad en alguna escala. Al igual que un disco no desfragmentado, debe recoger las piezas de todas partes. Es mas lento. Sin lugar a duda. ¿Pero debería importarme?
Y la pregunta no es sobre ...
no se trata de micro-optimización, optimización prematura, etc. No se trata de "optimizar esta o aquella parte hasta la muerte".
¿Entonces que es?
Se trata de la metodología general y las técnicas y formas de pensar sobre la escritura de código que surgió con el tiempo:
- "inyecta este código en tu clase como una dependencia"
- "escribe un archivo por clase"
- "separe su vista de su base de datos, controlador, dominio".
- no escriba spaghetti homogeneious single codeblock, sino que escriba muchos componentes modulares separados que trabajen juntos
Se trata de la forma y el estilo del código que actualmente, dentro de esta década, es visto y defendido en la mayoría de los marcos, defendido en las convenciones, transmitido a través de la comunidad. Es un cambio en el pensamiento de 'bloques monolíticos' a 'microservicios'. Y con eso viene el precio en términos de rendimiento y gastos generales a nivel de máquina, y también algunos gastos generales a nivel de programador.
La pregunta original sigue:
En el campo de la informática, he notado un cambio notable en el pensamiento cuando se trata de programación. A menudo me encuentro con el consejo que dice así:
- escribir código más pequeño en función de las funciones (más comprobable y mantenible de esta manera)
- refactorice el código existente en fragmentos de código cada vez más pequeños hasta que la mayoría de sus métodos / funciones tengan solo unas pocas líneas y quede claro cuál es su propósito (que crea más funciones, en comparación con un bloque monolítico más grande)
- escribir funciones que solo hacen una cosa: separación de preocupaciones, etc. (que generalmente crea más funciones y más marcos en una pila)
- cree más archivos (una clase por archivo, más clases para propósitos de descomposición, para propósitos de capa como MVC, arquitectura de dominio, patrones de diseño, OO, etc., que crea más llamadas al sistema de archivos)
Este es un cambio en comparación con las prácticas de codificación "antiguas" u "anticuadas" o "espaguetis" en las que tiene métodos que abarcan 2500 líneas, y grandes clases y objetos divinos que hacen todo.
Mi pregunta es esta:
cuando se trata de código de máquina, de 1s y 0s, de instrucciones de ensamblaje, de discos HDD, ¿debería preocuparme si mi código OO perfectamente separado por clases con una variedad de funciones y métodos refactorizados de pequeño a pequeño también genera mucho más gastos generales?
Detalles
Si bien no estoy muy familiarizado con la forma en que el código OO y sus llamadas a métodos se manejan en ASM al final, y cómo las llamadas DB y las llamadas del compilador se traducen en mover el brazo del actuador en un disco HDD, tengo una idea. Supongo que cada llamada de función adicional, llamada de objeto o llamada "#include" (en algunos idiomas) genera un conjunto adicional de instrucciones, lo que aumenta el volumen del código y agrega varios gastos generales de "cableado de código", sin agregar el código "útil" real . También imagino que se pueden hacer buenas optimizaciones para ASM antes de que realmente se ejecute en el hardware, pero esa optimización solo puede hacer mucho.
Por lo tanto, mi pregunta: cuánta sobrecarga (en espacio y velocidad) hace el código bien separado (código que se divide en cientos de archivos, clases y patrones de diseño, etc.) realmente introduce en comparación con tener "un gran método que contiene todo en un archivo monolítico ", debido a esta sobrecarga?
ACTUALIZACIÓN para mayor claridad:
Supongo que tomar el mismo código y dividirlo, refactorizarlo, desacoplarlo en más y más funciones, objetos, métodos y clases dará como resultado que más y más parámetros pasen entre piezas de código más pequeñas. Porque seguro, el código de refactorización debe mantener el hilo en funcionamiento, y eso requiere pasar parámetros. Más métodos o más clases o más patrones de diseño de Métodos de Fábrica dan como resultado una mayor sobrecarga de pasar varios bits de información más de lo que es el caso en una sola clase o método monolítico.
Se dijo en alguna parte (cita TBD) que hasta el 70% de todo el código está compuesto por la instrucción MOV de ASM, que carga los registros de la CPU con las variables adecuadas, no el cálculo real que se realiza. En mi caso, carga el tiempo de la CPU con instrucciones PUSH / POP para proporcionar la vinculación y el paso de parámetros entre varias piezas de código. Cuanto más pequeño sea su código, más se requiere un "enlace" superior. Me preocupa que este vínculo se sume a la hinchazón y la desaceleración del software y me pregunto si debería preocuparme por esto y cuánto, si es que lo hay, porque las generaciones actuales y futuras de programadores que están construyendo software para el próximo siglo , tendrá que vivir y consumir software creado utilizando estas prácticas.
ACTUALIZACIÓN: Múltiples archivos
Estoy escribiendo un código nuevo ahora que está reemplazando lentamente el código viejo. En particular, he notado que una de las clases antiguas era un archivo de ~ 3000 líneas (como se mencionó anteriormente). Ahora se está convirtiendo en un conjunto de 15-20 archivos ubicados en varios directorios, incluidos los archivos de prueba y sin incluir el marco PHP que estoy usando para unir algunas cosas. También vienen más archivos. Cuando se trata de E / S de disco, cargar varios archivos es más lento que cargar un archivo grande. Por supuesto, no todos los archivos se cargan, se cargan según sea necesario, y existen opciones de almacenamiento en caché de disco y memoria caché, y aún así creo que loading multiple files
requiere más procesamiento que loading a single file
en la memoria. Estoy agregando eso a mi preocupación.
ACTUALIZACIÓN: la dependencia inyecta todo
Volviendo a esto después de un tiempo ... Creo que mi pregunta fue mal entendida. O tal vez elegí entender mal algunas respuestas. No estoy hablando de micro-optimización, ya que algunas respuestas han señalado (al menos creo que llamar a lo que estoy hablando de micro-optimización es un nombre inapropiado) sino sobre el movimiento del "Código de refactorización para aflojar el acoplamiento apretado", en general. , en todos los niveles del código. Vengo de Zend Con hace poco, donde este estilo de código ha sido uno de los puntos centrales y centrales de la convención. Desacoplar la lógica de la vista, la vista del modelo, el modelo de la base de datos y, si puede, desacoplar los datos de la base de datos. Dependencia: inyecte todo, lo que a veces significa simplemente agregar código de cableado (funciones, clases, repetitivo) que no hace nada, pero sirve como punto de costura / enganche, duplicando fácilmente el tamaño del código en la mayoría de los casos.
ACTUALIZACIÓN 2: ¿"separar el código en más archivos" afecta significativamente el rendimiento (en todos los niveles de computación)
¿Cómo afecta la filosofía de compartmentalize your code into multiple files
la informática actual (rendimiento, utilización de disco, gestión de memoria, tareas de procesamiento de CPU)?
estoy hablando de
Antes de...
En un pasado hipotético pero bastante real, no muy lejano, podría escribir fácilmente un monobloque de un archivo que tenga espagueti de modelo y vista y controlador o no codificado con espagueti, pero que ejecute todo una vez que ya esté cargado. Al hacer algunos puntos de referencia en el pasado usando el código C, descubrí que es MUCHO más rápido cargar un solo archivo de 900Mb en la memoria y procesarlo en grandes trozos que cargar un montón de archivos más pequeños y procesarlos en una comida de paz más pequeña trozos haciendo el mismo trabajo al final.
.. Y ahora*
Hoy me encuentro mirando el código que muestra un libro mayor, que tiene características como ... si un artículo es un "pedido", muestra el bloque HTML de pedido. Si se puede copiar una línea de pedido, imprima un bloque HTML que muestre un ícono y parámetros HTML detrás que le permitan realizar la copia. Si el elemento se puede mover hacia arriba o hacia abajo, muestre las flechas HTML apropiadas. Etc. Puedo, a través de Zend Framework crearpartial()
llamadas, que esencialmente significa "llamar a una función que toma sus parámetros y los inserta en un archivo HTML separado que también llama". Dependiendo de cuán detallado quiera obtener, puedo crear funciones HTML separadas para las partes más pequeñas del libro mayor. Uno para flecha arriba, flecha abajo, uno para "¿puedo copiar este elemento", etc. Crear fácilmente varios archivos solo para mostrar una pequeña parte de la página web. Tomando mi código y el código Zend Framework detrás de escena, el sistema / pila probablemente llama cerca de 20-30 archivos diferentes.
¿Qué?
Estoy interesado en aspectos, el desgaste de la máquina que se crea compartimentando el código en muchos archivos separados más pequeños.
Por ejemplo, cargar más archivos significa tenerlos ubicados en varios lugares del sistema de archivos y en varios lugares de HDD físico, lo que significa más tiempo de búsqueda y lectura de HDD.
Para la CPU, probablemente significa más cambio de contexto y carga de varios registros.
En este subbloque (actualización n. ° 2), estoy interesado más estrictamente en cómo el uso de múltiples archivos para realizar las mismas tareas que podrían realizarse en un solo archivo, afecta el rendimiento del sistema.
Usando Zend Form API vs HTML simple
Utilicé Zend Form API con las últimas y mejores prácticas modernas de OO, para construir un formulario HTML con validación, transformándolo POST
en objetos de dominio.
Me tomó 35 archivos para hacerlo.
35 files =
= 10 fieldsets x {programmatic fieldset + fieldset manager + view template}
+ a few supporting files
Todo lo cual podría ser reemplazado por unos pocos archivos HTML + PHP + JS + CSS simples, quizás un total de 4 archivos livianos.
¿Es mejor? ¿Vale la pena? ... Imagine cargar 35 archivos + numerosos archivos de la biblioteca Zend Zramework que los hacen funcionar, frente a 4 archivos simples.