Combatir (percibir) la sobreingeniería contra el flujo [cerrado]

8

Me uní a un equipo que tiene un enfoque de diseño diferente al mío. Creo en el enfoque de diseño de YAGNI. Por ejemplo, si un método (interfaz, clase) no se utiliza, debe eliminarse. Eso es todo.

La gente en mi equipo está construyendo una aplicación modular, y uno de los módulos se percibe como "marco". La aplicación es el único usuario de este marco, y no hay planes en este momento para que tenga más clientes. Sin embargo, partes del código en este marco se escriben y se mantienen como si pudieran usarse más adelante , y la coherencia y la integridad ganan sobre YAGNI. Hay abstracciones en lugares que tal vez nunca necesiten abstracciones, etc.

Traté de discutir algunas cosas, pero cada punto toma mucho tiempo para persuadir, en todo caso, y me temo que demasiados "empujones" harán que el equipo se separe en lados opuestos.

Puedo "seguir el flujo" y escribir código adicional sin ningún problema personal. Ahora me llevará más tiempo codificar, y lo más probable es que, más tarde, mantener, sin embargo , cada discusión para no hacer algo adicional también requiere tiempo y aumenta la presión.

La pregunta es, en el caso de opiniones diferentes, ¿qué hará un mayor daño, un código innecesario pero "correcto", o argumentos constantes y una dinámica de equipo rota?

    
pregunta coverback 08.03.2017 - 10:57

6 respuestas

4

Mantener un marco imaginario es una decisión arquitectónicamente significativa, por lo que la pregunta se reduce a "cómo surgimos y evolucionamos la arquitectura" en el equipo. Debe comenzar con reglas de toma de decisiones bien definidas que sean claras y aceptadas por todos en el equipo porque no hay juego sin las reglas .

Al unirse a la empresa, una de las preguntas más importantes que puede hacer es:

  

¿Cómo funciona el proceso de toma de decisiones en el equipo y cómo evoluciona con el tiempo?

Ningún proceso de toma de decisiones es peor que malo el proceso de toma de decisiones. Si no hay proceso, alguien necesita definir uno. De lo contrario, la cantidad de tonterías aumenta junto con la cantidad de desacuerdos con el equipo.

Creo que con esto estamos cerrando el ciclo: o tienes autoridad y poder para definir el proceso de toma de decisiones cuando falta, O estás de acuerdo con el proceso actual y cómo evoluciona. Elige uno.

    
respondido por el Eduards Sizovs 08.03.2017 - 13:29
1

Los argumentos constantes y las dinámicas rotas del equipo nunca te llevarán muy lejos.

Trataré de comprender por qué hay un marco en primer lugar.

Lo más probable es que la razón sea que se espera que se use en otros sistemas más adelante. Si ese es el caso, entonces tiene sentido hacer más de lo necesario en este momento.

El motivo es que si una aplicación está en producción, una nueva aplicación está en proceso y requiere actualizaciones del marco, entonces cada vez que se cambia algo en el marco, tal vez se agreguen abstracciones que no eran necesarias anteriormente, entonces la aplicación original para ser actualizado y probado también.

Eso es una gran cantidad de refactorización y reevaluación de algo en producción.

Si eligió no incluir el marco actualizado en la aplicación anterior, entonces tiene 2 marcos para mantener uno de los cuales ya está obsoleto.

Mantener el código obsoleto tampoco es muy bueno para la moral.

    
respondido por el Bent 08.03.2017 - 11:53
1

Si eres nuevo en un equipo, tratar de no ser una perturbación en la fuerza debe ser tu primera preocupación.

Supongo que no estás en una posición de líder / arquitecto, y las decisiones no dependen de ti.

La preocupación segunda es Aprender . Aprender mucho. Sepa por qué tomaron las decisiones que tomaron, por qué se creó el marco, qué es lo racional detrás de eso. Cuando tenga toda la información, puede tomar una decisión informada sobre cómo abordar los posibles problemas, como la sobreingeniería y la mala comunicación.

Haga preguntas, de manera educada . Ponte en la posición de un estudiante, y no de un maestro. Facilitará que las personas le "enseñen" por qué hicieron las cosas de esa manera.

Ahora mismo eres el marginado. Te estás uniendo a un equipo extranjero, y debes aprender sus costumbres y adaptarte.

