Al final de mi soga [cerrada]

Soy contratista de una gran empresa. Actualmente, hay tres desarrolladores en el proyecto, incluido yo mismo.

El problema es que los otros 2 desarrolladores realmente no lo entienden. Por "eso" quiero decir lo siguiente:

• No entienden las mejores prácticas para la tecnología que estamos utilizando. Después de 6 meses de que yo y otros les demos ejemplos, se están utilizando terribles antipatrones.
• Son programadores de "copiar y pegar" que producen principalmente código de espagueti.
• Ellos constantemente rompen cosas, la implementación de cambios, pero no hacer una prueba básica de humo para ver si todo está bien
• Se niegan / rara vez piden revisiones de código.
• Se niegan / rara vez hacen cosas básicas como formatear el código.
• No hay documentación sobre ninguna clase (jsdocs)
• Miedo de borrar el código que no hace nada
• Deje bloques de código comentados en todas partes aunque tengamos control de versiones.

Me siento cada vez más frustrado al formatear el código de otros, corregir errores, descubrir funcionalidades que no funcionan y crear abstracciones para eliminar los espaguetis.

Realmente no sé qué hacer. Intento no frustrarme, pero es un desastre. Me gustan estas personas como personas, pero siento que la situación de codificación es tan mala que podría moverme más rápido si simplemente navegaran por la web todo el día.

¿Estaría fuera de lugar pedirle a nuestro gerente que revise los otros svn commit access; los compromisos solo se pueden realizar después de una revisión realizada por alguien que tenga conocimiento de lo que estamos haciendo. Como contratista, no estoy seguro de si esa es la mejor jugada.

¿Hay alguna manera sutil / no tan sutil de dejar en claro cuántas cosas estoy arreglando?

Tengo algo como esto en mi equipo. Intenté que la gente hiciera lo correcto y no funcionó como se esperaba, así que me mudé a una solución diferente.

Primero, fui a mi gerente y llegamos a un acuerdo, ningún código entra en el control de la fuente a menos que esté cubierto por pruebas unitarias. Si el código ingresa sin pruebas unitarias, tengo el poder de veto para deshacer la confirmación de inmediato y hacer un ping a quien sea responsable para que pueda trabajar en las pruebas y luego empujar el código.

Con esta regla, ejecuto regularmente herramientas de cobertura de código (en este caso, jacoco en nuestra compilación sbt ) para asegurarme de que las piezas estén cubiertas correctamente y también realizo refactorizaciones y revisiones de código constantemente en cualquier código introducido por ellas. Como este es un proyecto de Java y Scala , tengo muchas herramientas para ayudarme a atrapar cosas que no deberían estar allí o que no funcionan de la manera que pensamos que deberían, no estoy seguro de cómo puede hacer lo mismo con JavaScript, pero tal vez haya una solución.

Lo principal que creo que me está ayudando a seguir con esto es que tengo una visión clara de lo que espero del proyecto y su arquitectura principal, por lo que cada vez que veo algo que no refleja esta opinión, puedo ir allí y arreglalo. Debe hacer lo mismo, definir su vista, los patrones que se deben usar, la forma en que se debe escribir el código y mantenerse al tanto de esto, siempre haciéndoles saber (y a su administración) lo que está sucediendo y lo que impide que el proyecto avance Más rápido.

Seguramente habrá un momento en el que, o se rinden y hacen lo correcto, o la gerencia recibe el mensaje y los elimina del proyecto.

Estoy seguro de que ya has visto mis comentarios y mi otra publicación, así que no voy a fingir que realmente sé la respuesta. Lo mejor que puedo ofrecer es un resumen de lo que he escuchado / leído de otros y agregar algo de mi propia experiencia a la mezcla.

Primero, quiero decir que hace poco encontré un blog que pertenece a uno de nuestros propios miembros de Programmers SE, Martin Blore e IMO. Esta publicación específica sobre la autorrealización de TDD es muy precisa. TDD es el último nivel más alto que une todo, pero sin los niveles anteriores, especialmente el más grande, los principios y las prácticas para producir código claro y legible, será muy difícil, si no imposible, hacer que TDD funcione.

En mi empresa, la administración nos impuso tanto Agile como TDD, y al principio simplemente los hicimos porque nos dijeron (que es lo contrario de ágil). Hemos probado TDD dos veces y, aunque soy un gran defensor del uso de pruebas automatizadas, personalmente he descartado todas las que el equipo unió en la última versión. Eran frágiles, gigantescos, copiaban / pegaban el wazoo y estaban plagados de declaraciones de sueño que los hacían correr de manera muy lenta e impredecible. Mi consejo para su equipo: NO HAGA TDD ... todavía.

