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

14

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, usamos 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íbora sin saber realmente qué se duplicará exactamente en otros enrutadores. Ahora tenemos que tener que proporcionar un tipo UseCase que tenga 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 características futuras especulativas potenciales
    Por ejemplo, escribió un administrador para rellenar las vistas de la tabla de células estáticas cuando solo teníamos dos pantallas como esta en la aplicación y no sabía que el diseño pasaría de las formas verticales aburridas a otras IU personalizadas, por lo que el administrador es inútil. li>
  4. Optando por una complejidad incidental

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

    
pregunta Earl Grey 29.12.2016 - 15:03

1 respuesta

13

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 una persona, pero una implementación complicada.
  • Revisión de código. Las tiendas modernas revisan el 100% de todos los cambios de código realizados por varias personas
  • Cobertura de prueba. Asegúrese de que hay pruebas simples. Las pruebas excesivamente complicadas pueden reflejar un código demasiado complicado
  • Mucha discusión sobre el producto mínimo viable. Desglosa las características en los componentes más pequeños posibles. Está bien tener un ticket para cambiar la base de datos, otro para rellenar las tablas de referencia y luego un tercero para actualizar la interfaz de usuario (la parte que realmente será visible para los usuarios finales), pero se sentirá contraintuitivo ya que la resistencia es la primera. probable.
  • Discusiones frecuentes sobre cómo obtener tickets y cambios más pequeños.
  • El punto de votación de todo el equipo para abrir discusiones sobre la complejidad y el enfoque.
  • Educación. Asegúrese de tener Almuerzo y Aprendizaje, sesiones de capacitación, etc. para que las personas puedan conocer las buenas prácticas y por qué son buenas.

De todo lo anterior, mis dos puntos principales de enfoque serían las revisiones de código y las 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 en la actualidad), se necesita una persona dedicada como scrum-master para hacer las preguntas correctas y guiar el enfoque de desarrollo constantemente. En mi última organización teníamos una docena de ellos, uno en cada equipo para ayudar a guiar a la gente a través de este tipo de problemas. Esto elimina la necesidad de que un miembro del equipo del desarrollador intente convencer a los demás de que "su camino es correcto", lo que a menudo puede llevar a intercambios crónicos y mala sangre.

    
respondido por el Michael Durrant 29.12.2016 - 15:24

Lea otras preguntas en las etiquetas