archivo

Archivo de la etiqueta: reutilización

O infierno de los artefactos (en general). Se produce cuando en una organización o en un departamento de desarrollo o TIC no se gestionan de manera adecuada los artefactos de los que hacen uso las aplicaciones (gestionados, generalmente, a través de un repositorio de artefactos), lo que implica que se pueda sustituir un artefacto por otro que se llame de la misma manera y tenga un comportamiento distinto, que hagamos uso de uno que no es el oficial de una solución concreta, etc…

Al final, problemas y más problemas.

Esto, además de provocar problemas de disponibilidad cuando se tiene que generar una nueva versión de una aplicación, dificulta la reutilización de artefactos entre diferentes sistemas.

Nuestro deseo de implementar sistemas que deleguen funcionalidad en terceros ya implementados, que intercambien información con otros o de utilizar librerías y frameworks que ahorren tiempo de desarrollo, es razonable ya que por un lado disminuye el esfuerzo de desarrollo, lo que nos permite centrarnos en los objetivos del proyecto y por otro permite avanzar en la consecución de un ecosistema de aplicaciones interoperable en una organización, rompiendo la filosofía de sistemas estancos que está implantado en muchas.

Ahora bien este objetivo, que es razonable y deseable no puede pelearse con la realidad y con un objetivo todavía de mayor importancia.

No puede pelearse con la realidad en el sentido de que para delegar funcionalidades en terceros componentes y para interoperar de manera sostenible con otros sistemas, es necesario que los mismos sean estables, además de que los cambios que se realicen en los mismos estén controlados. De lo contrario estaremos ante una situación parecida a un sistema de cañerías de los antiguos, donde se pierda agua en las juntas de las tuberías.

En el caso de los sistemas de información, llegaremos a una situación donde estaremos apagando fuegos más de lo deseable, donde éstos aparecerán cuando menos te lo esperas (y por supuesto, cuando sean más inoportunos) y donde es posible que al final, resolviendo estos problemas terminemos gastando más dinero que el que pretendíamos ahorrarnos (sin contar con los costes tangibles e intangibles de un sistema inestable).

Tampoco puede pelearse con un objetivo mayor que es conseguir igualar o sobrepasar las expectativas del cliente y/o el usuario, no puedes poner en juego las mismas, por el deseo de implementar una dinámica entre sistemas cuando todavía no se ha alcanzado en ellos un nivel suficiente de madurez, como para evitar los problemas descritos en los párrafos anteriores.

Partamos de la base que estoy absolutamente a favor de delegar funcionalidad del sistema en componentes ya construidos que estén lo suficientemente probados y rodados, independientemente de que sean propios o de terceros, siempre que de estos últimos exista la posibilidad de tener un soporte y actualizaciones mediante un contrato de servicios y/o licencias claro, en los que se impida la imposición de futuras condiciones abusivas.

De lo contrario estaríamos ante otro antipatrón, que es el de reinventar la rueda o lo que es lo mismo, invertir esfuerzo en resolver un problema que ya está resuelto.

El bloqueo del vendedor se produce cuando se delega funcionalidad de una aplicación en un componente de un tercero tomar las precauciones necesarias que te protejan ante una posible situación de cautividad ante él.

Es posible que el componente no afecte a una parte esencial del sistema y sea fácilmente sustituible por otro, sin embargo, hay veces donde afecta al propio núcleo del sistema y la sustitución puede requerir un importante tiempo y esfuerzo que lo mismo no están disponibles.

Quien esté libre de pecado que tire la primera piedra.

¿Nadie ha copiado y pegado código de Internet en su aplicación y ha hecho adaptaciones del mismo hasta que lo ha hecho funcionar?, ¿lo mismo solo que en lugar de Internet el código procede de otra aplicación de tu organización o en la que has participado previamente?.

Soy de la opinión de que en lo posible hay que intentar entender lo que se está haciendo porque si no es así, no tendremos completa seguridad, salvo que realicemos una buena batería de pruebas, de que realmente el código funciona. Además, si no lo entendemos y toca hacer una mantenimiento evolutivo del mismo, nos encontraremos con la misma situación de partida solo que ahora probablemente no tendremos código que copiar y adaptar.

A veces los plazos se nos echan encima, queremos quitarnos una tarea de cierta complejidad que realmente no tiene mucha importancia dentro del proyecto o hay algo que no nos termina de funcionar. Esto provoca que en ocasiones se busquen soluciones donde sea y se da lugar a esta práctica que todos sabemos que aunque pueda ser efectiva en ocasiones, no es nada positiva en el proceso de desarrollo de software.

Hay quien entiende esto como reutilización de código. Si se quiere reutilizar código, yo entiendo que lo mejor es utilizar la fórmula de las librerías, de las API (cuando se delega funcionalidades en terceros), ya que se tiene más controlado el software que se utiliza. También podría entender esto como reutilización de código si se comprende lo que se está haciendo, es decir, lo que se hace es ahorrar un trabajo que no va a aportar nada, que es pesado, que sabemos como hacerlo y que ya está hecho en otro proyecto.

