Tratar con compañeros de trabajo durante el desarrollo, necesita asesoramiento [cerrado]

Desarrollé nuestra arquitectura de proyecto actual y comencé a desarrollarla por mi cuenta (llegando a algo así como revision 40) .

Estamos desarrollando un marco de enrutamiento de metro simple y mi diseño parecía estar muy bien: varios modelos principales, vistas correspondientes, lógica principal y estructuras de datos se modelaron "como deberían ser" y se separaron completamente de la representación, también se implementó la parte algorítmica aparte de los modelos principales y tenía un número menor de puntos de intersección.

Yo llamaría a ese diseño escalable, personalizable, fácil de implementar, interactuando principalmente en base a la "interacción de la caja negra" y, bueno, muy agradable.

Ahora, lo que se hizo:

• Comencé algunas implementaciones de las interfaces correspondientes, porté algunas bibliotecas convenientes y escribí apéndices de implementación para algunas partes de la aplicación.
• Tenía el documento que describe el estilo de codificación y ejemplos del uso de ese estilo de codificación (mi propio código escrito).
• Forcé el uso de C++técnicas de desarrollo más o menos modernas , incluido el no-deletecódigo (envuelto mediante punteros inteligentes), etc.
• Documenté el propósito de las implementaciones de interfaz concretas y cómo deberían usarse.
• Pruebas unitarias (principalmente, pruebas de integración, porque no había mucho código "real") y un conjunto de simulacros para todas las abstracciones centrales.

Estuve ausente por 12 días .

¿Qué tenemos ahora? (El proyecto fue desarrollado por otros 4 miembros del equipo):

• 3 estilos de codificación diferentes en todo el proyecto (supongo, dos de ellos acordaron usar el mismo estilo :) , lo mismo se aplica al nombramiento de nuestras abstracciones (por ejemplo CommonPathData.h, SubwaySchemeStructures.h) , que son básicamente encabezados que declaran algunas estructuras de datos.
• Absoluta falta de documentación para las partes implementadas recientemente.
• Lo que podría llamar recientemente single-purpose-abstractionahora maneja al menos 2 tipos diferentes de eventos, tiene un acoplamiento estrecho con otras partes, etc.
• La mitad de las interfaces utilizadas ahora contienen variables miembro (sic!).
• Uso de puntero sin procesar en casi todas partes.
• Pruebas unitarias deshabilitadas, porque " (Rev.57) They are unnecessary for this project".
• ... (eso probablemente no sea todo) .

La historia de commit muestra que mi diseño fue interpretado como una exageración y la gente comenzó a combinarlo con bicicletas personales y ruedas reimplementadas y luego tuvo problemas para integrar fragmentos de código.

Ahora, el proyecto todavía hace solo una pequeña cantidad de lo que tiene que hacer, tenemos graves problemas de integración, supongo que hay pérdidas de memoria.

¿Hay algo posible que hacer en este caso?

Me doy cuenta de que todos mis esfuerzos no tuvieron ningún beneficio, pero la fecha límite es muy pronto y tenemos que hacer algo. ¿Alguien tuvo una situación similar?

Básicamente pensé que un buen comienzo (bueno, hice todo lo que pude) para el proyecto probablemente conduciría a algo bueno, sin embargo, entiendo que estoy equivocado.

¡Refactoriza sin piedad para salir del desastre!

Tome el estilo de codificación que representa la mayor parte del estilo utilizable y úselo para este proyecto.

Lo peor es que tiene que volver a la revisión 40, y sus programadores tuvieron una sesión de capacitación de 12 días, que les dio una mejor comprensión del tema.

Si sus programadores tienen tanto que aprender sobre la codificación limpia, los doce días son la menor demora que tendrá.

Parafraseando su pregunta: "Me fui por un par de semanas y no estoy de acuerdo con lo que hizo mi equipo cuando me fui, ¿cómo hago para que hagan lo que quiero cuando no estoy aquí?"

Les digo que esto no es un problema técnico, es un problema de gestión. Mi opinión (perdóneme si me equivoco) es que usted dicta la solución técnica a un ejército de secuaces, que por alguna razón no pueden o no están de acuerdo o entienden su solución.

