Por más increíble que parezca, esto es muy común en el mercado. Pero no pienses que hablo sólo de Java, sería cierto si digo que el 90% de las empresas en que trabaje hasta la fecha, siendo de TI o de negocios (no IT) tienen framework hechos en casa.
En este post vamos a argumentar porque es una mala idea hacer frameworks en casa y como eso puede ser muy perjudicial para su empresa y para su equipo, o algo parecido a esto. Trabajé con frameworks de VB 6.0, ASP 3.0, PHP, Java e incluso JS. Por increíble que parezca, ví una locura como hacer framework JS en una empresa de negocios (no IT).
¿Un framework?
Vamos a algunas definiciones según el sitio thefreedictionary:
- Una estructura para soportar o englobar algo, principalmente un soporte en forma de esqueleto para alguna cosa a ser construída.
- Una plataforma de trabajo.
- Una estructura fundamental para el trabajo.
- Un conjunto de suposiciones, conceptos, valores y prácticas que constituyen una forma de ver la realidad.
Disculpen si la traducción no es perfecta, aunque creo que da la idea general. Así como pueden ver no existe nada mas en un framework.
Se que estabas probablemente esperando un jar, pero como podes ver este concepto salió de la vida real y luego fue a parar en la ingeniería de software. Volviendo a la definición de framework, me encantan las 4 definiciones, para mí es la más apropiada cuando se habla de software. Creo que con eso el lector conseguirá establecer la diferencia de rutina/biblioteca y un framework. Hablando de frameworks Stripes, Rails, Code Igniter, Django, etc son ejemplos de frameworks.
Algunos mitos de frameworks...
Es necesario un súper Arquitecto ...
Este es el primer mito, las personas creen que para hacer un framework necesitan de un super arquitecto que necesita saber todo de todo las API que existan y, luego, este hombre tiene que ganar mucho y las personas deben tener miedo de él y de ser posible, no cuestionarlo como si se tratara de un semi-dios.
Se incrementará la productividad de los desarrolladores ...
Esto es muy difícil, incluso por una simple regla de esfuerzo/retorno 80%/20%, luego se vende la ilusión de que el framework hará el trabajo de los colaboradores más fácil, divertido y al mismo tiempo rentable para la empresa.
Será rápido y fácil de construir ...
Otra leyenda urbana. Nunca es rápido y mucho menos fácil, en la práctica lo que ocurre es que quien hizo el framework hoy en día corre el gran riesgo de
cometer todos los errores que otras personas del mercado ya pasaron. Además de gastar dinero y recursos de la empresa de manera equivocada y sin gran
retorno de la inversión (ROI).
Las soluciones del mercado no cumplen con ...
Los frameworks del mercado no atienden y no pueden ser personalizados o es mucho esfuerzo para utilizar los puntos de extensión de los mismos. Es más
fácil construir uno desde cero porque la implementación en casa será mejor, más rápida y más eficiente que la de Oracle, IBM, MS y otros empresitas.
Todo es importante ...
A veces no vemos frameworks por ahí y sí muros que separan al desarrollador de la realidad y eso es casi como el desierto de Matrix
El framework protegerá al desarrollador de esta crueldad y complejidad sucia y absurda. Y todo esto con media docena de @anotaciones, XMLs de Bind y algunas ejecuciones de REGSVR32.exe myWTFDLL.dll.
El arquitecto estará en la empresa ...
La persona que construyó el framework es extremadamente comunicativa, documentada muy bien lo que hace y da formación y además de eso el código es tan bueno como cualquier simple mortal puede mantener el código. Aunque eso no es necesario, porque el arquitecto progenitor que parió el framework no se irá de la compañía, y mucho menos de sus sucesores.
El framework sirve a todos los problemas pasados, presentes y futuros ...
Esta es la bala:) Pues, una vez hecho megazord el servirá para la resolución de todos los problemas que existen hoy en día, además de los problemas que
ya existían y de los que van a existir y los que son creados por la "solución" también serán resueltos con algunos paths.
Caída en la Realidad ...
El framework que su empresa desarrolló no es eficiente, existen al menos 5 soluciones de mercado que hace la misma cosa mucho mejor y más fácil. La solución "solución" no dió retorno, y gastamos mucho en ella, y tenemos muchos errores y cada vez mas workarounds.
El "Arquitecto", que hizo el megazord se fue de la empresa y los dos sustitutos despues de él se fueron también, nadie más quiere mover esto y la mitad del equipo se fue por desmotivación, 3% se fueron porque descubrieron que no sabían más programar sin el megazord y están atrapados/presos en el desierto de la matrix y el gerente de la empresa no sabe ni la mitad de estos problemas.
Hacer un framework no es un juego, no es fácil, y no es para cualquiera, precisamos de un problema y digo mas, necesitamos tener un escenario en el que no existen soluciones listas para ese problema o que no pueden ser integradas y personalizadas.
¿La misión y los valores de su empresa coinciden con la construcción de este framework? Lo dudo mucho.
Existen frameworks hechos en COBOL hoy en día, que fueron hechos en casa hace unos 20 años y que "funcionan". ¿La cuestión es valió la pena? Lo dudo.
El arquitecto senior no es aquel que cree que puede construir un framework, y si es aquel que no quiere hacer esto porque prefiere utilizar algo listo y quiere resolver los problemas del negocio.
¿Viste esto en tus trabajos? ¿Como te sentiste trabajando con frameworks propietarios? ¿Pensas que creces profesionalmente?
