¿Qué es un framework?

Un framework es un conjunto de elementos que juntos nos ayudan a construir software de una manera más sencilla, de mayor calidad, y en menor tiempo. Podríamos decir que un framework se compone de las siguientes características:

Un objetivo limitado y concreto

El framework sirve para resolver una tarea perfectamente definida. Puede ser la distribución de las capas en nuestro sistema, facilitarnos la construcción de una capa en concreto, relacionar entidades de negocio con entidades de base de datos, o ayudarnos con otros aspectos como la inyección de código o semejantes.

Un conjunto de librerías

Un framework agrupa librerías diseñadas para solucionar la tarea para la cual está pensando. Dichas librerías están basadas en patrones de software y son consistente en todo el paquete (todos las objetos son creados y se usan de la misma forma). Además su funcionalidad es completamente extensible para resolver nuevas necesidades (sin modificar las librerías mismas).

Posiblemente un conjunto de herramientas

Aunque este punto podría estar incluido en el anterior, decidí hacer una división mas practicas. Las librería son los elementos que son referenciados desde nuestro código, la herramientas son aquellas que nos ayudan a crear nuestro código. Pueden ser que creen de forma automática todas las entidades de nuestro negocio o las entidades de nuestra base de datos, o las páginas web de nuestra aplicación. Los generadores de código automáticos entran en esta categoría.

Patrones de diseño

Los frameworks esta íntimamente relaciones con los patrones de diseño. Generalmente implementan una colección bastante común y amplia de ellos, y además obligan a que se sigan implementando dichos patrones en los sistemas donde son usando.

Metodología de trabajo

A la vez que el framework ofrece una colección de librerías para resolver un problema, también debe ofrecer una metodología de trabajo que nos indique como hacerlo. Solo hay una forma de hacer las cosas de forma "correcta" y esa es la forma es indicada por el mismo framework.

Si no se cumplen esta serie de características entonces no estaríamos hablando de un framework, sino simplemente de un conjunto de librerías reutilizables agrupadas.

Regla N°11 de la Ingeniería de Software: El primer código es para entender el problema, los restantes para hacerlo bien.

"En primavera de mi último curso en el instituto de Lisbon (o sea, en 1966) recibí un comentario manuscrito que cambió para siempre mi manera de enfocar las revisiones. Debajo de la firma del director, reproducida a máquina, figuraba a mano lo siguiente: «No es malo, pero está hinchado. Revisa la extensión. Fórmula: 2da versión = 1ra versión - 10%. Suerte.»", Mientras escribo, Stephen King, 2000.

Uno de los desafíos a los que nos enfrentamos los que nos dedicamos a crear sistemas software (de forma empresarial) es que debemos construir herramientas sobre ámbitos de negocio que no dominamos. Con lo cual nos enfrentamos a dos circunstancias:

• Comprender los requisitos de un sistema.
• Construir el sistema en sí.

En una metodólogia tradicional, tendremos el rol de analista, diseñador y codificador. El analista obtendrá los requisitos, el diseñador los convertirá en un modelo codificable, y el programador creara el código fuente. La posibilidad de que esos roles sean personas diferentes dependerá mucho de la empresa y de la situación en particular.

Como defensor del las metodologías agiles, creo que la mejor forma de comprender un problema es descomponiéndolo en problemas más sencillos y solucionándolos uno a uno.

Esto implica que hasta que no tengamos algo de código listo, no comprenderemos exactamente la necesidad que estamos intentando suplir. Es más, el ver la necesidad resulta, pueda cambiar los requisitos y la percepción sobre el problema real a tratar.

Los motivos anteriores hacen que el primer código no sea el más optimo, porque su objetivo está más orientado al análisis que a la implementación. La situación en este punto es tenemos un código que nos muestra una solución, pero es una solución temporal y estática (Si hubiera un cambio en los requisitos sería muy difícil de ajustar estar código para atenderlo).

Es por lo cual necesitamos realizar una segunda revisión del código, en estas caso ya no para resolver el problema de negocio, sino para asegurarnos que nuestro código sea de calidad, cumpliendo los siguientes requisitos:

• Que no tenga código repetido.
• Que se entienda claramente.
• Que tenga los comentarios, que seguramente omitiste la primera vez.
• Y el más importante, que se pueda mantener

Como último detalle debemos tener en cuenta que la segunda revisión debiera tener menos código que la primera escritura, pero no debemos confundirnos entre eliminar código innecesario y hacer el código ilegible o ofuscado. No se trata de eliminar líneas o condesar instrucciones en una sola línea, o cualquier tipo de reducción innecesaria que solo llevara a que el código no sea claro, y que no sea mantenible.