En este artículo, abordaré la cuestión del umbral para ingresar a un proyecto con una arquitectura establecida y daré varias opciones para responder una pregunta muy frecuente: ¿por qué es tan difícil?
Esta pregunta a menudo surge entre los recién llegados que vienen al proyecto. O hay situaciones en las que el proyecto entra en soporte y desarrollo en nuevas manos, y el nuevo desarrollador también tiene esta pregunta. Y raramente, uno de ellos está tratando de descubrir las verdaderas razones por las cuales es así aquí y no de otra manera. Esto puede llevar a tristes consecuencias para el negocio, por ejemplo, un nuevo desarrollador puede insistir en reescribir toda la aplicación desde cero.
Para minimizar tales riesgos, en lugar de preguntar por qué es tan difícil? hacer tales preguntas:
- ¿Qué requisitos para el proceso de desarrollo fueron establecidos por el arquitecto?
- ¿Cuál es el resultado del proceso de desarrollo requerido en la salida?
Requisitos del proceso de desarrollo.
Primero, el desarrollador debe profundizar en el sistema del proceso de desarrollo, debe hacer la siguiente pregunta:
- ¿En qué sistema se basa el proceso?
A menudo, en el desarrollo personalizado, un proyecto con requisitos inequívocos y un conjunto fijo de funcionalidades llega a la entrada. Cuán bien desarrollados pueden estar: este es el tema de otro artículo. Y el proceso de desarrollo en tales proyectos se construye con mayor frecuencia de acuerdo con un sistema en cascada, porque involucra la retroalimentación directa de los usuarios del producto, después del desarrollo de toda la funcionalidad del producto , mientras que con un modelo iterativo, la retroalimentación se puede obtener después de la primera iteración. Para tales proyectos, el arquitecto generalmente ya tiene una arquitectura establecida que cumple con ciertos requisitos para este proceso. ¿Cuáles son los requisitos para tal proceso de desarrollo establecido por el arquitecto?
1) El proceso de desarrollo de la tubería debe ser lo más complejo posible para el desarrollador. Y el rechazo del código que ingresa al repositorio del proyecto debe ocurrir al máximo automáticamente y, si es posible, sin la participación del propio arquitecto.
Es decir Se debe configurar una tubería específica en el proceso. El código que pasó por toda esta tubería se considera satisfactorio. Esto es muy importante porque un buen arquitecto necesita salvar a sus desarrolladores del dolor de cabeza y la responsabilidad de no trabajar en el ensamblaje después de que el código ingrese al repositorio. Si no existe dicha canalización , sus desarrolladores sufrirán un estrés constante. Si el código entró en el repositorio y la tubería lo aceptó, y este código rompió el ensamblaje o dañó la funcionalidad que ya funciona, esto ya es un problema de la tubería en sí.
Por lo tanto, en dicha canalización, debe usar:
- Muchos analizadores de código estático
- Pruebas automatizadas y pruebas de cumplimiento piramidal
- Cálculo automático de cobertura de código por pruebas
- La puerta de entrada a la calidad del código (puertas de calidad). Para todo tipo de métricas: porcentaje de cobertura de código con pruebas, porcentaje de duplicación de código, olores de código, seguridad, errores, etc.
- revisión de código cruzado
- etc.
Todos estos puntos juntos conducen a la pregunta del desarrollador: ¿por qué es tan difícil?
Por ejemplo, intente escribir pruebas para este código:
class SomeService( private val restApi: SomeApi
Tendrá que ejecutar tales pruebas en un dispositivo Android real o en un emulador. Y esto conducirá inmediatamente a una reducción significativa en el segundo requisito para el proceso de desarrollo:
2) Los elementos de tubería automatizados y el proceso de desarrollo deben realizarse lo más rápido posible
Si sus desarrolladores tienen que esperar mucho tiempo para que se completen las pruebas, este es el problema de su tubería y si la arquitectura no permite acelerar este proceso, este es el problema de su arquitectura
Reescribamos el ejemplo:
interface SomeApi { fun loadSomething(): Single<NetworkResult> } class NetworkSomeApi : SomeApi { override fun loadSomething(): Single<NetworkResult> { } } class SomeService( private val restApi: SomeApi
Vemos que la complejidad del código ha aumentado, pero desde el punto de vista del proceso de desarrollo: hemos hecho que la arquitectura sea más flexible, ahora no tenemos que ejecutar pruebas de lógica de negocios para el bloque de map en el emulador o en el dispositivo, solo ejecutarlas en pruebas rápidas. Esto reducirá la cantidad de pruebas de integración que deben ejecutarse en un entorno lento.
El patrón de diseño elegido por el arquitecto puede reducir la cantidad de costosas pruebas de integración. No seas perezoso y trata con los patrones que son populares hoy: MVP , MVVM , MVI .
Hablemos un poco más sobre la navegación en la aplicación. También queremos poder probarlo y probarlo en pruebas rápidas. Nuevamente, tenemos una "complicación" de la arquitectura, porque tenemos que ocultar el sistema de navegación en la aplicación detrás de la abstracción.
Y también queremos poder conectar los componentes de nuestro sistema usando DI, construir gráficos de dependencia y verificar su corrección en la etapa de compilación del proyecto, y no en tiempo de ejecución. Entonces Dagger 2 y sus monstruosos componentes y subcomponentes con módulos aparecen en el escenario, que ya confunden al pobre principiante al final.
Y esos momentos poco obvios de "complicación" de la arquitectura para principiantes se acumulan mucho. Naturalmente, sin comprender los procesos de desarrollo y los requisitos para estos procesos, tienen la misma pregunta: ¿por qué es tan difícil?
Resultado del proceso de desarrollo
Para evaluar el éxito del proceso de desarrollo integrado y, indirectamente, la arquitectura del proyecto, es necesario analizar su resultado. Como regla, el resultado es un producto (una aplicación si hablamos de desarrollo móvil). Y las métricas de éxito del producto son diferentes para todos: el cliente tiene las mismas métricas, el desarrollador tiene sus propias métricas, el usuario del producto tiene las suyas.
Como mínimo, usted, como el arquitecto que crea la tubería para el proceso de desarrollo, debe tener en cuenta al evaluar la efectividad del proceso de desarrollo de las métricas y las métricas comerciales de su empresa.
Este es un proceso continuo: desarrollo -> recopilación de métricas -> análisis del resultado -> haciendo las modificaciones necesarias al proceso de desarrollo.
Por lo tanto, el resultado afecta la formación del proceso de desarrollo y el proceso de desarrollo ya afecta el cambio en la arquitectura del proyecto. Es decir La idea importante que quiero transmitir es que la arquitectura es secundaria, el resultado primario y el proceso de desarrollo .
Conclusión
En conclusión, digamos nuevamente:
- sin comprender los procesos de desarrollo y los requisitos para estos procesos, el desarrollador crea la sensación de una arquitectura de proyecto complicada;
- la arquitectura es secundaria, resultado primario y proceso de desarrollo;
Sin una comprensión de estas cosas, un desarrollador puede querer tomar y reescribir todo desde cero. En mi opinión, esto se justifica solo cuando el proceso de desarrollo y el resultado no satisfacen completamente al cliente de este desarrollo.
Para principiantes, le aconsejo que se meta en un proyecto con una tubería de desarrollo refinada. El umbral de entrada a tales proyectos es alto, pero al superarlo, abordará seriamente la comprensión de cómo se construyen los procesos de desarrollo.