Si 12 días es todo lo que se necesitó para hacer tanto daño a su diseño, debe haber una razón. ¿El diseño es frágil? ¿Está sobre diseñado? ¿O el equipo lo hizo por despecho? ¿Cómo son sus plazos y entregas? ¿Apretado? ¿solo intentaban conocer a uno?

En un caso, he visto que el líder técnico estaba tan por delante del juego que el desarrollador promedio (yo) no podía seguir el ritmo. El líder técnico no pudo diseñar un código comercialmente viable, ya que él era el único que podía mantenerlo. Si un desarrollador graduado no puede mantenerlo, es demasiado complejo para el mundo comercial. En todos los demás casos, era simplemente la falta de habilidades de gestión de personas en el lado de gestión.

La dinámica del equipo está rota. Puede (según lo sugerido por otros) pasar tiempo refactorizando el desorden y tener que volver a hacerlo todo la próxima vez que se vaya. Es posible que necesite mejorar las habilidades de los miembros de su equipo, pero creo que primero debe corregir la dinámica del equipo, ya que parecen tener suficientes habilidades para hacer el trabajo, sin importar cuán feo cree que sea.

Par.

Lo que estás describiendo es hacerlo bien, técnicamente, solo . Sí, trató de documentar, trató de imponer estándares, pero (aparentemente) no pudo comunicarse.

Bueno, su equipo acaba de comunicarse con usted, de manera bastante rotunda. Dijeron: "Oye, Yippie, ¡no te estás comunicando!" La forma más poderosa de comunicación que conozco es el emparejamiento. Par. Hasta que lo consigan, o hasta que lo convenzan de hacerlo de otra manera.

Como Brooks nos dijo durante los últimos 30 años, la integridad conceptual es la parte más importante de cualquier proyecto. Para cualquier subsistema completo y no trivial debe haber exactamente una persona, responsable de su diseño y con autoridad para dirigir su implementación. Algo salió mal con esta parte en su proyecto. Sea lo que sea, la única solución es revertir el código en el repositorio que existía antes de que eso sucediera. Una pérdida de 12 días no es nada en comparación con los gastos de mantener un diseño roto. También pensaría en las formas de eliminar a las personas involucradas en este resumen de un trabajo posterior en el proyecto, ya que demostraron ser incompetentes.

Una cosa que haría para empezar es obtener una buena herramienta de revisión de código, usarla para marcar el código incorrecto y documentar por qué es malo y (conceptualmente) cómo debe hacerse. Ahora, por lo que entendí, se han hecho muchas cosas malas, por lo que sería mucho trabajo revisar; Suponiendo que usted es el único que ve algo mal con el código, puede que no sea factible revisar todo usted mismo. Pero puede marcar los peores delitos y convertirlos en entradas en su sistema de seguimiento de problemas, asignado a la persona que escribió el código correspondiente.

El mejor incentivo para escribir código de calidad es saber que si no lo hace, lo perseguirá en el futuro. A sus compañeros de trabajo no parece importarles eso, por lo que la mejor medicina es hacer que refactoricen las partes equivocadas y aprendan.

Con el tiempo, puede volver a visitar otras partes del código que son problemáticas y volver a asignarlas al autor original (incorrecto). Después de un tiempo, se darán cuenta de los beneficios de hacer un buen trabajo la primera vez.

Supongo que no considera que una reversión a su versión original sea una opción; en otras palabras, a pesar del código incorrecto que escribieron sus compañeros de trabajo, agregaron alguna funcionalidad y el valor neto de la versión actual es más alto que el original. También supongo que incluso si ese no es el caso, no tienes capital político para hacer esa reversión y hacer que reescriban el código (ya que muy pocas personas en el planeta tienen ese capital). Estas y muchas más son las complejidades de juzgar una situación que no estoy experimentando, pero espero que mis dos centavos me hayan ayudado.

Una cosa que no he visto mencionada, pero que ha surgido recientemente donde trabajo son los problemas de "silos de desarrollador" y "compra".

