¿Cómo explicar por qué las opciones de diseño son buenas? [cerrado]

A medida que me convertí en un mejor desarrollador, descubrí que gran parte de mi habilidad de diseño proviene más de la intuición que del análisis mecánico. Esto es genial. Me permite leer el código y sentirlo más rápido. Me permite traducir diseños entre idiomas y abstracciones mucho más fácilmente. Y me permite hacer las cosas más rápido.

La desventaja es que me resulta más difícil explicar a los compañeros de equipo (y peor, a la gerencia) por qué un diseño en particular es ventajoso; especialmente compañeros de equipo que están atrasados ​​en las mejores prácticas. "¡Este diseño es más comprobable!" o "Deberías favorecer la composición sobre la herencia". pase por encima de sus cabezas y diríjase a la madriguera de mí tratando de dar pistas a todos sobre la última década de avances en ingeniería de software.

Mejoraré con la práctica, por supuesto, pero mientras tanto implica una gran cantidad de tiempo perdido y / o mal diseño (eso conducirá a un tiempo perdido reparándolo más tarde). ¿Cómo puedo explicar mejor por qué cierto diseño es superior, cuando los beneficios no son completamente obvios para la audiencia?

Es posible que esto no responda directamente a su pregunta, pero podría llevarlo en una dirección interesante.

Creo que lo que hay que hacer está más relacionado con venderles la idea que con explicarles . Las ventas se tratan de comprender cuál es el problema del cliente y luego mostrarles cómo su producto (o método de desarrollo, lo que sea) los beneficiará . Cada persona tiene diferentes necesidades, por lo que aquellas cosas que benefician a una persona y las entusiasman pueden dejar a otra persona fría.

Para su CEO, el tiempo de comercialización puede ser la clave, para su gerente puede ser horarios más predecibles, para sus colegas de programación puede ser una codificación más rápida (o pruebas / documentación / depuración / lo que sea más fácil), y para los clientes de su empresa puede ser ... ?

Las ventas no se producen automáticamente: debe hacer un esfuerzo concertado para comprender el punto de vista de la otra persona y luego descubrir cómo mapear sus ideas en su Happy Place ™. Una vez que saben cómo se beneficiarán personalmente de esta nueva cosa, a menudo preguntan: "¿Cuánto costará y qué tan pronto podemos hacerlo?" Una vez que escuche esas palabras mágicas, sabrá que ha hecho bien su trabajo de ventas.

Realmente no tengo una solución a su pregunta, pero hace algún tiempo me enfrenté exactamente al mismo dilema y estaba tratando de responder exactamente esta misma pregunta.

Me encontraría a un lado del argumento y alguien más al otro lado, y aunque cada fibra de mi cuerpo me dijo que el diseño correcto es X, no pude respaldarlo con palabras.

Peor aún es que a veces admitía el punto y dejaba que la otra persona lo implementara a su manera solo para que su diseño explotara en mi cara y luego pensaba: "Sí, este es un ejemplo perfecto de por qué no quería hacerlo de esa manera. Si solo pudiera demostrarles este código en ese entonces ".

Bueno, realmente nunca encontré la respuesta, pero hace unos días, cuando estaba hojeando Lean Software Development: An Agile Toolkit, Me encontré con algo interesante que podría sugerir que la respuesta en realidad no existe. Una sección del libro hablaba de líderes en otros campos, especialmente en unidades de respuesta a emergencias y cómo esos líderes tomaron decisiones. Cuando hay un incendio, o alguien te está disparando, esos líderes nunca se sientan y discuten los pros / contras con sus compañeros de equipo. En cambio, utilizan la intuición, que se desarrolló a través de la capacitación y la experiencia para ayudarlos a tomar decisiones. Lo mismo se aplica a nuestra profesión: ¿cómo puede tomar una decisión totalmente lógica ante una tonelada de incógnitas y variabilidad que es tan común en el desarrollo de software? Los autores sostienen que, en lugar de intentar justificar cada decisión, se debe alentar a los desarrolladores a entrenar y mejorar sus instintos para que eventualmente "sepan" qué hacer.

La única forma en que encontré superar estos argumentos es construir un historial probado de mi trabajo. Para mostrarle a la gerencia y a otros miembros de mi equipo que las decisiones de diseño que tomo en mi código resultan en un código que es más fácil de mantener, extender y más confiable. Haces esto repetidamente y la gente te notará. En ese punto, su opinión, que podría basarse solo en su instinto, tendrá un peso mucho mayor que el que tiene hoy. Esta estrategia funcionó con más del 90% de mi equipo, incluido mi jefe. Desafortunadamente, puede encontrar uno o dos tipos que son completamente tercos y se negarán a ver nada a su manera. En ese punto, tienes pocas opciones:

