Qué hacer cuando su compañero de trabajo no entiende el diseño que intenta mantenerse [cerrado]

Un proyecto de software en el que estoy trabajando me involucra a mí y a otro programador. El proyecto involucró un motor de backend con un MVC front end. Inicialmente hice mucho trabajo en el proyecto y, por lo tanto, configuré algunas metodologías de diseño simples, principalmente sobre abstracción y estrategia de plantilla.

Durante bastante tiempo he estado fuera del motor y trabajando en el sitio web. Sin embargo, todavía he mantenido un interés en el motor, ya que me informaron que podría volver a utilizarlo en algún momento.

El proyecto se encuentra dentro de un plazo muy ajustado, por lo que todos estamos apresurados para terminarlo tanto en la parte delantera como en la trasera.

No me considero un gran programador y, por lo tanto, nunca trato de imponer un diseño particular o un conjunto de metodologías en las personas, ya que no siempre estoy seguro de tener razón y me gusta que otras personas ofrezcan sus opiniones para intentar proponer mejores soluciones. Sin embargo, he notado cambios en este código del motor que realmente me está molestando. Cuando me enfrenté al desarrollador para sugerirle que hiciera el trabajo de otra manera, dijo que no veía el punto ya que parecía haber poco beneficio teniendo en cuenta los plazos ajustados.

Tuve que tratar de explicar que el truco que había puesto podría significar un mayor desarrollo después del lanzamiento y no pensé que fuera justo hacer que otros recogieran la holgura cuando pudiéramos solucionarlo ahora. Pasé unos 30 minutos repasando lo que había hecho y al final me pidió que escribiera el código para poder copiarlo.

La base de lo que inicialmente había configurado fue:

• Una clase abstracta x
• Una clase abstracta de fábrica para crear instancias concretas de x

Lo que sucedió fue que había puesto un par de afirmaciones que podrían haberse puesto fácilmente como métodos virtuales / abstractos en la clase abstracta y luego implementadas en consecuencia, ya que el nuevo cambio seguía el mismo principio de otros métodos en la clase abstracta.

Esto me parece trivial, sin embargo, ni siquiera podía comprenderlo incluso cuando le mostré las clases involucradas.

Ahora mi pregunta es:

1. ¿Es injusto suponer que debería haber captado este concepto? Me doy cuenta de que tenemos plazos ajustados, pero pensé que era trivial. Se supone que el programador es al menos un nivel intermedio.
2. Esto ha sucedido en varios lugares y siempre he tratado de hacer que cambie, pero parece que no. ¿Debería ignorarlo?
3. Debería plantear este problema en otro lugar, o simplemente chuparlo y cuando vuelva a ponerme en el proyecto, simplemente cambiaré todas estas cosas.

Su parte del proyecto no va a estar terminada, por lo que tendré que volver a ayudarlo. Realmente no quiero también, ya que ha tomado un proyecto con una arquitectura no muy buena, pero está bien y realmente ha puesto un montón de código desordenado que con mucha frecuencia no siguió lo que se intentaba lograr.

Si la pregunta es demasiado vaga o desvergonzada, avíseme e intentaré editar en consecuencia.

EDITADO: Se espera que el proyecto continúe después de la fecha límite inicial ya que ya hay trabajo de seguimiento planificado y trabajo que no encajamos y que se acordó implementar más adelante.

Desde la supervisión de más de 200 desarrolladores en los últimos 25 años, creo que la proporción de desarrolladores que se sienten intuitivamente cómodos con el tipo de abstracciones de diseño de las que está hablando es algo así como un tercio. Mi enfoque ha evolucionado desde esperar arreglar esto con coaching, entrenamiento y estímulo, hasta seguir trabajando en el coaching, etc., pero reconociendo que esta comodidad tiene una calidad innata y que a menudo no se puede cambiar. Me preguntaste si es justo. Creo que lo que no es justo es que su gerencia espere que un miembro del equipo de desarrollo asuma la responsabilidad de esta tensión y el impacto de la misma. Si tienes un líder cerca, intenta explicarles la tensión en SUS términos, no en los tuyos. No se trata del otro desarrollador, se trata de la eficiencia, impacto y riesgo futuros = resultado final y, por lo tanto, una clara responsabilidad de gestión. Busque soluciones organizacionales que exploten sus habilidades relevantes. ¿Puedes asumir más trabajo de orientación de diseño y el otro tipo hace más del acabado? No asuma que todos los desarrolladores no desearían este papel; a muchos desarrolladores les encanta ser buenos para terminar cosas para satisfacer a los clientes rápidamente, y están agradecidos por el hecho de que otra persona proporcione un entorno de diseño de calidad.

A veces no es el concepto, sino el tiempo necesario para asimilarlo. Las personas no obtienen las cosas cuando alguien se las explica rápidamente, pero les da tiempo para buscar las melodías y luego lo conseguirán. A veces toma un poco de tiempo para que el concepto se hunda.

Entiendo que los plazos eran ajustados, y el conocimiento es limitado, lo que puede haber tenido un mayor impacto de lo que quisiera, pero en este caso (y hago suposiciones aquí), ¿lo señaló en un documento de patrón de diseño de fábrica , o lo hizo? solo espera que él entienda tu código agitándolo debajo de su nariz gritando "simplemente no lo entiendes hombre, simplemente no lo entiendes" :)

Incluso podría haber hecho lo mismo: mostrar el código a las personas, esperar que lo comprendan instantáneamente, frustrarse cuando se ven en blanco, ampliarlo en un vano intento de hacer que entiendan, enojarse cuando se confunden aún más, y luego o los apartaré del camino y lo haré yo mismo o me pedirán que me vaya y lo haga yo mismo si soy tan listo. Lo cual es una reacción comprensible a mis pobres intentos como maestra.

Las clases abstractas, las fábricas de clase, no me malinterpretan, pero suena como una artillería para matar un pájaro. Los patrones están ahí para resolver problemas, no para crearlos. Admitiste que el proyecto es de 2 personas.

Sin embargo, lo que su colega está haciendo mal es que no está siguiendo las pautas. Causará un poco de desorden aguas abajo. Si el proyecto se abstrae de todas las formas, entonces debería intentar seguirlo.

No querías forzar el patrón sobre él desde el principio, pero podrías haber tenido una breve discusión sobre algunas de las cosas que hiciste. Bajo las limitaciones de tiempo, dudo que sea capaz de comprender su concepto lo suficiente como para poder implementarlo tan rápido como su 'pirateo'. Desea que él arregle las cosas ahora para evitar que otra persona / usted tenga que arreglarlas más tarde, pero el proyecto no se realizará a tiempo. O no entiende lo que estabas haciendo o siente que tomará demasiado tiempo y no vale la pena arriesgarse a retrasarse.

Hágale saber cuándo se puede completar el proyecto y plantee preocupaciones sobre estas limitaciones en el futuro y la necesidad de tiempo adicional. Tendrá dificultades para que todos lo vean a su manera si el cliente está satisfecho. Puede que no sea correcto, pero es la realidad.

Probablemente no sea un problema técnico, definitivamente no es un problema de programación. Suena como nada más que el debate tradicional de "programación para el futuro posible frente al cumplimiento de los plazos de hoy", que es un caso específico de "No me gusta la forma en que el otro hace su trabajo, quiero que lo haga a mi manera ". Ocurre todos los días en cada lugar de trabajo con más de 1 miembro del personal.

Sus habilidades de gerencia y vendedor serán más importantes que cualquier superioirty técnico en su diseño si quiere "ganar" este.

Sugiero leer libros como "Cómo ganar amigos e influir en las personas" y "De qué color eres paracaidista" y libros de habilidades de otras personas.