Articles

Marco de software

Esta sección tiene múltiples problemas. Por favor, ayuda a mejorarla o discute estos problemas en la página de discusión. (Aprende cómo y cuándo eliminar estos mensajes de la plantilla)

Esta sección necesita citas adicionales para su verificación. Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables. El material sin fuente puede ser cuestionado y eliminado.
Encontrar fuentes: «Software framework» – noticias – periódicos – libros – scholar – JSTOR (Abril 2011) (Aprende cómo y cuándo eliminar este mensaje de la plantilla)

Esta sección puede ser demasiado larga y excesivamente detallada. Por favor, considere resumir el material mientras cita las fuentes según sea necesario. (Abril de 2020)

Esta sección contiene palabras de comadreo: frases vagas que suelen acompañar a información sesgada o no verificable. Tales afirmaciones deben ser aclaradas o eliminadas. (Abril 2020)

Esta sección está escrita como una reflexión personal, un ensayo personal o un ensayo argumentativo que expone los sentimientos personales de un editor de Wikipedia o presenta un argumento original sobre un tema. Por favor, ayuda a mejorarla reescribiendo en estilo enciclopédico. (Abril de 2020) (Aprende cómo y cuándo eliminar este mensaje de la plantilla)

(Aprende cómo y cuándo eliminar este mensaje de la plantilla)

Los diseñadores de marcos de trabajo de software tienen como objetivo facilitar los desarrollos de software permitiendo a los diseñadores y programadores dedicar su tiempo a satisfacer los requisitos del software en lugar de ocuparse de los detalles de bajo nivel más estándar para proporcionar un sistema de trabajo, reduciendo así el tiempo de desarrollo general. Por ejemplo, un equipo que utilice un marco web para desarrollar un sitio web bancario puede centrarse en escribir el código particular de la banca en lugar de la mecánica de la gestión de solicitudes y estados.

Los marcos suelen aumentar el tamaño de los programas, un fenómeno denominado «hinchazón de código». Debido a las necesidades de las aplicaciones en función de la demanda de los clientes, a veces acaban apareciendo en un producto marcos que compiten y se complementan. Además, debido a la complejidad de sus API, puede que no se consiga la reducción prevista del tiempo total de desarrollo debido a la necesidad de dedicar tiempo adicional a aprender a utilizar el marco; esta crítica es claramente válida cuando el personal de desarrollo se encuentra por primera vez con un marco especial o nuevo. Si dicho marco no se utiliza en tareas posteriores, el tiempo invertido en el aprendizaje del marco puede costar más que el código escrito a propósito y familiarizado con el personal del proyecto; muchos programadores guardan copias de boilerplate útiles para necesidades comunes.

Sin embargo, una vez que se aprende un marco, los proyectos futuros pueden ser más rápidos y fáciles de completar; el concepto de un marco es hacer un conjunto de soluciones de talla única, y con la familiaridad, la producción de código debería aumentar lógicamente. No se hacen tales afirmaciones sobre el tamaño del código que finalmente se incluye en el producto de salida, ni sobre su relativa eficiencia y concisión. El uso de cualquier solución de librería necesariamente arrastra extras y activos extraños no utilizados, a menos que el software sea un compilador-enlazador de objetos que haga un módulo ejecutable ajustado (pequeño, totalmente controlado y especificado).

La cuestión continúa, pero una década o más de experiencia en la industria ha demostrado que los marcos más eficaces resultan ser los que evolucionan a partir de la refactorización del código común de la empresa, en lugar de utilizar un marco genérico «de talla única» desarrollado por terceros para fines generales. Un ejemplo de ello sería cómo la interfaz de usuario en un paquete de aplicaciones como una suite ofimática crece para tener un aspecto, una sensación y unos atributos y métodos de intercambio de datos comunes, a medida que las aplicaciones antes dispares agrupadas, crecen unificadas en una suite que es más ajustada y más pequeña; la suite más nueva/evolucionada puede ser un producto que comparta bibliotecas de utilidades integrales e interfaces de usuario.

Esta tendencia en la controversia trae a colación una cuestión importante sobre los frameworks. Crear un marco de trabajo que sea elegante, frente a uno que simplemente resuelva un problema, sigue siendo más bien un oficio que una ciencia. La «elegancia del software» implica claridad, concisión y poco desperdicio (funcionalidad extra o ajena, mucha de la cual es definida por el usuario). En el caso de los marcos de trabajo que generan código, por ejemplo, la «elegancia» implicaría la creación de un código limpio y comprensible para un programador con conocimientos razonables (y que, por tanto, es fácilmente modificable), frente a uno que se limita a generar código correcto. La cuestión de la elegancia es la razón por la que relativamente pocos marcos de trabajo de software han resistido la prueba del tiempo: los mejores marcos de trabajo han sido capaces de evolucionar con gracia a medida que la tecnología subyacente sobre la que se construyeron avanzaba. Incluso allí, habiendo evolucionado, muchos paquetes de este tipo conservarán capacidades heredadas que hinchan el software final, ya que los métodos que de otro modo se habrían sustituido se han conservado en paralelo con los métodos más nuevos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *