Escapando del modelo de desarrollo "mete-saca"

¿Qué nos mueve a seguir implementando aplicaciones que no son más que entrada/salida de datos y se dedican, al igual que hacía Microsoft Access, a presentar listas de información para editar e insertar registros? Este modelo de trabajo al que denominamos "mete-saca", puede ser consecuencia de varios factores culturales, de uso de una arquitectura enlatada o de frameworks de referencia del lado cliente que nos guían hacia un modelo inadecuado. En esta charla analizaremos como huir de los modelos SPI MV* en cliente soportados por backends REST, con el fin de evolucionar a un sistema basado en acciones o eventos de negocio que permitan sacar un mayor partido al código implementado y a su evolución. Finalmente, analizaremos cómo implementar estos patrones de forma sencilla y cómo algunas propuestas como Flux o Falcor/Relay nos ofrecen alternativas a los modelos tradicionales.

Transcript

1. Modelo de Desarrollo Ricardo Borillo @borillo “mete-saca” Escapando del
5. ¿Qué es el modelo de desarrollo “mete-saca”?
8. ¿Qué es Aportar valor?
14. Resuelve un Caso de uso cada vez ...
16. ¿Y los criterios de Aceptación?
29. 1Bad User Stories?
34. DoD
35. 2Datacentric? Anemic?
39. Bad UI architecture? 3
45. Bad US/DoD Anemic design Poor client architecture
47. CQRS Command Query Responsibility Segregation
49. UI Task-based
50. “The only constant is change” Let’s talk about state ... Heráclito:
51. State Change Analysis
54. UX feature
58. single end-point...