Sobre copiar y pegar código de otras fuentes (en este caso Internet), el desarrollador Mike Johnson realiza la siguiente reflexión: “Copiar y pegar código de Internet en el código del programa es como masticar chicle que has encontrado en la calle”.

No lo debe ser, por muy mal que estén las cosas. Si no hay dinero para hacer el proyecto, lo mejor es no hacerlo, ya que vas a invertir un dinero que probablemente no llegue a ningún sitio o que después se te multiplique por mucho si realmente quieres que funcione como debe, teniendo en cuenta que en el caso de que se logre (y no siempre se conseguirá) se tendrá un producto parcheado con una deuda técnica más que notable.

El precio hay que tenerlo en cuenta, claro que sí, pero nunca debe ser el factor decisivo para elegir un proveedor salvo que las soluciones propuestas sean muy similares.

Los desarrollos valen lo que valen. Se pueden optimizar por la calidad, cualificación y productividad de tu personal, por la selección de una metodología adecuada, por la eliminación de requisitos innecesarios, por la posibilidad de reutilizar código o poder delegar funcionalidades en terceros componentes ya desarrollados.

Si todo eso viene bien justificado podría parecer razonable una reducción sensible del precio, tampoco es cuestión de castigar a quien hace las cosas bien o tiene la propuesta o solución más adecuada a una propuesta realizada por un cliente.

El problema comienza cuando el precio resta peso a la oferta hasta tal punto de que no sea significativa a la hora de elegir un proveedor, ya que nadie regala nada y si lo que te ofrecen está por debajo de mercado, prepárate para un proyecto con mucho desgaste y ejecución más que dudosa.

Si se tiene una aplicación que permite que los usuarios puedan trabajar de manera adecuada o si se tienen desarrollados sitios web que tienen un grado de aceptación importante, ¿para qué invertir esfuerzos en volver a realizar un sistema que haga más o menos lo mismo?.

Puede estar justificado en las siguientes situaciones:

– Importante deuda técnica de la aplicación que dificulta enormemente las tareas de mantenimiento.

– Se prevén cambios funcionales sensibles y se aprovecha para hacer una renovación tecnológica de la aplicación.

-(No deja de ser un caso particular de la anterior) Necesidad de hacer cambios para mejorar la eficiencia y productividad de los usuarios de la aplicación o para aumentar (o al menos mantener) la atención en un sitio web.

En estos dos últimos casos no estaríamos hablando de realmente de renovación injustificada del sistema, hay motivos que pueden hacer necesario desarrollar una nueva versión de la aplicación, codificándola desde cero.

Puede parecer lógico no sustituir una solución que funciona sin motivos de cierto peso, pero seguro que si nos ponemos a pensar conocemos más de un caso y más de dos.

Sobre esto, existe una cita de Richard Hill que se ajusta a lo que he comentado “No escribas un nuevo programa si ya tienes uno que más o menos hace lo que tu quieres. Y si debes escribir un programa, reutiliza código tanto como te sea posible”.

Si la mayoría de los sistemas de información de una organización no reutilizan código generado en el desarrollo de los mismos o en otros, nos encontramos con que estaremos reinventando la rueda una y otra vez.

La teoría dice eso, pero la realidad pone bastante difícil el proceso de reutilización, sobre todo en entornos con muchos proveedores, con un portfolio de aplicaciones alto y con diferentes estados en su ciclo de vida.

Hay que tener en cuenta que decir que no se reutiliza, no es cierto, ya que la mayoría de los desarrollos utilizan librerías de repositorios estándar, como por ejemplo las que componen determinados frameworks. Además, los proveedores también reutilizan determinadas librerías propias.

Si además se utilizan generadores de código, hay que sumar a las librerías todo el software que se ha escrito automáticamente, que si bien no es código reutilizado es fruto de un componente que se reutiliza una y otra vez (y que también va evolucionando, mejorando y adaptándose a los cambios en la tecnología y en los frameworks).

La reutilización se puede hacer principalmente a dos niveles, uno a nivel de librerías, es decir, que se puedan reutilizar desarrollos de otros proveedores, lo que requiere tener las mismas bien catalogadas y otro a nivel de delegación de funcionalidades en componentes de más alto nivel.

Este segundo nivel de reutilización, se basa en el uso de un componente que realiza una funcionalidad concreta a través de la comunicación con el mismo a través de un API. Estos componentes realizan una funcionalidad de cierta complejidad y nuestro sistema lo utilizará para que realice una determinada competencia, como por ejemplo, la gestión de usuarios, la autenticación, la gestión de documentos a firmar electrónicamente, la generación de documentos, la gestión de su almacenamiento, etc…

Además de las ventajas que supone reutilizar el componente en el desarrollo, tenemos las propias de no tener código duplicado (o funcionalidades duplicadas), es decir, el mantenimiento y testing de esos componentes está centralizado en una sola instancia, lo que además de ahorrar esfuerzo permite incrementar la estabilidad de nuestros sistemas.