No sé cuál es su situación porque mencionó que ha estado en la empresa durante solo 6 meses y que es un contratista. ¿Sus objetivos a largo plazo son quedarse con esta empresa o se va a acabar el contrato? Le pregunto porque, incluso si hace algo, podría llevar bastante tiempo ver los resultados.

Además, cuando te unes a un equipo, generalmente toma tiempo antes de obtener suficiente credibilidad y respeto de tu equipo, donde ellos (desarrolladores y administración) considerarían cualquier cosa que propongas. En mi experiencia, ayuda si apaga algunos incendios y demuestra que tiene habilidades y conocimientos de los que otros pueden depender. No estoy seguro si 6 meses es suficiente. Con mucha frecuencia, una persona nueva y ambiciosa se uniría al equipo, luego publicaría aquí preguntando cómo pueden cambiar el mundo. La triste realidad es que simplemente no pueden.

Asumiendo que tienes el respeto y la atención de tu equipo. ¿Ahora que?

Primero, tanto la administración como los desarrolladores deben ser conscientes de que hay un problema. La gestión mide los resultados en términos de trabajo entregado. Si están contentos con la cantidad actual y la calidad de las características, entonces la triste realidad es que no escucharán. Como otros han señalado, sin el apoyo de la gerencia, será extremadamente difícil introducir cualquier tipo de cambio.

Una vez que obtenga soporte de administración, el siguiente paso es profundizar e identificar las causas fundamentales de por qué el equipo opera de la manera que lo hace. El siguiente tema es algo que ha sido una búsqueda personal mía desde hace un tiempo. Hasta ahora este ha sido mi viaje:

1. Una vez que tenga el apoyo de la gerencia. Puede comenzar a introducir muchas prácticas / procesos dictados centralmente que MainMa sugirió en respuesta a mi pregunta . Hemos hecho muchos de ellos (excepto la programación emparejada) y definitivamente ve beneficios. Las revisiones de código ayudaron especialmente a estandarizar el estilo, la documentación y también nos permitieron compartir conocimientos / técnicas entre el equipo. A pesar de que se dictaron las revisiones de código, al equipo realmente le gustan y revisamos cada pieza de funcionalidad que se registra. Sin embargo ...
2. Notará que el código que generalmente se escribe todavía está demasiado acoplado, el diseño es malo o carece por completo. Las revisiones de código captan algo de esto, pero hay muchas cosas que puedes reescribir. ¿Por qué el diseño es malo en primer lugar? - A muchos desarrolladores nunca se les presentaron buenas prácticas y nunca se les enseñó formalmente OOD en primer lugar. Mucha gente "simplemente codificó" cualquier tarea que se les asignó.
3. Con el apoyo de la gerencia, puede introducir más procesos, como discutir el diseño antes de que se realice la codificación. Pero solo eres una persona y parece que tan pronto como no prestas atención, el equipo vuelve a lo que siempre ha hecho. ¿Por qué?
4. ¿Se pueden introducir y enseñar mejores prácticas o hábitos para que no tenga que monitorear constantemente? - Resulta que esta parte no es tan fácil.
5. ¿Por qué otros miembros del equipo son reacios a aprender y aprender nuevas prácticas y por qué son tan resistentes a SÓLIDO o SECO cuando se ha escrito tanto en la literatura moderna sobre metodología de software? Con todos los cambios positivos que hemos tenido en mi equipo, hace 2 semanas tuve una discusión en la que refacturé 2 funciones que tenían 15 líneas de código idénticas y el revisor lo llamó heroico, esfuerzo innecesario porque no hay nada de malo en copiar / pegar solo 15 líneas Estoy totalmente en desacuerdo con tales puntos de vista, pero por ahora hemos decidido aceptar estar en desacuerdo. -- ¿Y ahora que? Ahora hemos llegado al tema de mi otra publicación .
6. Como maple_shaft y nikie señalaron en sus respuestas (lo siento, MainMa , obtuviste la mayor cantidad de votos, pero estás a 5 pasos de distancia :)), has llegado a una etapa en la que el "proceso" ya no puede ayudarte a ti ni a nadie en este foro puede decirle cuál es la "solución". El siguiente paso es acercarse a las personas, tal vez uno a uno, tal vez como un equipo, probablemente ambos en un momento u otro y hablar con ellos. Pregúnteles qué funciona y qué no. La única forma de identificar la causa raíz de lo que los impulsa ahora es hablar con ellos individualmente y descubrirlo. Como parte de este paso, recientemente me encontré con un problema de equipo completamente diferente, pero creo que la respuesta de Joel aquí, que es muy detallado y perspicaz, también se aplicaría a este caso. En resumen, si bien el uso de la administración como "correa corta" es un posible enfoque para casi cualquier cosa, debemos recordar que estamos tratando con humanos para entender realmente las motivaciones que tenemos que cruzar más en el psicoanálisis que la administración pura o el liderazgo técnico.
7. Entonces, ¿estás hablando con tus compañeros de equipo? Que les preguntas No estoy seguro de esta próxima parte porque nunca he estado aquí. Aquí hay un posible escenario: P: ¿Cómo es que no hay SÓLIDO? A: no lo necesito. P: Podría ayudar. A: Lo hago bien como está. - de alguna manera, necesita generar una serie de sonidos que salgan de su boca y hagan que el oyente reconozca que las cosas podrían mejorar si le dan una oportunidad a lo que usted está vendiendo. Si fallas aquí, nunca se convencerán de que lo que sea que "haga el proceso" realmente tiene algún valor. Por otro lado, si supera este punto, probablemente encontrará que ya ni siquiera necesita "el proceso".
8. OMI desde la raíz, tus compañeros de equipo no aprenderán si no ven nada malo en sus hábitos / prácticas actuales. Entonces, quizás el siguiente paso en todo esto es encontrar una manera de ilustrar, resaltar los problemas y hacerlos obvios. Después de todo, no estamos escribiendo código legible, utilizando principios SOLID / DRY o manteniendo documentación solo porque nos da una sensación cálida y difusa. Lo hacemos porque produce un código de mejor calidad y, francamente, nos hace codificar más rápido. ¿Se puede medir eso? ¿Quizás aquí es donde entran las métricas de software?
9. Aquí hay una idea loca y no tengo idea de si realmente funcionaría (podría ser una práctica estándar de la industria, o tal vez sea completamente inválida. Lo inventé en las últimas 24 horas), pero estoy muy tentado de traerla. a la mesa tan pronto como comience el próximo año:
   • Contra las opiniones de muchos otros , presente la idea de Autor / Propietario para todos los archivos fuente. Como sugiere The Pragmatic Programmer, esto le dará un sentido de propiedad y responsabilidad a una sola persona que será responsable de un código fuente. No significa que otras personas no puedan modificar el código, todos estamos trabajando en equipo, pero al final del día, la persona que posee el código es responsable de revisar los cambios.
   • Cree un activador de repositorio de origen que supervise todos los registros y busque específicamente aquellos que son correcciones de errores. Conviértalo en un proceso para que cada corrección de errores tenga un identificador de referencia directamente en la descripción del check-in. Ahora escriba un script que analice una lista de archivos que fueron modificados y elimine el "Autor" del bloque de comentarios del encabezado del archivo. Cree una base de datos SQL que rastree el número de defectos registrados por archivo / por proyecto / por autor.
   • Una vez que tenga suficientes estadísticas, con suerte notará que su código tiene menos defectos / cambios que algunos de los otros códigos. Estos son datos duros que puedes usar. Si un solo proyecto tiene una tasa de defectos significativamente superior al promedio, créelo como candidato para el próximo esfuerzo de limpieza / refactorización para pagar parte de la deuda técnica.
   • Si un proyecto o archivo tiene una tasa de defectos significativamente superior al promedio y tiene un propietario, hable uno a uno con esa persona. Pregúnteles, muy cortésmente, sin confrontaciones, qué pueden hacer para abordar esto. Dado que son los propietarios, deben impulsar el cambio, pero ofrecer cualquier ayuda de su parte. Con suerte, el propietario rastreará muchas de las causas de su propio código de espagueti y tan pronto como pidan ayuda, es cuando entra en acción y coloca algo de SÓLIDO.

Le sugiero que hable con su gerente sobre el tema, pero es casi seguro que no querrá revisar cada registro.

En cambio, sugiero que sugiera un conjunto de pruebas de unidad / regresión, que se enganche en SVN y se ejecute para cada registro. Eso al menos te ayudará a evitar construcciones rotas. Puede sugerir gradualmente otras mejores prácticas.

Si resulta ser completamente poco receptivo, tal vez deberías pasar por alto. Si decides hacer eso, deberás traer tu mejor juego. Básicamente estarás lanzando a la gerencia para ser contratado en un nivel superior si haces eso.