Desde hace un tiempo vengo reflexionando acerca de si la metodologia de desarrollo que estuve utilizando hasta ahora daba los resultados que deseaba (lograr que framework que "asuste" en el corto plazo con sus resultados, pero tambien que tenga velocidad y aceleracion de desarrollo ), y llegue a la conclusion de que me estuve equivocando al aplicar el desarrollo en capas de abajo para arriba (todo el cuento de
dividir el desarrollo en fases por capa ).
El problema
El problema fundamental de esta metodologia es que "no va a ningun lado", o para decirlo mejor, no tiene objetivos planteados a corto plazo, solo es una especie de
Big Ball of Mud bizarra que tiene una calidad de diseño interno muy alta, pero que solo se justifica en si misma y no hace nada especifico (la Big Ball of Mud clasica es al revez, calidad interna muy baja, objetivos rapidos).
Lo que ocurre a raiz de esto, es que se pierden totalmente las esperanzas de terminacion del desarollo, ya que los objetivos "reales" que se plantea el proyecto nunca estan en contacto con el desarrollo primario que es el de la "capa 0", ya que no hay manera de desarrollar en torno al nivel de abstraccion que separa la capa 0 del resultado final que esperamos; porque la metodologia misma plantea que la capa 0 tiene que estar "completa" antes de empezar a programar las demas, piensen en la vaguedad del termino "completa" en este contexto.
Obviamente, el problema principal que hay que atacar, es el hecho de poder trabajar solo en el nivel mas bajo de abstraccion, y no poder definir ningun parametro ni nada que guie el desarrollo. Podria pensarse que el diseño en capas es un obstaculo, pero el diseño en capas es generalmente mucho mas conveniente que lo que podria parecer, ya que permite separar muy bien en distintos niveles de abstraccion los componentes, y a su vez tener todo muy ordenado.
Solucion
Lo que hay que cambiar es el metodo de desarrollo, para poder lograr los objetivos y que el desarrollo de las capas de bajo nivel esten regidas por algo tangible, evalue en un momento el uso de alguna metodologia "agil", como XP, TDD, Scrum, etc..., pero todas harian destrozos a la calidad interna del framework, ya que esas metodologias funcionan bien para otro tipo de proyectos, proyectos que "finalizan" con un objetivo concreto estatico y muy bien definido.
Lo que se puede rescatar de las metodologias agiles, es el orden del desarrollo, en las metodologias agiles no hay impuesto ningun orden cronologico para desarrollar (sin importar si el diseño sea en capas, o no), ya que el orden estricto trae aparejado los problemas que se describieron recien. Las metodologias agiles no imponen un orden, solo dan una guia de como desarrollar y a veces el "vale todo" para modificar el proyecto en todos lados, con tal de lograr el objetivo (algo asi como "el fin justifica los medios").
En RSIF, se puede desarrollar de esa manera, pero deben aprovecharse todo lo posible las libertades que tienen los desarrolladores, para mantener la calidad de diseño del software, un ejemplo de esto es la ausencia total de deadlines: si no hay deadlines que seguir, no existen "ultimos momentos" donde haya que hacer cosas "feas" en el codigo para cumplir con los plazos, entonces las cosas deberian diseñarse y programarse mejor.
Guias
Se denominaran guias en esta metodologia a todo documento y/o especificacion que justifique cualquier modificacion o agregado al software. Existen dos tipos principales de guias: las consignas, y los objetivos.
Consignas
Tambien cabe destacar, que aunque se anuncie a la comunidad de desarollo como tienen que usar las libertades que otorga el proyecto a favor de la calidad de diseño del RSIF, deben existir claras consignas de calidad documentadas que los desarrolladores pueden seguir para saber si estan haciendo algo "mal" o algo "bien", las consignas son atributos de calidad del codigo y del diseño, como por ejemplo la conveniencia de usar diversos tipos de polimorfismo antes que estructuras de control de flujo condicionales, que son mas dificil de mantener.
Objetivos
Complementariamente a las consignas que se definen del proyecto, existiran "objetivos", que son objetivos muy concretos acerca de funcionalidades que el "producto final" va a tener. El desarrollo para completar los objetivos en la gran mayoria de los casos (sobre todo al principio) necesitara desarrollar en todas las capas, y en este punto se ve la gran diferencia con la metodologia vieja: mientras en la metodologia vieja solo se podia trabajar con una capa hasta que esta se complete, en la nueva metodologia se plantean estos "objetivos" y no hay absolutamente ninguna restriccion acerca de en que capas se puede modificar/agregar funcionalidad. Nuevamente, el, o los desarrolladores que programan para cumplir "objetivos" deben desarrollar en lo posible por favorecer al framework dandole atributos de calidad de diseño que este necesita (diseñar nuevos componentes etc...).
Refactoring
El Refactoring es un proceso fundamental en esta metodologia, la contemplacion del refactoring es lo unico que permite otorgar a los desarrolladores algo de licencia para degradar la calidad del diseño al perseguir un objetivo concreto (algunos desarrolladores podrian degradar la calidad, sin saberlo), gracias a esto los desarrolladores que aporten al framework añadiendo funcionalidad tienen mas libertad de accion y sus aportes deben tener mas aceptacion, aunque no cumplan con las consignas.
El refactoring, en este contexto, se define como una operacion que generalmente modifica mucho codigo fuente y solo se justifica para incrementar la calidad de diseño del framework, incluyendo por ejemplo el ajuste del codigo o el diseño que no respetaban una consigna para que la cumpla, el refactoring tiene que hacerse en un fork del proyecto hasta que este completo y no tiene que afectar la funcionalidad del proyecto, o sea, no tiene que ocasionar que deje de funcionar lo que antes funcionaba.
Sera muy importante reglamentar y documentar los normas y los procesos de refactoring, ya que el refactoring permite dividir las tareas de objetivos y consignas al otorgar a un desarrollador la libertad de quebrar las consignas y a otro la de modificar todo el codigo para agregar el cumplimiento de la consigna que el otro usuario no respeto, de mas esta decir que el desarrollador que implementa la busqueda del objetivo debe respetar en lo posible las consignas de entrada para que no sean necesarios tantos refactoring o refactorings tan complejos.
Documentacion
Todas las guias y el refactoring debe tener documentacion previa, en el caso de las consignas, la documentacion debe especificar como la consigna aporta a la calidad del soft, debe dar ejemplos de como la consigna se cumple, de como no se cumple, y de como se hace refactoring del codigo que no cumple. Los objetivos se documentan explicando cuales son sus alcances y ejemplos de que se espera que el framework haga
