¿Cómo evitar que un colega introduzca extrema complejidad y abstracción?

Estoy teniendo un momento muy difícil porque mi colega parece exhibir

1. Esfuerzos de optimización prematuros / innecesarios
2. Deduplicación prematura con abstracciones cuestionables
   Por ejemplo, utilizamos una arquitectura VIPER modificada. Introdujo una clase base para el componente Enrutador (usando genéricos) como parte de la implementación de la primera pila de víboras sin saber qué se duplicará exactamente en otros enrutadores. Ahora estamos atascados con tener que proporcionar un tipo UseCaseque contenga casos de uso, pero la mayoría de los enrutadores no tienen múltiples casos de uso, solo uno.
3. Inventar soluciones de propósito general para futuras características especulativas potenciales
   Por ejemplo, escribió un administrador para poblar vistas estáticas de tablas de celdas cuando solo teníamos dos pantallas como esta en la aplicación y no sabía que el diseño pasaría de formas verticales aburridas a más personalizadas. IU, por lo que el administrador es inútil.
4. Optando por la complejidad incidental

¿Cómo peleo esto cuando él también exhibe tener una barrera del idioma con un pésimo inglés?

Su descripción suena como la codificación que hice en la década de 1990. Actuar adecuadamente para el mundo moderno no es fácil. Recomiendo centrarse en los siguientes factores:

• Emparejamiento. Dos pares de ojos pueden ayudar a protegerse contra la implementación excelente, pero complicada de una persona.
• Revisión de código. Las tiendas modernas revisan el 100% de todos los cambios de código por varias personas
• Cobertura de prueba. Asegúrese de que haya pruebas simples. Las pruebas demasiado complicadas pueden reflejar código demasiado complicado
• Mucha discusión sobre el producto mínimo viable. Descomponga las características en los componentes más pequeños posibles. Está bien tener un ticket para cambiar la base de datos, otro para llenar las tablas de referencia y luego un tercero para actualizar la interfaz de usuario (la parte que en realidad será visible para los usuarios finales), pero se sentirá contra-intuitivo en primer lugar, ya que la resistencia es probable.
• Debates frecuentes sobre cómo tener entradas y cambios más pequeños.
• Punto de la historia de votación por todo el equipo para abrir discusiones sobre la complejidad y el enfoque.
• Educación. Asegúrese de almorzar y aprender, sesiones de capacitación, etc. para que las personas puedan exponerse a las buenas prácticas y por qué son buenas.

De todo lo anterior, mis dos puntos principales de enfoque serían revisiones de código e historias más pequeñas.

Al final del día, creo que la mejor solución para cambiar el comportamiento existente es tener una persona dedicada que lidere el cambio. En las organizaciones ágiles (probablemente la mayoría hoy en día), se necesita una persona dedicada, como el scrum-master, para hacer constantemente las preguntas correctas y guiar el enfoque de desarrollo. En mi última organización teníamos una docena de ellos, uno en cada equipo para ayudar a guiar a las personas a través de este tipo de problemas. Esto elimina la necesidad de que un desarrollador miembro del equipo intente convencer a otros de que "su camino es correcto", lo que a menudo puede conducir a intercambios hostiles y mala sangre.