Developer experience (DX) o experiencia del desarrollador, son las características de usabilidad del software cuando su desarrollo va dirigido a otros desarrolladores.
Es un concepto similar al User Experience (UX) o Experiencia de Usuario, donde se caracteriza lo usable (fácil, intuitivo, agradable, adaptable, atractivo) que es nuestro software a un usuario final, así como la sensación que trasmite al usuario cuando lo utiliza. Un usuario interacciona con nuestro software a traves de la interfaz gráfica de usuario (GUI) y un desarrollador lo hace con nuestra API (Application Program Interface).
En el terreno de la Experiencia de Usuario entran en juego las características de Usabilidad del software e incluso las de funcionalidad, pero en la experiencia del desarrollador entran todas las demás: rendimiento, compatibilidad o portabilidad, fiabilidad, seguridad y, especialmente, la mantenibilidad (ISO 25010).
Las características del software relacionadas con UX suelen desarrollarse y aplicarse en el frontend de la aplicación, mientras que las características relacionadas con DX se implementan en el backend.
Un desarrollador de frontent debe tener en cuenta que su software será usado por usuario final o personas del negocio de la aplicación que posiblemente no tengan, o no necesiten tener, conocimientos de cómo se construye el software, ni cómo se utiliza la tecnología. Su foco está en la funcionalidad (requisitos o historías de usuario) , así como en la usabilidad de nuestra aplicación. La calidad de nuestra aplicación se mide en términos de la problemática del negocio que resuelve y lo fácil que es resolverla. El resto de aspectos de calidad del software entran en el capítuo de «que no falle».
Sin embargo, un desarrollador de backend tiene como cliente al desarrollador del frontend y su foco es aportar un API que permita resolver todas las funcionalidades solicitadas por el usuario final o las personas del negocio de la aplicación, pero con una arquitectectura y organización que permita:
- Fiabilidad, robusted: la aplicación mantiene su funcionalidad a pesar de los posibles fallos
- Tolerancia a fallos internos: Todo software complejo fallará. La aplicación debe gestionar estos fallos sin que afecte al frontend, ni al usuario final.
- Tolerancia de fallos externos: Todas las personas nos equivocamos y otras aplicaciones o sistemas, pueden fallar. Un usuario puede realizar una petición errónea, un desarrollador de frontend puede insertar un defecto en su código, otras aplicaciones o sistemas conectados a la nuestra pueden fallar. Nuestra aplicación debe gestionar estos fallos sin detenerse y sin dejar de entregar la funcionalidad al usuario final.
- Rendimiento: el nivel de respuesta de nuestra aplicación
- Tiempo de respuesta adecuado: No sólo al solicitar una funcionalidad o transacción, sino en condiciones de funcionamiento (número de usuarios y transacciones concurrentes).
- Consumo de recursos adecuado: Memoria, almacenamiento, ancho de banda de comunicaciones.
- Capacidad de escalado: Nuestra arquitectura de aplicación permite hacer crecer a la aplicación en número de usuarios y transacciones concurrentes.
- Compatibilidad, portabilidad:nuestra aplicación es capaz de realacionarse con distintos entornos
- nuestra aplicación puede trabajar con diferentes sistemas de frontend, con distintas máquinas, distintos entornos, distintos software base.
- nuestra aplicación puede ejecutarse en entornos en los que se ejecutan otras aplicaciones, aunque no se comunique con ellas.
- Seguridad: nuestra aplicación ofrece la información que debe, cuando debe y a quien debe.
- Confidencialidad: La información sólo se entrega a los usuarios y aplicaciones autorizados
- Integridad: La información no se modifica o se pierde durante la transacción
- No repudio: Existe garantía de que la información fue entregada de forma adecuada
- Autenticidad: Se garantiza el origen de la información. Mi aplicación no puede ser suplantada por otra
- Auditoría: Se puede realizar un seguimiento de quien, como y cuando usó o modificó la información
- Mantenibilidad: la facilidad de que otros desarrolladores usen o mantengan la aplicación
- Modularidad o arquitectura: organización de aplicación (componentes internos e interfaces disponibles)
- Reusabilidad: capacidad de mi aplicación o de los componentes de la misma para ser usados een otros aplicaciones, sistemas o entornos
- Analizabilidad: capacidad de la aplicación de ser analizada y comprendida, por ejemplo para evaluar el impacto de un cambio en el software
- Modificabilidad: facilidad para poder realizar una modificación en mi aplicación, como por ejemplo, el cambio de la lógica del negocio de la aplicación
- Testabilidad o facilidad para probar la aplicación: una aplicación debe ser fácil y barata de probar.
Por tanto, para el desarrollo de software, es necesario tener en cuenta requisitos y caracerísticas del software más allá de las funcionalidades y con distintos alcances y objetivos.
Un arquitecto software podría ser el perfil más adecuado para trasformar las necesidades del usuario o del negocio en diseños, arquitecturas y características del software acordes al contexto donde se utilizará el software. En cualquier caso, nuestra aplicación debe crearse para otros desarrolladores.