Al comienzo de mi proyecto actual, terminé diseñando una biblioteca básica básicamente solo. (Al igual que lo has hecho hasta la rev. 40). Luego, cuando lo hice, presenté al resto del equipo y les dije a todos que podían comenzar a usarlo. Lo que sucedió en los meses siguientes fue que la gente siguió implementando las mismas cosas que ya estaban en esta biblioteca en otros lugares. El CTO (que codifica activamente) señala que nunca hubo una aceptación del resto del equipo en la arquitectura / diseño / interfaces públicas de la biblioteca.

Bueno, acabamos de pasar por una reescritura importante de esa biblioteca que posiblemente haya mejorado el diseño general para adaptarse mejor a lo que estamos haciendo actualmente, pero nuevamente un desarrollador tomó la biblioteca como su único proyecto, trabajó en ella durante varias semanas y entonces solo lo presenté. "¡Voila! ¡Aquí está! ¿No es bonito?"

Ahora que tengo que usar la nueva versión y el mismo problema está ahí, odio la forma en que lo hizo. Y dejó de lado las cosas que eran necesarias porque no pudo colaborar con nadie más mientras estaba trabajando en ello. Entonces, nuevamente, estoy comenzando a implementar las mismas cosas en otros lugares y formas de trabajar para lo que necesito hacer.

En pocas palabras: si desea que la calidad del código aumente y sea coherente, le sugiero que reúna a todo el equipo para establecer estándares, estilos, etc. Además, cada vez que alguien construya una pieza fundamental o fundamental de su aplicación, sugeriría que la persona responsable dirija a todo el equipo en el diseño de las clases, etc., de modo que al final del día, todo el equipo tenga que aceptar la arquitectura general de la aplicación. Además, si saben cómo funciona el código de otro miembro del equipo, será menos probable que lo implementen de nuevo de una manera que les funcione.

¿Eres el desarrollador senior (o uno de los desarrolladores senior) en este equipo? Si es así, parece que necesita realizar algunos seminarios de capacitación sobre mejores prácticas. Probablemente debería revertir gran parte del trabajo realizado, celebrar una reunión con su equipo y explicar la forma correcta de implementar la funcionalidad requerida de una manera que mantenga el diseño existente.

Dado que se enfrenta a una fecha límite ajustada, es posible que deba enviar el código tal como está y refactorizar (¿reescribir?) Después de su lanzamiento.

También parece que necesita definir y aplicar algunas prácticas de código comunes. ¿Tiene un proceso de revisión de código en su trabajo? Si no, parece que ahora es el momento de implementar uno. Las revisiones de código son, por cierto, una excelente manera de enseñar a los nuevos desarrolladores las mejores prácticas.

EDITAR:

Me encontré con una situación similar recientemente. La gerencia de mi empresa insistió en que usáramos desarrolladores por contrato para escribir gran parte de nuestra aplicación. El código que produjeron fue horrible (por decirlo amablemente), pero nos vimos obligados a usarlo. A partir de hoy, he reescrito el 80% del código que los contratistas escribieron para nosotros. Estaba lleno de errores e imposible de ampliar con nuevas características. En un par de meses más, mi equipo lo reescribirá todo, convirtiendo en un desperdicio el dinero invertido en el desarrollo del contrato.

El código incorrecto realmente cuesta dinero, es algo de lo que querrás hablar con tus gerentes, ya que probablemente necesites su ayuda para implementar y aplicar estándares de codificación.

Hiciste un esfuerzo, pero el hecho es que nadie está a cargo . "Pero prefiero mi estilo de codificación", nada de mierda. Me gustaría trabajar en mis proyectos personales todo el día y seguir cobrando.

Con suerte, puede presentar esto a los poderes fácticos y mostrarles lo que podría haberse hecho para oponerse al Wild West Show que se prolongó durante dos semanas. Parece que va a tener que sacar algo por la puerta, pero continúe haciendo un seguimiento del problema de falta de controles y consistencia.

Concéntrese en los pocos que acompañaron su plan y haga todo lo posible para ayudarlos a solucionar este problema y ponerlos en su equipo en proyectos futuros. Es posible que tenga que rechazar el resto si no pueden lograrlo.