Fondo:
Trabajo en un pequeño grupo de desarrolladores web para un proyecto de sitio web. El proyecto está creciendo significativamente y nuestro líder había agregado un nuevo desarrollador. Yo trabajo principalmente en el aspecto de front-end (referente al diseño web), mientras que el resto de los desarrolladores trabajan en el aspecto de back-end (referente a la lógica del proceso del servidor).
Vamos a referirnos al nuevo desarrollador como John. Para empezar, tengo que admitir que mis sentimientos por John ahora son parciales, pero trato de ser lo más neutral posible al describir la situación. Por lo tanto, tome mis declaraciones con pinzas.
John proviene de un entorno de back-end y también ha incursionado en el front-end. Una vez, estaba demasiado ocupado con mi trabajo y John se ofreció a ayudar, a lo que acepté. El producto final fue bastante desordenado y tuve que limpiarlo. Después de eso, le di consejos sobre dónde mejorar y le expliqué cómo funcionaban nuestros estándares. También lo orienté sobre la instalación de un complemento para garantizar que su trabajo cumpliera con los estándares, pero me pidió que lo deshabilitara y dijo que lo usaría más tarde.
Más tarde, lo pusieron a cargo de otro módulo, en el que se ofreció a hacer el front-end nuevamente. Una vez que estuvo hecho, el líder me pidió que revisara su trabajo para asegurar la calidad. El trabajo de John era funcional y funcionaba, pero el código estaba muy desordenado. Sin embargo, el líder estaba lo suficientemente feliz porque funcionó. Me resultó difícil limpiar el desorden, así que me senté con John nuevamente y hablé con él sobre el asunto.
De nuestra discusión, aprendí que su forma de hacer las cosas es más hacia "el fin justifica los medios". Dado que este proyecto es grande, mi forma de hacer las cosas es más para prepararlo para el futuro. Si tuviera que arreglar su trabajo, solo estaría haciendo el doble de trabajo. Además, como se mencionó, nuestro líder no tiene quejas. Entonces, le entregué la responsabilidad de la parte delantera a él por completo.
He discutido este asunto con algunos de mis colegas, y algunos de ellos se quejan de la calidad de su trabajo. No estamos seguros si debemos llevar este asunto a nuestro líder. Por un lado, nuestro líder solo tiene conocimientos técnicos básicos, lo que significa que será difícil explicar este problema. También está teniendo dificultades para equilibrar la calidad y la velocidad en este proyecto.
John no es exactamente un mal hombre, y puedo ver que está haciendo todo lo posible. Pero claramente no está siguiendo nuestro consejo, prefiriendo hacer las cosas a su manera.
Pregunta:
¿He manejado el asunto de la mejor manera posible? Si alguna vez encuentro situaciones similares, ¿cuál es el mejor curso de acción?
¿Debo plantear este asunto a nuestro líder e intentar explicar este problema?
Los estándares de codificación son responsabilidad del líder del equipo. Evite asumir la responsabilidad del código de John a menos que exista un riesgo claro para el equipo.
Resalta un problema potencial, ya que el líder del equipo podría no tener suficiente conocimiento técnico para liderar realmente en esta área. Sin embargo, según la información de su pregunta:
Por lo tanto, es posible que el énfasis del líder del equipo en el código que funciona sea correcto (o al menos defendible) en este caso.
El desarrollo de software siempre implica lograr un equilibrio entre un desarrollo eficiente y un código perfectamente diseñado. El método de John puede ser más "rápido y sucio" de lo que usted prefiere, pero eso no lo hace necesariamente incorrecto. Puede ser que priorizar el desarrollo rápido sobre las pruebas futuras sea la decisión correcta en este momento.
(En algún momento, la calidad del código empeora lo suficiente como para ser simplemente indefendible, pero no está claro a partir de la información que ha proporcionado que el código de John sea realmente tan malo).
Por lo tanto, me inclinaría a dejar la responsabilidad al líder del equipo en este punto. Si su código funciona, déjalo así.
Ciertamente, no reescriba el código de trabajo de John para "arreglarlo".
El código de trabajo no debe reescribirse; esta es una de las reglas fundamentales del desarrollo de software. Puede haber sido mejor probarlo en el futuro, pero dado que el código ya está hecho, solo debe esperar hasta el futuro cuando realmente necesite ser rediseñado (es posible que este futuro nunca llegue).
Solo para aclarar este punto, por "funcionar" quiero decir que el código funcionará en el entorno de producción esperado. Si el código funciona ahora en las pruebas pero no pudo hacer frente al uso esperado en el mundo real, entonces no es realmente un código funcional en este sentido.
Si decide plantearlo al líder del equipo, base la discusión en un tema concreto.
Si realmente hay un problema con el código de John más allá del teórico "no debería hacerse de esta manera", plantéelo sobre la base del problema y sus consecuencias. El líder de su equipo no es técnico, así que haga un caso comercial de que algo debe cambiar.
Por ejemplo, "Nos preocupa que si John continúa con su diseño actual, será necesario mucho más esfuerzo para agregar la característica XYZ que hemos planeado para más adelante", o "Esta funcionalidad de búsqueda puede funcionar ahora en nuestros datos de prueba, pero no crea que escalará al sitio web real donde podría haber millones de resultados de búsqueda".
Si hay problemas genuinos que deben abordarse, intente separar el estilo de la sustancia y concéntrese solo en los problemas reales de funcionalidad.
De esto se trata la Deuda Técnica . Debe asegurarse de que su líder lo entienda en la medida en que lo afecta y evalúe los riesgos en consecuencia. Es triste que su equipo tenga estándares de codificación y un proceso de revisión, pero es casi una pérdida de tiempo ya que su jefe tampoco los sigue. Como resultado, John tampoco.
Solo infórmele al líder que si algún código de John tiene que ser depurado o cambiado para nuevas características, tomará mucho más tiempo corregirlo. Todo el código se pudre, pero esto se va a pudrir a un ritmo más rápido. Si su jefe quiere que esto sea una "oportunidad que tendremos que aprovechar", entonces no hay nada que pueda hacer al respecto.
No se sorprenda si tiene que volver a mencionar esto como el motivo de la demora en la solicitud de un cliente. Su jefe probablemente querrá ignorarlo y contraatacar. Entonces estarás buscando una manera amable de decir: "Te lo dije".
¿Has pensado en revisiones de código?
Las revisiones de código son una práctica estándar en la que solo fusiona su código después de que haya una aceptación general de su calidad, esto generalmente ocurre antes del control de calidad. Esto significará que tanto usted revisará el trabajo de John como John revisará el suyo; por lo general, se encontrará con sorpresas antes de que se fusionen y ayudará al equipo a unirse y entrar en conflictos por cosas menores.
Estoy de acuerdo con su posición, al final, el código debe leerse como si lo escribiera la misma persona, mientras que en la práctica esto es muy difícil, algunas ideas estructurales deben mantenerse.
A juzgar por lo que hiciste, lo hiciste bien.
El problema viene de John, que no quiere entender lo que es bueno en términos de codificación. Sucede mucho y tuve el mismo problema con un colega.
Termino diciéndole que debería dejar de hacer eso, porque me estaba perdiendo tanto tiempo como si lo hubiera hecho yo mismo. Como ya explicaste el problema, lo cual yo no hice, al principio, mi enfoque sería el siguiente:
Es lo que he hecho, simplemente no tenía que atrapar a mi líder de proyecto, pero tal vez tú tengas que hacerlo. No se avergüence, es bueno para todos, especialmente para aquellos 2 que no entienden las cosas principales sobre un código limpio.
MGOwen
usuario51235
usuario45590
usuario51235
usuario45590
Brandín
Remojar
usuario51235
Empleado Técnico