Desarrollo web y aplicaciones

Una web corporativa publica información destinada a ser leída: solo cambia cuando alguien decide modificarla. Una aplicación web hace avanzar un trabajo: contiene cuentas, permisos, datos que cambian de estado a medida que se usa y reglas que deciden qué está permitido. El criterio de distinción no es el número de páginas ni la apariencia, sino la presencia de un estado que evoluciona. Es ese criterio el que gobierna la forma de comprobar antes de publicar, el alojamiento necesario y la carga de mantenimiento que habrá que asumir después.

La cuestión se decide observando qué hay realmente particular en su actividad. Si la necesidad es corriente —publicar, vender de manera clásica, concertar citas—, un producto configurado hace el trabajo y su mantenimiento corre a cargo de otros. El desarrollo a medida se justifica cuando una regla de negocio, un encadenamiento o una restricción propia de la organización no puede expresarse en un producto existente, o cuando adoptarlo obligaría a deformar lo que funciona. La vía intermedia es frecuente y a menudo la mejor: una base existente completada con un desarrollo limitado al punto preciso en el que la organización se diferencia de las demás.

Nada de eso se da por supuesto y se decide por escrito antes de empezar. Hay tres elementos distintos en juego. El nombre de dominio, que debe registrarse a nombre de la empresa y no de su proveedor. El código fuente, del que hay que saber si se cede, se concede bajo licencia de uso o se compone de piezas abiertas sujetas a sus propias condiciones. Y los datos, que deben poder recuperarse íntegramente en un formato utilizable fuera de la herramienta. A esos tres elementos se suman las credenciales: alojamiento, base de datos, servicios de terceros, procedimiento de despliegue. Tener el código sin las credenciales no da autonomía.

La aceptación es la comprobación, por parte de quien encargó el trabajo, de que lo entregado hace lo que se había pedido. Se distingue de las pruebas de quien programa, que verifican que el programa hace lo que su autor cree haber escrito. La realizan personas del oficio, en un entorno distinto del de producción, con datos realistas y escenarios escritos de antemano. Se busca lo que se rompe más que lo que funciona: campos vacíos, textos demasiado largos, caracteres poco habituales, acciones simultáneas, retroceso del navegador. Concluye con una decisión escrita y con la separación entre lo que es una corrección y lo que es una evolución.

Abarca tres actividades que conviene distinguir. La corrección trata los defectos constatados. La evolución añade lo que el uso ha revelado. La conservación en estado operativo consiste en actualizar los componentes de los que depende el sitio cuando se publica una vulnerabilidad, seguir las versiones del lenguaje y del sistema, renovar los certificados y comprobar que las copias de seguridad se restauran y que los servicios de terceros no han cambiado sus interfaces. Es esa tercera actividad la que responde a la pregunta: un programa que no se toca no permanece estable, porque todo aquello sobre lo que se apoya sigue evolucionando sin él.

La lentitud percibida tiene causas acumulativas, y conviene saber cuál domina antes de actuar. Las imágenes sin redimensionar y servidas en un formato inadecuado suelen ser la causa. Después viene la cantidad de código cargado y ejecutado antes de que la página resulte utilizable, a menudo hinchada por guiones añadidos con el tiempo sin que nadie retire ninguno. Luego el tiempo de respuesta del servidor, ligado al alojamiento y a las consultas hechas a la base. Por último, la elección de calcular las páginas por adelantado, a demanda o en el navegador. Esas causas se miden, y la medida se toma en un dispositivo y una conexión corrientes, no en el equipo de quien programa.

La accesibilidad es la propiedad de un sitio de resultar utilizable por personas cuyas capacidades, herramientas o condiciones de uso difieren de las que se imaginan por defecto. En concreto: una estructura de página correcta, para que las tecnologías de apoyo anuncien qué son los elementos; un uso completo con el teclado; un rótulo asociado a cada campo; un contraste suficiente; ninguna información transmitida solo mediante el color; el elemento activo siempre visible. Sirve mucho más allá de las situaciones de discapacidad, porque una conexión mala, una pantalla a pleno sol o una mano ocupada crean las mismas necesidades. Se concibe desde el principio: retomada al final, obliga a rehacer los componentes.

Un sitio bien concebido se adapta a las pantallas pequeñas, se actualiza sin intervención del usuario, se abre desde un simple enlace y no depende de ninguna tienda de aplicaciones. Eso cubre lo esencial de las necesidades corrientes. Una aplicación instalada se justifica cuando hay que funcionar sin red, acceder a funciones del dispositivo que el navegador no expone o expone mal, enviar notificaciones de manera fiable o sostener un uso diario e intensivo. Su coste real no es fabricarla sino convivir con ella: sistemas distintos que seguir, publicaciones sometidas a validación, versiones antiguas que siguen instaladas en los equipos de los usuarios. Lo que hay que decidir es el uso previsto, no la modernidad aparente.

Una interfaz de programación es un conjunto de direcciones mediante las cuales un programa pide algo a otro y recibe una respuesta en un formato convenido. En un proyecto web separa la interfaz visible de las reglas y los datos: la pantalla pide, el servidor decide y responde. Esa separación tiene tres efectos prácticos. La interfaz puede rehacerse sin tocar las reglas. Otra herramienta —una aplicación interna, una aplicación móvil, un socio— puede alimentarse con los mismos datos. Y los servicios de terceros, pago, cartografía, envío de mensajes, se integran por el mismo mecanismo, con la dependencia que ello supone: sus condiciones, su disponibilidad y sus cambios pasan a ser los suyos.

Un sitio ya conocido por los buscadores ha acumulado algo invisible: direcciones indexadas y enlaces que apuntan a ellas. Una reconstrucción que cambia las direcciones sin redirigirlas pierde ese activo, y restablecerlo exige más esfuerzo del que habría costado conservarlo. La precaución consiste en inventariar las direcciones existentes antes de empezar, decidir para cada una la dirección que la sucede y establecer las redirecciones permanentes en el momento del cambio. Dos comprobaciones completan la operación: retirar las instrucciones que impedían la indexación durante la fabricación y confirmar que las páginas importantes siguen siendo alcanzables. El contenido sigue siendo el factor determinante: un rediseño que lo empobrece degrada el resultado sean cuales sean las redirecciones.