1. Puedes intentar obtener un rango (terminé yendo a mi jefe y pidiéndole un rango porque estaba muy cansado de estos argumentos sin salida)
2. Puede intentar presionar para que la mayoría del equipo lo apoye.
3. Si el proyecto puede permitirse (es decir, no demasiada pérdida de productividad), lo que en su opinión es una mala decisión, deje que la otra persona gane el argumento. Sucederá una de dos cosas:
   • En algunos casos (con suerte, una porción muy pequeña), su intuición estará equivocada y terminará aprendiendo algo. Bien por usted.
   • En la mayoría de los casos (de nuevo ... con suerte), usted Y la persona que defendía el diseño "malo" se darán cuenta exactamente por qué es malo; después de todo, la retrospectiva es siempre 20/20. Con suerte, esta será una lección para esa persona que posiblemente sepa de lo que está hablando y la próxima vez que lo piense dos veces argumentando su caso.

Bueno, esta respuesta no es realmente tan específica para la programación como podrías pensar. Tienes que devolverlo a las cosas que sí entienden.

Si se trata de algo así como la composición sobre la herencia, probablemente solo tenga que decir que actualmente quizás el 90% de los desarrolladores consideraría que es una mejor práctica (una suposición descabellada, basada en parte en el hecho de que el 100% de los desarrolladores están de acuerdo en casi nada), y usted de acuerdo y estaría encantado de averiguar por qué.

Intento ser lo más honesto posible sobre lo controvertido y el porcentaje de desarrolladores que estarán de acuerdo conmigo.

En general, esto funciona mejor con la administración que los desarrolladores, quienes probablemente lo obligarán a explicar si realmente está abogando por un buen diseño y cómo lo sabe. Hay algo digno de elogio en esto, pero significa que debes dedicar mucho tiempo. A menos que confíen en ti lo suficiente como para tomar tu palabra para tales cosas, al menos provisionalmente. En el lado bueno, pueden convencerte de que estás equivocado, lo que supera la realidad fría y dura que te convence en el futuro.

Para cosas como que un diseño sea más comprobable, si no están de acuerdo en que es más comprobable, entonces es más o menos lo mismo que el primer ejemplo. Si no están de acuerdo en que es deseable ser más comprobable, entonces debe volver a las cosas que entienden. Lo más probable es que se trate de gestión, y puede hablar de costos de desarrollo más bajos a largo plazo, menos QA, procesos más predecibles (ya que la duración de los ciclos repetidos de QA es difícil de predecir), etc.

Creo que parte del problema es que usted subestima lo difícil que es lograr que un equipo esté de acuerdo con usted en algo controvertido, incluso si es correcto (y, por supuesto, puede que no lo sea). La programación es en parte un ejercicio sociológico y es posible que necesite programar un tiempo para atravesar algunas de esas madrigueras de conejos, ya que un gran diseño que nadie entiende o se queda atrás rara vez es un gran diseño en la práctica. Así que no piense que ese tiempo se desperdicia, piense que es una parte necesaria del éxito de su proyecto. Aunque sería mucho más fácil si pudieras omitirlo de alguna manera.

Ser la única voz de cambio nunca es una cosa fácil. El primer desafío generalmente es conseguir que otras personas se unan a usted (con suerte, hay algunos en su empresa que son más abiertos que el resto). Si puede llamar la atención de un par de otros desarrolladores / gerentes senior para unirse a su cruzada, esas voces combinadas serán cada vez más difíciles de ignorar para el resto.

Creo que una buena manera de explicar a las personas es proporcionar ejemplos concretos de errores pasados ​​cometidos en proyectos en los que han participado activamente (por ejemplo, "¿Alguna vez ha intentado depurar esto? Ha sido así durante años y nadie sabe cómo hacerlo". arreglalo.."). Mejor aún, aplicar esas 'nuevas' ideas y principios de diseño a un proyecto pequeño / de prueba y poder mostrar cuán exitoso ha sido al final.

Dependiendo de las actitudes de los demás en su empresa, el cambio puede ocurrir rápidamente, o puede ser como tratar de nadar a través de la melaza. Algunos gerentes son completamente inamovibles a menos que tengan estadísticas / pruebas sólidas frente a ellos, mientras que otros están muy interesados ​​en mantenerse al día con las últimas ideas.

Es posible que deba probar diferentes tácticas dependiendo de con quién esté tratando; Sugerir que se podría ahorrar dinero / tiempo / esfuerzo y mejorar la calidad es una buena manera de llamar la atención de los gerentes no técnicos; y la promesa de pruebas automáticas sencillas atrae a muchos desarrolladores que generalmente no pueden soportar pasar días revisando las mismas hojas de cálculo de prueba repetidamente.

Depende de la audiencia! Como desarrolladores, desarrollamos una intuición para el código bueno y malo, y usamos términos emocionales vagos como "olor a código", "código feo", "solución hermosa". Esto solo funciona cuando se comunica con otros desarrolladores con la misma mentalidad. Trate de explicarle a su CEO no técnico que debe invertir x horas hombre para hacer que un código sea "más hermoso", lo más probable es que falle espectacularmente.

Debe poder argumentar que cualquier mejora de diseño dada

• ahorrar dinero para la empresa
• ganar dinero para la empresa

Por ejemplo, ¿cuál es el caso para adherirse al principio de responsabilidad única? Si cada clase tiene una responsabilidad única, hace que sea mucho más fácil localizar y corregir errores, y facilita agregar funciones y mejoras. Menos tiempo arreglando errores y agregando funciones = dinero ahorrado.