bitácora de uno

Con esta entrada vamos a comenzar a meternos en harina en lo que a desarrollo de software se refiere y a las últimas tendencias en ingeniería de software.

Desarrollar software de verdad debe cumplir con unos requisitos ideales. Supongamos que no queremos desarrollar mierdas.
1.- Queremos que funcione bien y de acuerdo lo que nos han pedido - o hemos pensado - que haga. Cumple.
2.- Lo que haga que lo haga rápido. Eficaz.
3.- Me gustaría poder ponerle y quitarle funcionalidad sin que sea el infierno. Va a ser modular.
4.- Paso de casarme con una plataforma, forma de comunicarme o con un sistema operativo (aunque sea GNU), quiero que la gente se lo instale en lo que tenga SIN problemas. Multiplataforma.
5.- Si cumpliendo lo demás puedo hacerlo genérico y que me sirva a mi o a otras personas en otros proyectos: Fetén. Reusable.

Desarrollar software que cumpla con esta lista es difícil. Cuando te has pegado con varios sistemas, has visto cómo desarrollaban otros, has pensado mejoras o las has visto luego de haber implementado algo, y en definitiva cuando has estado varios años en un caldo de cultivo provechoso en este sentido, te conviertes en alguien que atisba más fácil y rápido arquitecturas adecuadas según ves un problema. Te suena el problema y te suena la solución que mejor encaja.

Encontrar este tipo de persona es difícil. Es importante contar con gente así si tu proyecto es medianamente complicado y quieres hacerlo bien.
Además si es difícil hacer las cosas bien desde el punto de vista técnico todo el panorama se suele ver aun más oscurecido por problemas de trabajo en equipo, organizativos, administrativos, económicos, políticos, sociológicos y psicológicos.

La cosa está jodida pero tenemos algún arma. La primera es la ilusión: mola desarrollar cosas complicadas y que salgan bien ¿o no?. El resto de armas tienen mucho que ver con la ingeniería del software y toda la literatura al respecto generada por un montón de gente dándole a las neuronas.

La idea básica que subyace en todo avance en el desarrollo de software (y en otros campos) es que “a ver si currando menos hacemos más y mejor“. Muy loable; puede ser mejor ser inteligente que muy trabajador. Si el trabajo es tedioso mejor automatizarlo y dedicarnos a otros menesteres.

Esto de trabajar menos programando tiene nombre en ingeniería del software: Reusabilidad. Siempre he dicho que si pillan a un alumno copiando en un exámen de programación sólo debería ser suspendido si ha copiado de una fuente mala. “Oiga usted, que estoy aplicando el concepto de reusabilidad“. Bien.

Copiar código, estructuras o ideas de otros en el desarrollo de un software tiene ventajas, algunas fenomenales:
- Me equivoco menos. Cojo algo que ya funciona, ya lo han probado otros y me quito trabajo de teclear, detectar errores de compilación, errores en producción.
- Voy más rápido. Mejora la productividad.
- Me aburro menos. Desarrollo lo que es específico o nuevo para mi aplicación, no tengo que estar haciendo por enésima vez la librería para generar trazas en fichero.

Hay dos formas de Reusabilidad:

Reusabilidad Oportunista:
En general se da porque un programador copia código y lo pega en el suyo. Está bien pero tiene problemas a la larga: genero líneas diferentes para lo mismo y si algo está mal en el origen hay que buscar todos los sitios en donde se ha pegado para corregirlo.

Reusabilidad Sistemática:
Esta es la buena. Aquí copiamos a posta y con un plan calculado. Quiero tirar poco código, equivocarme menos, poner y quitar funcionalidad de forma fácil. Quiero aprovecharme de los conocimientos y trucos de otros que han estado antes “por aquí”.

Nos interesa la Reusabilidad Sistemática y al vasto campo de la ingeniería del software también.

Conceptos como la Programación Orientada a Objeto, los Patrones de Diseño, Frameworks, y Middlewares, las Arquitecturas Orientadas a Componentes, a Modelos o a Aspectos, son todos maquiavélicos planes para perder menos tiempo, para copiar, para trabajar menos.
Los iremos viendo.