Hola estoy trabajando en desarrollo web. Tengo la responsabilidad de la ejecución de un proyecto. Tengo algunos juniors que les delego tareas y lo hacen. Este flujo me parece bien.
Pero cuando miro en el código encuentro algunas cosas que no deberían estar ahí. Algunas prácticas no necesitan estar allí. No soy ningún tipo de codificador ninja, pero puedo reconocer los malos hábitos.
Por mala práctica no me refiero a mal, el código funcionará como se esperaba, pero tengo un TOC y a veces me irrita porque puede limitar el rendimiento de la aplicación.
Tengo dos opciones para abordar esto:
Deje el trabajo como está, dígales que no lo repitan de nuevo, ya que la versión actual funciona bien.
Corregir todo por mí mismo o indicarles que lo corrijan, pero este enfoque llevará algún tiempo y causará un retraso en el proyecto.
¿Qué enfoque debo tomar aquí o hay alguna otra solución para esto?
Configure un documento de estándares de codificación para su equipo, estableciendo lo que es aceptable y lo que no lo es.
Luego, solo permita que el código se fusione con la rama maestra de su repositorio de código fuente después de que ese código se haya sometido a una revisión de código. Puede usar herramientas como StyleCop para hacer cumplir reglas particulares automáticamente, pero sentarse y hacer revisiones de código significa que se verá más agradable dentro de su equipo.
Ya que eres el líder del equipo...
Primero... ¿tenía algún tipo de mejores prácticas de codificación? Si no, el código incorrecto es su culpa.
Segundo... ¿revisas el código, ya sea de manera formal o informal? Si no, entonces el código incorrecto es nuevamente tu culpa.
Tercero... ¿el código es en realidad una mala práctica, o simplemente no es su método preferido para hacer las cosas? Como dijiste, "... porque PUEDE limitar el rendimiento de la aplicación", parece implicar que no está roto, solo que no es como lo quieres.
Independientemente, para responder a su pregunta, NO... usted no realiza los cambios usted mismo. Hable con PM y si hay tiempo y una NECESIDAD real, deje que el desarrollador que escribió el código haga el cambio y explique por qué es necesario. Suenas como el programador 'perfeccionista', así que mira honestamente el código y a ti mismo, y pregúntate si no es solo que quieres que las cosas se hagan a tu manera, o si es un código realmente malo. Tenga en cuenta que criticar el trabajo de alguien simplemente porque no está hecho como lo haría usted es una forma segura de perder su respeto y deseo de escucharlo.
Un buen código y un producto de calidad no es su única responsabilidad de entrega a la empresa; deberías estar enseñando y moviendo a tu equipo también.
La mayoría de los programadores están ansiosos por escribir un buen código y tienen ideas sobre cuál es la mejor manera de hacerlo. No siempre están de acuerdo entre sí en esto. El objetivo no debe ser lograr que lo hagan exactamente como dices; aparte de cualquier otra cosa, indudablemente también puedes aprender de tu equipo.
Por supuesto, desea mantener buenos estándares, y eso incluye que el equipo escriba el código de manera coherente, en lugar de que cada uno haga lo suyo. Como ha mencionado, algunas prácticas son técnicamente mejores que otras, y querrá incluir las buenas en sus pautas.
Esto se puede lograr a través de varias rutas. Yo sugeriría lo siguiente:
Intente en la medida de lo posible actuar como facilitador para que su equipo produzca código de alta calidad. Agradecerán el respeto que esto conlleva.
Si tiene la autoridad, puede establecer pautas para la codificación y pedirles a los jóvenes que se adhieran a ellas.
Si no tiene la autoridad, entonces no puede hacer mucho, puede arreglarlo usted mismo o pedirle al gerente que hable con ellos. Pero si hace esto último, debe tener pautas escritas, no sirve de nada decir que está mal a menos que pueda mostrarles la forma 'correcta' de hacerlo.
Como dijeron los demás, hay un conjunto de buenas prácticas que existen prácticamente para todos los lenguajes/marcos y están documentados en la red y son una herramienta para ayudarlo en la revisión del código.
Si tiene la autoridad pero no las habilidades adecuadas para hacer cumplir un documento adecuado de mejores prácticas, deléguelo a alguien. Prefiero que no se apliquen las mejores prácticas que recibirlas de alguien que no entiende realmente de lo que está hablando, especialmente si se trata de rendimiento .
Por mala práctica no me refiero a mal, el código funcionará como se esperaba, pero tengo un TOC y a veces me irrita porque puede limitar el rendimiento de la aplicación.
¿Se trata sólo de rendimiento?
Si es así, le sugiero que agregue a su proceso de validación una prueba de datos adecuada si aún no la tiene. Por pruebas de datos adecuadas me refiero a datos generados cuyo volumen coincide con la realidad esperada. Si está haciendo, por ejemplo, una aplicación web, ¿podría configurar que cada acción básica tome menos de un segundo, un trabajo nocturno complicado menos de una hora? Si la prueba falla, entonces hay algo que cavar.
Finalmente, si hay alguna pieza especial de código que realmente le parece mal en términos de rendimiento y la prueba de rendimiento de alto nivel no es suficiente para usted, aíslela en una prueba unitaria, ejecútela contra un gran conjunto de datos generado y compruébelo. el resultado.
Is that only about performance ?Probablemente quiere decir algo como usar var myVariable = "abc";en lugar de let myVariable = "abc";o posiblemente algo como mantener los parámetros como una sola línea larga, en lugar de agregar un salto de línea después de cada coma.it irritates me sometimes because it may limit the performance of the appme parece bastante claro.
Kilisi
keshlam
Dhiraj Wakchaure
Mawg dice que reincorpore a Monica