Desarrollando aplicaciones en el 2015.
Me gusta cada tanto pensar como pueden ser las metodologías de desarrollo en los años venideros. El articulo “Some reflections on a future of software engineering” (via @gmilano) me hizo recordar un post que tenía a medio escribir desde hace bastante tiempo y decidí que era momento de terminarlo. No estoy en todo de acuerdo con lo que dice dicho artículo, pero coincido en algunas partes muy importantes.
Para mi, las herramientas de desarrollo del futuro cercando deberían poseer las siguientes características:
Desarrollo basado en Conocimiento.
Creo que GeneXus ha dado en el clavo con este concepto y creo que las herramientas del futuro deberían basarse en dicho paradigma para poder mantenerse tecnológicamente actualizadas. Deberíamos tener aun mas conocimiento almacenado en dichos repositorios.
Basado en la nube.
Los repositorios de conocimiento (podrían llamarse KR=Knowledge Repositories, para diferenciarlos de las KB GeneXus), deberían estar accesibles desde a través de protocolos estándares desde cualquier maquina conectada a internet (con la autenticación/autorizaciones necesarias). El contar con dicho repositorio alcanzable en la nube posibilitara que grupos de trabajo puedan trabajar desarrollando una misma aplicación de forma mucho mas natural.Lo que se tendría ahí, no es una copia compartida como hoy se trabaja con GXServer, sino seria la versión oficial sobre la cual se podría desarrollar.
Basado en Modelos.
El desarrollo basado en modelos y las pruebas basados en modelos muestran que son buenas herramientas para el desarrollo. Creo que esto debería poder ser ampliado y aplicarlo también a la etapa de instalación de las aplicaciones posibilitando la aparición de herramientas que trabajen con modelos donde las personas declaren de que forma se va a instalar la aplicación, controlando las inconsistencias que puedan aparecer en la etapa y disminuyendo los riesgos y errores que se realizan en esta etapa.Posiblemente como desarrollador, me toque tomar alguna decisión de instalación básica y luego se lo pasaría a otra empresa que se especialice en el deployment de dicha aplicación en la nube, donde ejecutarán la mayoría de las aplicaciones del futuro.
En el área de desarrollo, tendríamos un uso muy fuerte de patrones y generación de código.
Mas Conocimiento
Dentro del KR se van a tener mas cosas como por ejemplo:
Pruebas Unitarias. Como quiero que se comporten los componentes internos de mi aplicación. En estos componentes tendríamos los resultados esperados por diferentes componentes de mi aplicación para una entrada determinada. También podrían representarse requerimientos adicionales como por ejemplo que la emisión de una factura no puede demorar mas de 1 segundo.
Pruebas Funcionales: Como quiero que mi aplicación se comporte funcionalmente. Por ejemplo, creo que los Casos de Prueba que hoy se generan en GXTest deberían almacenarse en dicho repositorio o KB ampliada.
Requerimientos Adicionales: Estaría bueno que dentro de un KR,se pudieran documentar mejor que hoy todo lo que es la captura de requerimientos. Se podrían grabar las charlas con los usuarios en videos, imágenes, audio y texto. Si al desarrollador le surge alguna duda, podría recurrir a esas fuentes para aclarar dichas dudas. Esto puede hacerse hoy con el Wiki dentro de la KB, pero se necesitaría alguna herramienta adicional que ayude en el proceso.
Instalaciones. Dentro del repositorio debería contar con modelos que cuenten donde esta instalado cada una de mis aplicaciones (maquina, sistema operativo, servidores, etc.) controlando versiones y posibles inconsistencias.
Errores o incidentes del Software: Esta bueno que los problemas que aparecen en los diferentes módulos se puedan almacenar en el repositorio de conocimiento. Esto implicaría también tener modelado a los clientes de la aplicación para poder avisarles cuando se corrigen. También es bueno poder convertir estos errores en casos de prueba, de forma de asegurarnos que el error no se vuelva a repetir.
Manejado por varias herramientas. Manejando el ciclo de vida completo de la aplicacion.
El ciclo de vida de la aplicación podría ser manejado por varias herramientas y dichas herramientas deberían estar desarrolladas por diferentes empresas que tengan especialización en cada una de las areas de conocimiento. Si en el Diseño y Desarrollo contamos con GeneXus, en la etapa de pruebas podemos contar con GXTest. En la personalización y capacitación, se podría contar con herramientas para la edición de temas, un,editor de ciclo de workflow de mi aplicación y también programas propios de configuración de mi aplicación, que como a través de tutoriales me enseñen a personalizar a las aplicaciones a mi gusto.
En la etapa de operación, la aplicación debería brindar a los usuarios la posibilidad de reportar errores de funcionamiento y que los mismos queden asociados a los programas que los produjeron, ahorrándole trabajo a la persona responsable de corregir dicho error. También estaría bueno que la aplicación sea capaz de reportar cuales fueron los ultimas tareas realizadas de forma que sea fácil reproducir el error.
Monitoreo y optimización. En esta etapa se podrán definir indicadores de funcionamiento (la tarea tal no puede demorar mas de X) o mas funcionales (se debe realizar al menos 10 operaciones por día). Si alguno de estos indicadores no se cumple, se avisa a quien corresponda. El sistema de monitoreo debería poder evaluar si algo esta emporando en forma sistemática, para sugerir alguna mejora.
Para posibilitar el tener diversas herramientas trabajando en conjunto, es indispensable al definición de interfaces claras y publicas, para interactuar con el repositorio de conocimiento.
Modulos.
El post ya esta quedando demasiado largo, pero para el manejo de grandes proyectos, se hacen indispensables el manejo de Módulos de forma de poder dividir el problema en algo mas manejable.Codigo consultable
El repositorio estaria bueno que estuviera almacenado en un formato mas fácil de consultar que el que hoy manejamos.Integracion e Instalacion Continua
Cuando modificamos algo en el respositorio, se disparan inmediatamente lo necesario como para regenerar todo lo necesario y volver a correr todos las pruebas unitarias necesarias en forma casi instantanea. El cambio no seria aceptado, hasta que las pruebas unitarias se superasen. Cuando estas pruebas unitarias son satisfactorias, se pasa a una segunda etapa de deployment y ejecucion de pruebas funcionales que van a demorar bastante mas. Si alguna de estas pruebas fallan se va a avisar a quien lo desarrollo. Esto se podria hacer en forma desatendida y en la nube.
Post relacionados:
PD: Mi deformación profesional, desarrollando con GeneXus, GXTest y algunas herramientas hace que el análisis este bastante sesgado hacia este tipo de metodología de desarrollo.
Hum... algunas consideraciones.
ResponderBorrarGeneXus dió en el clavo hasta la versión 9 con la Base de Conocimiento. Con GeneXus X ha diluido de forma excesiva dicho concepto centrandolo más en el bit&byte y la gestión del Conocimiento (con C mayuscula) se ha descontrolado un poco.
Lo de KR creo que en el 2015 no existirá todavia, puede que en el 2025.... aunque hay que ver como funciona la nube para muchos otros conceptos antes.
Creo que hay conceptos que no tocas como la virtualización (¿de que?, no se.. de KB?, de objetos?, de usuarios que hacen de usuarios virtuales...).
Daniel:
ResponderBorrarPorque decis que en la version X se descontrolo la gestion de conocimiento?.
Desde mi punto de vista, como repositorio de conocimiento, es mucho mejor la KB de la X que las anteriores. Es mas abierta, soporta nuevos tipos de objetos, es mas extensible, pues puedo crearme mis propios objetos.
Podemos discutir si los programas generados son mejores en la 9 que en la X y tambien si se tiene mayor productividad con la X o con la 9, pero desde el punto de vista de gestion de conocimientos, creo que la X es ampliamente superior.
En una definición estrictamente formal es verdad, el conocimiento es "mejor" en la X, pero hay "peros", ya que conocimiento no es solo la KB (almacenada ahora en un SQL server) o los objetos, sino que es el todo. Tu mismo propones en otras entradas mejoras que por su simplez parece increible que no hayan implementado. A mi me gustaria usar la X si pudiera controlar el conocimiento que me quiere brindar, pero en algunos casos se descontrola (por ejemplo, aún no se, tal vez por ignorancia, que objetos estan pendientes de especificar).
ResponderBorrarPara un desarrollador esta muy bien tener herramientas de control, versiones congeladas, ramas de mi KBASE, nuevos objetos y que yo me pueda definir los mios, pero en el día a día con esa aplicación que no usas esas cosas (y que es la que te da dinero y que tienes que mantener, mejorar) ves que la X ha "olvidado" ciertas cualidades que hacen que dicha KBASE (la que te da de comer) se vuelva en contra tuya.