Analicemos los elementos necesarios que necesitamos para crear nuestra línea de
producción de software , basado en un esquema de “Fabrica de software”, que se puede
implementar dentro de nuestra empresa, ya sea que esta tenga un departamento de
desarrollo de sistemas o que el giro de la empresa sea el desarrollo de sistemas
en sí.
Estándares de programación: Es una colección de reglas de programación que
define como debe crearse el software de nuestra empresa , es importante que todos
los programadores los conozcan y respecten. De esta forma cualquier codificador
del equipo podría asumir cualquier tarea de programación o mantenimiento con una
curva mínima de aprendizaje. Deben de existir herramientas que validen de forma
automática que los estándares se cumplan.
Metodologías adecuadas: Debemos trabajar de la forma correcta y que dicha
forma sea conocida y cumplida por todos los integrantes del equipo. Debido a las
características de nuestra línea de producción, en que muchos elementos serán generados
automáticamente, puede utilizarse un enfoque ágil (como XP, o Scrum), en
el que se presenten cada poco tiempo un prototipo que a la vez sirva para definir
y acércanos más a la necesidad final del cliente (En las metodologías agiles se
asume que el software va a cambiar y eso se valora como algo positivo).
Patrones de software : Es necesario que el equipo de desarrollo conozca
los patrones de software y los sepa aplicar de forma adecuada, igualmente nuestro
generador puede implementar automáticamente los patrones de software, para garantizar
que se usen correctamente.
Consumo de framework de terceros: Es necesario identificar los componentes
existentes en el mercado que nos pueden ayudar en nuestro desarrollo . Muchos de
estos componentes resuelven problemas que a nosotros nos pueden resultar complejos
o los más probable que estén fuera del ámbito del problema de negocio que queremos
resolver (por ejemplo cuando creamos un portal web , no queremos crear un Framework
MVC, por que ese no es nuestro objetivo real, por eso usamos alguno previamente
existe como ASP.NET MVC o Apache Struts). Es importante encapsular los framework
elegidos apropiadamente para no generar dependencias externas excesivas, para ello,
nos será muy útil nuestro generador de código que puede crear las interfaces adecuadas
hacia dichos frameworks (y cambiarlas si es necesario).
Desarrollo de framework empresariales propios: Se encapsularan los componentes
y funcionalidades comunes que se hayan sido desarrollados dentro la empresa . Cualquier
funcionalidad que pueda ser global, se convierte en una herramienta que podrá ser
usada en cualquier futuro desarrollo . Nuestro generador puede administrar dichos
componentes.
Control de versiones: En toda fábrica es necesario tener controlado el software
generado, permitir "viajar" sobre distintas revisiones y sobre distintas
ramas de un mismo producto , para ello podemos usar herramientas como SVN
o GIT.
Generador de código: Es el encargado de generar la gran parte de nuestro
sistema . Todo característica repetible, que se propague en dirección vertical u
horizontal en nuestra aplicación, se convertirá en una parte de este generador ,
una característica a incluir en un catálogo común.
Un característica común repetible, no es un fragmento de código, ni una librería
que se usa en varios lugares, sino una parte del desarrollo , que puede ser reusada
en otros desarrollos, esto incluye la parte del análisis y del diseño, no solo del
código. El código se generara automáticamente adaptándose a la circunstancia indicada
para el sistema que se quiera hacer.
Por ejemplo si empresarialmente definimos que nuestros sistemas deben tener cierta
arquitectura, existirá una característica (o conjunto de ella), que se encarga de
generar el código que respecte dicha característica. El código por sistema será
diferente pero se habrá generado automáticamente, en base a un análisis y diseño
que se realizaron previamente. El código de la misma forma, podrá cambiar de arquitectura,
si cambiamos la característica generadora, o podrá crearse simultáneamente para
varias arquitectura, por ejemplo podríamos desear que se genere nuestro software
para escritorio y para teléfono móvil (Android o iOS ). De esta manera para una
misma lógica de negocio , se crearan diferentes arquitecturas de forma automática.
Hay que considerar que para resolver el desarrollo de un sistema no se puede usar
cada uno de los elementos previamente mencionados como única solución (de hacerlo
caeremos en el problema del martillo de oro ). Es necesario combinar adecuadamente
todos los elementos, para conseguir un software estable y con escalable a futuro:
Los estándares y las metodologías por sí solo, nos dan las reglas y las buenas prácticas
sobre cómo crear nuestro software , por otro lado los patrones de software deben
usarse de la forma y en los lugares correctos.
El abuso de los frameworks externos nos genera una dependencia, tanto al nivel de
arquitectura, como técnicamente. Cuando estamos muy atados a un framework, y este
no resuelve un problema en concreto, la solución puede volverse tremendamente complicada
y enrevesada, entorpeciendo el mantenimiento del producto .
Intentar resolver todos los problemas con framework propios tampoco es una solución
idónea, puesto que caeremos en dos escenarios posibles para abarcar todas las circunstancias
propias de nuestro negocio , o crearemos un framework muy abstracto, que no resuelva
nada, o creamos un framework muy concreto, amplio y difícil de manejar y mantener.
Si solo usáramos nuestro generador de código de forma exclusiva, este crearía muchos
elementos repetidos, y código innecesariamente largo, haciéndolo difícil de comprender
su funcionamiento, y por lo tanto condenado a ir perdiendo su utilidad con el tiempo
(por posibles mantenimiento y diagnósticos).
Por todo eso debemos combinar en nuestra línea de producción de software todos los
elementos según las necesidades particulares de los sistemas a desarrollar, eso
hará que sean sistemas con alta calidad , funcionales y escalables.
El manifiesto ágil indica que se debe valorar más la colaboración con el cliente
sobre negociación contractual y respuesta ante el cambio sobre seguir un plan.
La expresión "Martillo de oro", hace referencia el refrán "Al que
tiene un martillo, todo le parece un clavo". Se quiere evidenciar que es fácil
creer que nuestra herramienta o tecnología, por buena que sea, puede resolver cualquier
problema, aunque no sea apropiada para la tarea.
