eMartos

En la informática en general, y en el desarrollo de aplicaciones más concretamente, es conocido el lema de no reinventar la rueda para expresar que resulta más práctico usar herramientas existentes que volver a crearlas desde cero. Aunque no en todas las ocasiones resulta rentable o posible, suele funcionar bastante bien; sin embargo, se tiene poco presente en la actualidad.

En el ámbito particular, el lema es justamente el contrario, pues se persigue un aprendizaje o, simplemente, pasar el rato (sé que habrá quien no conciba que esto último es posible). Incluso en el ámbito profesional, a veces, hay que pararse a desarrollar determinadas herramientas porque puede que las existentes no se ajusten por completo a nuestras exigencias, o no dispongamos de suficiente presupuesto, o sean incompatibles con nuestra plataforma... En cambio, habrá un gran número de proyectos esté justificado usar componentes de terceros. En la informática de gestión podemos estar seguros de que cubriremos un considerable porcentaje del desarrollo con esta filosofía.

Estoy hablando de componentes de acceso a datos o de interacción con protocolos de red, de módulos para explorar estructuras de ficheros... Es decir, todo aquello que no trata de nuestro proyecto, sino de tareas de propósito general. Afortunadamente, los entornos de desarrollo vienen cada vez más completos e incorporan gran parte de la funcionalidad descrita. En cualquier caso, venga de serie o no, lo interesante es emplear el tiempo asignado para el proyecto (ya de por sí  escaso) en su diseño y desarrollo, no en los de las herramientas.

El motivo es muy sencillo: no sólo invertimos el tiempo eficazmente, además tenemos la tranquilidad de que el componente funciona, ya que es un producto terminado que ha pasado por fases de depuración y validación. De todas formas, en caso de fallo siempre podemos recurrir a los parches y actualizaciones.

Aquí entra la segunda parte de la cuestión: no nos servirá cualquier componente. Debemos elegir aquellos que tienen detrás un equipo activo de desarrollo, ya que, de lo contrario, podríamos encontrarnos ante un producto descontinuado. También conviene, siempre que se pueda, elegir productos de software libre. Y no lo digo porque puedan ser gratuitos (ya que algunos se comercializan), sino porque, si en alguna ocasión necesitamos introducir cambios en el código, nada nos lo impedirá. Se puede argumentar que, aun siendo software propietario, se le pueden comunicar los errores a su autor; pero el esfuerzo es mucho mayor, la versatilidad menor y tampoco es seguro que nos vaya a solucionar el problema. Lo digo por experiencia. Durante dos años he trabajado con TeamWare Flow, un componente cerrado sobre el cual se cimentaba todo un sistema de tramitación de expedientes. En un momento determinado, el producto dejó de estar soportado por su fabricante. Con la evolución del sistema, el componente acabó quedando obsoleto. ¿Qué tuvimos que hacer entonces? La única solución era desarrollar un sustituto; es decir, perder tiempo no previsto en desarrollar un componente para reemplazar otro que resultó no ser la mejor elección.

En conclusión, es muy recomendable usar componentes de terceros, pero con las debidas precauciones y con visión de futuro. El resultado es gratificante tanto desde el punto de vista profesional como desde el empresarial. El objetivo, al fin y al cabo, es reducir tiempos y costes.