Si haces tu trabajo de la manera correcta, con un enfoque cortés hacia las personas, las personas te escucharán naturalmente con el tiempo. Y luego, si tiene toda la razón, su enfoque es el mejor en su conjunto, puede influir en las personas para que cambien.

Apenas conozco a alguien a quien le guste trabajar con una persona que critica a menudo, pero no genera valor. Sea una referencia para su equipo, alguien con quien están orgullosos de trabajar.

También, lectura recomendada: enlace

    
respondido por el Machado 08.03.2017 - 17:14
0

Hay 2 cosas fundamentales que creo que están sucediendo. El primero es cultural. Eres nuevo en el equipo y aún no has descubierto cómo trabajar con este equipo. Probablemente tienen diferentes políticas y prácticas que pueden funcionar para ellos. Además, uno o más de ellos pueden haber solicitado tu posición y, por lo tanto, pueden estar saboteando activamente tus esfuerzos o simplemente no decirte lo que necesitas saber.

El segundo es que posiblemente hayas leído mal el diseño. La parte que usted cree que es un código muerto puede ser en realidad una generalización de otras partes del diseño o puede estar trabajando para respaldar algo que la empresa finalmente quiera respaldar. En realidad puede ser código muerto. Deja de obsesionarte por eso y entiende por qué está ahí. En realidad, puede llevar meses resolverlo.

En industrias adversas al riesgo (es decir, banca, medial ...) donde existe la pequeña posibilidad de que se pueda usar una parte del código, esa parte del código se mantendrá durante décadas.

Para resaltar esto, una de las estructuras de bases de datos extrañas que he visto está centrada en 6 tablas. 3 de ellas eran tablas de mapeo que conectaban las otras tres. No tenía ningún sentido ya que el código indicaba que solo uno de ellos se estaba utilizando como una relación de muchos a muchos y los otros dos se estaban implementando de uno a muchos. Los diseñadores originales se habían ido y nadie podía explicar exactamente cómo o por qué funcionaba. Finalmente, encontré un documento comercial que explicaba el diseño, así que supongo que la empresa lo había solicitado y que algunos DBA se habían implementado de una manera que la empresa podía entender, a pesar de sus obvias limitaciones. 30 años más tarde todavía está allí, ganando dinero de la empresa, pero desde un punto de vista de desarrollo difícil de entender, mantener y desarrollar.

    
respondido por el Robert Baron 08.03.2017 - 13:21
-1

Veo algunos puntos positivos acerca de tener una pieza de este tipo fuera de la aplicación, incluso si nadie más la usa.

Esto puede imponer el desarrollo de funcionalidades técnicas en el marco con sus pruebas adecuadas fuera del contexto funcional de la aplicación (y en su propia hoja de ruta).

Además, es posible que no desees que todos los desarrolladores desarrollen ese marco, sino solo los más avanzados, por lo que, de nuevo, obtenerlo fuera de la aplicación es una ventaja.

Para las capas de abstracción que no son necesarias, bueno, si ya están allí, no cambies algo que ya esté funcionando.

Sin embargo, puede que recuerde a su equipo para el futuro que el objetivo del marco es aligerar su trabajo, sin ponderarlo.

    
respondido por el Walfrat 08.03.2017 - 11:08
-3

Leyendo entre líneas, me inclino hacia los miembros de tu equipo. Hacer algo "más complicado de lo necesario" no solo allana el camino para una posible funcionalidad futura que quizás nunca se necesite, también sirve para que los desarrolladores entiendan la aplicación, incorpora un modelo en el software, documenta una idea.

Y al hacerlo, restringe la forma en que pueden ir los desarrollos futuros. Mantiene a los desarrolladores que no entienden completamente el diseño / la intención de desviarse.

Al principio, un nuevo desarrollador puede sentirse molesto por el diseño "innecesariamente complicado", pero también lo guía en la dirección correcta, lo hace caer en la trampa del éxito y le hace más difícil "hacer las cosas a su manera ", lo cual sería otra manera de complicar las cosas porque conduciría a diferentes enfoques en la misma aplicación, lo que hace que sea aún más difícil para el próximo jugador tener la cabeza alrededor.

YAGNI no significa (o no debería) que significa "puede omitir el diseño" o "hacerlo rápido y sucio". Si su equipo tiene el lujo de pensar en las cosas, diría que es algo que apreciar y no luchar.

    
respondido por el Martin Maat 08.03.2017 - 16:28

Lea otras preguntas en las etiquetas