Published Wednesday, June 3, 2015 - By Super Admin



Es muy frecuente que cuando acudo a hacer una presentación de la plataforma de aplicaciones , el programador, líder técnico o el director de sistemas incluso, tienen una idea preconcebida (equivocada) acerca del tema, algunos piensan que se trata de un generador de código  o una herramienta case, controles, componentes. Hay quienes ya han tenido la mala experiencia de este tipo de herramientas y eso justifica su prejuicio. Otra razón por la que tienen cierto rechazo natural es porque al final de cuentas estas tecnologías vienen a reemplazar buena parte del trabajo… de horas hombre.


Es así entonces que los programadores, responsables de desarrollo (y hasta directores en ocasiones) dicen: No, no quiero nada que tenga que ver con generadores de código. Y yo estaría de acuerdo con ellos, si no fuera porque la realidad en la que viven es otra:


Todos los directores de áreas de programación hacen uso de generadores de código, solo que éstos generadores, suelen cometer errores, tener diferentes estados de ánimo, no hacen las cosas de manera homogénea y aplicando los mismos patrones… son personas. Los programadores somos generadores de código. Y somos los peores generadores de código. Nuestro esfuerzo debería estar enfocado en tareas de solución del problema técnico. no en la codificación repetitiva y artesanal que solemos hacer, me atrevo a decir que esto pasa en más del 90% de los casos.


Bien, pero cuando hablamos de los otros generadores de código NO HUMANOS, uno de los principales problemas a los que nos enfrentamos es que nos ayudan a empezar esa parte de la aplicación para la que estan enfocados, pero una vez comenzada y que avanza el proceso de construcción y cambios, seguirla usando se vuelve muy difícil, porque no permiten integrar el código manual y el que se genera automáticamente de una manera natural.


Entrando en materia, cual es la diferencia entre nuestras herramientas de SFS Tools y el ecosistema de aplicaciones  con respecto a las otras ..


  1. Promueven evitar el software de desarrollo de Microsoft y Terminan inventando sus propios entornos, sus propios lenguajes en el afán de evitar programar, y lo único que consiguen es que ahora debamos aprender los suyos.

  2. Ocultan lo que generan en ensamblados compilados y evitan o vuelven difícil la programación manual que casi siempre es necesaria.

  3. De ésta manera crean una dependencia que causa bastantes limitaciones.

  4. Muchas herramientas promueven prescindir del programador, nos dicen los vendedores que ya no es necesario programar para hacer software, ahora hay que aprender a diseñar complejos diagramas y utilizar una serie de instrucciones para diseñar hasta la regla más simple… lo que termina al final obligandonos a aprender ahora su propia manera de hacer las cosas aún más complejas.

  5. Otras se enfocan en tareas muy aisladas para automatizar solo la creación de entidades basadas en un modelo estructural de la base de datos, o bien para crear los formularios en una versión inicial, y como no mantienen una integración en toda la arquitectura no nos pueden garantizar una integración natural de todas las partes de nuestro proyecto.

  6. No se integran a la programación manual y como les comentaba, se convierte en una tarea difícil mantener lo que se genera manualmente y lo que tenemos que programar nosotros. Esto impide un proceso de construcción iterativo donde poco a poco van liberándose cambios funcionales.



En nuestras herramientas en cambio, las cosas son totalmente distintas. La extensión para Microsoft visual studio (SFS Tools)  se instala precisamente en Visual Studio aumentando la capacidad que de por sí ya tiene la herramienta de desarrollo de Microsoft.  


En el código que se genera y los frameworks que integramos seguimos las mejores prácticas y patrones de Microsoft. No hemos inventado nuestro lenguaje propio ni nada por el estilo. También desechamos esos patrones que en los ejemplos pequeños de Microsoft suelen funcionar muy bien, pero que en escenarios empresariales y robustos se convierten en antipatrones.


El código que se genera es abierto y está completamente  separado del código manual pero se integran en el momento de generar la aplicación. Esto permite un desarrollo totalmente cómodo, transparente y armónico.


Por si esto fuera poco, SFS Tools es completamente extensible en el sentido de que permite al programador agregar nuevas funciones de automatización, de acuerdo a sus necesidades.


Aunado a lo anterior, entre el framework, la extensión de Visual Studio y la plataforma (Ecosistema) suman alrededor de 1000 características específicas que permiten reducir dramáticamente el costo y tiempo de producción.


Espero dejar claro el mensaje: Esta tecnología  No es un generador de código simplemente, no es una herramienta CASE.


Con estas herramientas no promovemos prescindir del programador, dado que realmente se trata de una tecnología de programación, que lo único que hacer es evitar la codificación que no es propiamente del negocio y que cuesta tanto dinero. Para enfocar el esfuerzo del programador en las reglas de negocio que realmente son por lo que paga el cliente.


Por parte del programador hay un rechazo natural de este tipo de estrategias y herramientas de desarrollo, pues hasta más del 80% de su trabajo que no genera valor pero sí cuesta, se verá disminuido o eliminado por completo, pero debo de ser muy claro en esto, ese 80% debe ser enfocado en las reglas de negocio, en crear verdadero valor agregado, en trabajar con menos presión.


Esto significa ser más competitivos, esto aumentar la productividad.

comments powered by Disqus
Culture: en-US UICulture: en-US cookieserver: en-us company: user: