Categoría: Software Libre

Son cosas que todos sabemos pero que sigo viendo en muchos proyectos, algunos de ellos se han hecho bastante populares.

1. Debe estar documentada. Es de perogrullo pero es una cosa que a ningún desarrollador le gusta hacer pero es lo primero que buscamos cuando estamos programando. Un API sin documentación no sirve de mucho. Ejemplos de bibliotecas que triunfan y tienen una gran documentación y puede que parte de su éxito sea justamente este detalle son PHP, Qt o  Java.
2. Compatibilidad a lo largo del tiempo. Un api de programación tiene que ser estable a lo largo del tiempo, si se empiezan a cambiar las interfaces de los métodos o funciones, se crean incompatibilidades binareas, etc esta biblioteca nos dará muchísimos quebraderos de cabeza. Lo que suelen hacer algunos fabricantes es que durante la versión mayor de una biblioteca se mantiene la compatibilidad y cuando se pasa a la siguiente versión mayor ya si que se puede añadir lo que se quiera porque se permite la incompatibilidad con la versión anterior.
3. Debe facilitar la actualización. Cuando se crea una nueva versión se debería pensar en la forma de actualizar desde la versión anterior de manera que luego no existan problemas en las migraciones.
4. No se pueden dejar funcionalidades a medias. Si empiezas un desarrollo y no lo terminas no puedes dejar la aplicación llena de partes de dicho desarrollo pero que en verdad no sirven de nada.
5. El código fuente debe estar en inglés. Habrá gente que no le guste pero el idioma internacional para la tecnología es el inglés y es el que todos los desarrolladores suelen entender. Si tu código está en otro idioma estás cerrando puertas para que otros desarrolladores entren al proyecto.

Existen muchos más problemas asociados pero estos 5 me parecen fundamentales. En Openbravo me he encontrado estos y nos está afectando actualmente en varios proyectos en los que estoy metido en mi empresa.

Ante el primer problema y preguntando diréctamente cómo funciona tal método de una clase a desarrolladores de Openbravo, gente que lleva trabajando para la empresa Openbravo desde hace bastante tiempo y que están en el equipo de ingeniería la respuesta es – No lo se, yo pillo un ejemplo parecido que ya esté hecho y copio y pego. A la pregunta de si estaba documentado la respuesta era no y que en todo caso se iban a la propia definición en el código de la biblioteca.La culpa no es de ellos, la culpa es de que el que escribió las bibliotecas y herramientas que utilizan no las documentó y actualmente no hay ningún recurso en Openbravo para documentarlas.

El segundo caso me pasó cuando intentamos utilizar un informe que desarrollamos según las indicaciones del wiki de Openbravo, este informe funcioaba perfectamente en la versión 2.35 pero al intentar compilarlo en la versión 2.40 no funcionaba. El problema venía porque habían modificado unos atributos privados de la clase base  de la que heredaba la clase que lanzaba el informe. En verdad habían hecho bastante limpieza en esa clase y si a eso le añadimos que a los atributos no se accede mediante métodos públicos, una interfaz pública pues no tiraba. Lo suyo es que como se comenta más arriba se mantenga el api de todas las bibliotecas que se utilizan en el proyecto a lo largo del tiempo. Se podría refactorizar el código pero siempre que mantuvieras las interfaces de las clases, pero es que en muchos casos ni siquiera hay interfaces bien definidas.

El tercer caso me ha pasado al intentar actualizar Openbravo, se supone que Openbravo utiliza un fork propio de ddlutils para la manipulación de la información en la base de datos. Su actualizar de la 2.40beta  a la 2.40 funcionaba  a la perfección con la instalación de la 2.40beta limpia pero si intentaba aplicarlo sobre uno de nuestros proyectos me dió un error tan chorra como que un campo que no era único había pasado a ser único en una tabla y al detectar duplicados no podía terminar el proceso de actualización de la base de datos dejándola en un estado inconsistente. Este tipo de cambios no se deberían dar en una base de datos medianamente estable, pero si se dan y quieres hacerlos debes tener mucho cuidado de que no existan problemas al actualizar.

El cuarto caso es muy típico en Openbravo, la aplicación está plagada de campos, ventanas/pestañas que no sirven para nada pero que por alguna extraña razón alguien dejó ahí. Esto a parte de confundir al usuario da una sensación de dejadez impresionante. Aquí os dejo un ejemplo.

El quinto caso sigue ocurriendo en Openbravo, han ido limpiando muchas partes del código pasándolo al inglés pero todavía queda mucho trabajo por hacer, sigue habiendo mucho código en castellano.

¿Qué problemas soléis encontrar vosotros en los proyectos en los que estáis?

Cheli