Obviedades olvidadas de los proyectos de software

A la hora de desarrollar software se nos llena la boca con grandes arquitecturas, servidores, servicios, patrones, bibliotecas,... Pero al final, seguimos obviando los mismos detalles básicos en el diseño y construcción de nuestras aplicaciones y sistemas.

Obviedades en el desarrollo de software

A modo de ejemplo, las obviedades más habituales:

• Cadenas. A la hora de leer o escribir ficheros de texto, ¿cual es la codificación empleada? Aquí, muchos lenguajes y bibliotecas han avanzado tanto que han tomado demasiadas decisiones transparentes al desarrollador, haciendo que, en cualquier momento, por problemas de interoperabilidad, falle la aplicación. Ejemplo: en Java, por defecto, al volcar un String, lo hará con el encoding por defecto de la plataforma, haciendo que algo hecho en un ordenador no funcione en otro. Problema similar pueden dar los saltos de línea. 
• Fechas. Las fecha-hora dependen de nuestra forma de contar, del lugar en el mundo donde están los ordenadores,... Pero si generamos un dato, y luego lo leemos en otra máquina, las formas de interpretar la fecha-hora pueden variar. ¿todos los días duran 24 horas? No, al menos en España, hay un día al año que dura 25 horas, y es debido al cambio de hora de octubre. Podríamos tener problemas al guardar eventos cada x tiempo, y que hubiera 2 eventos a la misma hora. 
• Enteros. No todos los números enteros tienen igual tamaño, por lo que no tienen los mismos límites y, dependiendo de las optimizaciones del compilador, ciertas operaciones darnos overflow sin siquiera preverlo. ¿pudieran interesar con signo o sin signo? 
• Punto flotante. Si damos por hecho que, como regla general, no se puede hacer comparaciones de igualdad entre 2 números flotantes, hay que decidir nuestro rango de aceptación, que se manejará a lo largo de TODO el programa. También pueden surgir problemas de rango y de representación. 
• Manejo de la memoria. Con la difusión de los recolectores de basura, ya sea interno a la máquina virtual o mediante bibliotecas, pocas veces prestamos atención a la forma en que requerimos memoria y la liberamos. ¿Qué es mejor, pedir muchos trozos pequeños de memoria o pedir uno grande?  ¿Crear muchos objetos temporales? ¿cual es el tamaño de pila adecuado? 
• Imágenes. Casi nadie lee o escribe imágenes usando código creado desde cero, al igual que solemos dejar que las capas inferiores de la interfaz de usuario gestionen la representación de dichas imágenes, pero, ¿qué pasa con las modificaciones? La forma en que están grabados los datos y como se muestran no tienen porque ser coincidentes. Uno puede ser lineal y el otro cuadrático, diferentes gammas en diferentes sistemas, diferentes perfiles de color,... Pueden hacer que los cambios realizados no se vean como esperábamos. 
• Base de datos. Dentro de los elementos básicos de una aplicación, este es el que creo que esta más  presente para los programadores de hoy en día, pudiendo aparecer los típicos problemas de autocommit, bloqueos, SQL injection,...
• Diseño. Sobre todo en aplicaciones a medida, se hace un esfuerzo en la etapa del análisis (toma de requisitos, casos de uso, historias del usuario,...), pero luego apenas hay bocetos del diseño y lo siguiente que hay es la construcción. Luego, al tomar decisiones posteriores de alto nivel, siempre se hace con pies de barro.
• Interfaz de usuario. Muchísimas aplicaciones primero crearon su funcionalidad y, tras detectar graves errores de usabilidad, se tuvieron que cambiar bastante. Y no me refiero a que fueran bonitas, sino a formas de interactuar, gestionar la información, el contenido de la pantalla, la metáfora del usuario,...

Dada la importancia que creo tiene este tema, intentaré en futuras entradas, centrarme en algunos de estos u otros puntos tan básicos y olvidados del desarrollo de software - interoperabilidad.