Qué se copia y qué se borra sin avisar

Los contratos

Diseñar para el borrado de caché

La consecuencia más práctica, y merece hacerse explícita porque casi nunca se prueba:

Tu aplicación tiene que funcionar con la caché vacía, en cualquier momento, sin diferencia visible más allá de ir más lenta un rato.

Eso descarta tres cosas que la gente pone en la caché:

• Índices que tardan horas en reconstruirse. Si reconstruirlo es caro, no es caché: es un dato derivado y va a datos, con su propio mecanismo de invalidación.
• El único sitio donde está algo. Una miniatura de un fichero que el usuario ya borró, por ejemplo: si la caché es la única copia, no era caché.
• Estado de sesión. Ya lo dijo el nivel 34.5, y aquí tiene su segunda razón.

Y una prueba de un minuto que casi nadie hace: borrar el directorio de caché con la aplicación cerrada y volver a abrirla. Si algo se rompe, está mal colocado.

La configuración que viaja

La segunda fila tiene una consecuencia que se olvida: la configuración se restaura en otra máquina, sea por una copia de seguridad o por un perfil que viaja. Y hay cosas que no tienen sentido allí:

El estado de ventana fuera de pantalla es el más visible de los tres y merece la comprobación defensiva: al restaurar posición y tamaño, verificar que la ventana cae dentro de alguna pantalla existente, y si no, centrarla. Son cinco líneas y evitan una aplicación que arranca invisible.

Y el usuario que quiere limpiar

Una decisión de producto que sale de todo esto: ofrecer una forma de borrar la caché desde la propia aplicación. Es fácil —ya sabes qué directorio es y qué contrato tiene— y resuelve dos cosas: el usuario que quiere recuperar espacio sin buscar directorios ocultos, y el diagnóstico de soporte, donde «borra la caché y vuelve a probar» es un primer paso que resuelve una parte de las incidencias.

Lo que no conviene es ofrecer un botón que borre los datos sin una confirmación seria. Es la operación irreversible de tu aplicación, y merece el mismo cuidado que cualquier otra.