¿Cómo implementar una plataforma web y una app mobile sabiendo que 1. durante muchos meses seré el único que trabaje en las dos implementaciones, 2. la segunda persona que se una debería entender de forma fácil la implementación que se le asigne y 3. si necesitamos o queremos intercambiar responsabilidades sea relativamente simple?
Trabajo en un proyecto que busca mejorar la calidad de vida de personas que han tienen un marcapasos, el objetivo de la plataforma es, por un lado dar acceso a los médicos tratantes a la información del paciente, permitirles comunicarse y facilitarles en el diagnóstico y en la toma de decisiones. El otro lado relevante, para este post, es la aplicación para los pacientes, desde ahí pueden comunicarse con sus médicos, ingresar y acceder a información relevante.
Entrando en el tema técnico, el frontend, la webapp para los médicos y la app mobile para los pacientes, está implementada con react - reactjs y react-native respectivamente - hay librerías que tienen en común, por ejemplo: luxon, redux, e immerjs.
Detalles que pueden gustar a algunos y desagradar a muchos otros, el frontend está escrito con javascript, no es typescript, ni siquiera usa flow. ¿Por qué? porque hay razones varias para este proyecto que van desde condiciones de negocio, constraints en el ambiente, preferencias, etc. Personalmente no me afecta, considero que hay proyectos en los que typescript es el camino adecuado y otros en los que javascript es la opción, así como hay escenarios en los que mi sugerencia sería implementar una app nativa usando swift (iOS) y kotlin (android), estoy convencido que tener dogmas en el lenguaje de elección o en la librerías e incluso en la arquitectura es perjudicial no solo para la app, sino para el negocio y más importante para la persona.
"Cómo implementar la estructura de directorios?" es un tema que siempre me interesa y me preocupa, acceder al archivo necesario de forma eficiente, poder entender donde encontrar cierta implementación o entender porque está implementado en cierto lugar debe ser una tarea que facilite el trabajo del desarrollador. La forma en que estructuro los directorios, salvando errores que cometo en el proceso, es hacer un reflejo casi exacto de la arquitectura, es decir los bloques grandes que contienen la vista general de la app son los que determinan la estructura del directorio, no todo se ajusta a esa idea y el proceso tiene que ser pensado y revisado constantemente.
Otro elemento importante que sugiero prestar atención es la extracción de librerías para uso común entre partes de la plataforma.
- Librerías de componentes visuales: actualmente la plataforma tiene una sola webapp que es para los médicos, pero a futuro hay planes de implementar interfaces para otro tipo de usuario, si queremos consistencia es más fácil extraer esa consistencia y colocarla en una librería.
- Acceso al API: si cualquiera de las aplicaciones necesita acceder a la información de la plataforma a través de un api, lo conveniente es extraer la implementación que hace de puente entre backend y la app.
Los beneficios son múltiples, si se desea, a futuro se puede liberar la librería para que otra gente use algo que creemos funciona y ayuda a otros desarrolladores, OSS. También empezar un nuevo proyecto, incluso un prototipo, con cada iteración es más ágil y eficiente.
Obviamente tiene desventajas, el mantenimiento debe ser riguroso, cualquiera puede acceder a la librería y modificarla de acuerdo a la necesidad del momento. Es responsabilidad de esa persona y de todo el equipo velar por la consistencia de esa librería, por la integridad de ese cambio y de mantener la dependencia actualizada a esa librería en su aplicación, pero los beneficios son mayores y en otro post hablaré sobre lo que creo es el mayor impacto de aceptar, que aunque haya un apuro de lanzar la app usando el famoso "luego lo arreglamos", es importante usar tiempo de desarrollo para el mantenimiento de la plataforma o en otras palabras:
siempre habrá technical debt, acumularla y no hacer nada por mantenerla estable es lo peligroso.