Un poco de historia: soy uno de los dos programadores para nuestro departamento de 10 personas (el resto son artistas y gerentes). Los dos hacemos toda la codificación necesaria para que las cosas fluyan bien y desarrollamos cualquier proyecto que surja. He estado programando durante unos 4 años, donde este es su primer trabajo "real" (como él lo dice). Generalmente estamos trabajando en diferentes proyectos en cualquier momento.
Hace un par de meses desarrollé un conjunto (de ninguna manera perfecto) de clases que se utilizarían para un proyecto posterior. Se le delegó una gran parte de ese proyecto (por razones de facturación) para diseñar y programar una interfaz GUI. Como era nuevo, ayudé un poco con el diseño y le dije que pidiera ayuda si la necesitaba con el resto. Terminó la interfaz hace unas semanas, que demostró para demostrar que funcionaba, aunque un poco lento.
La siguiente parte de ese proyecto ha comenzado, en la que estoy trabajando. Abrí la interfaz para comenzar con los siguientes pasos, e inmediatamente me encontré con problemas (un poco lento fue un poco de eufemismo, errores en acciones comunes, etc.). Busqué en el código algunos problemas y estoy encontrando O(n^n)llamadas que deberían ser O(n), escriba suposiciones sin verificación de errores (está en Python), referencias a la GUI agregada al código original, y así sucesivamente.
Ahora, definitivamente me gustaría enseñarle lo que estaba mal y cómo solucionarlo, pero ya pasó a su próximo proyecto, y esto fue hace unas semanas. Me temo que digo "¡Vuelve y hazlo bien!" (con ayuda, por supuesto) es demasiado duro, y todavía tenemos otros proyectos por hacer mientras tanto. ¿Debo arreglar el código yo mismo por ahora e intentar atrapar cosas en el futuro?
fuente
O(n^n)menos que simplemente no haya otra manera. Si lo hacen, entonces probablemente obtuvieron una C en algoritmos o no la tomaron o tuvieron un profesor horrible. Sería bueno aprovechar algún tipo de herramienta para ayudar a encontrar problemas comunes. ¿Quizás como la próxima tarea este tipo puede escribir algunas pruebas de rendimiento?Respuestas:
Parece que instituir algún tipo de política de revisión de código podría ser beneficioso en múltiples niveles. Algunos beneficios inmediatos:
Ahora, cuando continúe y comience a limpiar su código, úselo como un ejercicio de enseñanza cuando busque una revisión de este código. Hará que revisen sus cosas, y puede que aprenda cómo hacerlo mejor la próxima vez.
fuente
Nunca nunca arregles su código, de lo contrario no aprenderán nada más que si cometen errores, los atraparás y los arreglarás. La tarea no se realiza hasta que se hace . Tuve mucha suerte cuando comencé profesionalmente y mi supervisor directo volvió a verificar todo lo que había cometido, y si había una solución mejor o si había cometido un error tonto me lo diría, lo que significaba que mis habilidades mejoraron, lo que significaba que mejoré más rápido y desarrollé Una piel más dura.
Dejarlo deslizar generará malos hábitos, corregirlo ahora los ayudará a enfrentar mejor las críticas y a verificar tres veces antes de afirmar que está hecho.
fuente
¿Podemos inferir que el proyecto "funciona" y se realizó en un período de tiempo razonable (aunque con algunos problemas de diseño atroces pero reparables)? Si es así, está en una forma mucho mejor que muchos proyectos que he visto a lo largo de los años.
Creo que una mayor comunicación ayudaría a su equipo, y esto podría hacerse con una revisión regular del código.
Es bueno que seas sensible a ser "demasiado duro" y creo que tendrás en cuenta que la revisión de códigos no tiene que ser una experiencia desmoralizadora en la que los jóvenes se sometan a escrutinio y escrutinio. También puede ser una forma para que los desarrolladores senior demuestren buenas prácticas y para que todos ganen confianza unos en otros siendo amables y amigables incluso en presencia de "errores".
Las personas aprenden bien cuando ven cómo se ven las cosas realmente buenas. Esto es mejor que señalar sistemáticamente cada pequeño defecto. El O (n ^ n), sin embargo, debe señalarse de manera suave y constructiva.
fuente
Comparte tu conocimiento.
Le ofrecería ayuda en su nuevo proyecto a cambio de algunas enseñanzas de un senior a un junior.
¿Por qué no emparejar la programación en ambos proyectos?
fuente