¿Cómo debo arreglar el código de un programador con menos experiencia?

19

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?

code-reviews bug

— TorelTwiddler
fuente

44

En el futuro, ¿existe la posibilidad de acordar pautas de codificación que eviten errores como los que usted describió?

— Benni

55

Es una buena cosa que no estés corriendo de inmediato a la gerencia y contando con él. Algunas empresas están orientadas a la culpa. A medida que revise las soluciones, encuentre una forma de agruparlas y luego haga que este tipo las vea más tarde. Por otro lado, incluso un recién graduado no debería estar codificando nada, a 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?

— Trabajo

Una O (n ^ n) sin documentación de por qué es simplemente incorrecto, punto. Si realmente tiene que hacerlo, los comentarios deberían explicar por qué.

— Loren Pechtel

Estaba a punto de escribir que "oye, O (n * n) no es tan malo, muchas aplicaciones lo requieren ..." pero luego me di cuenta de que no era un signo de multiplicación, sino un asesino ^!

— Max

O (n ^ n) puede ser en una magnitud más rápida que O (n) si O (n) tiene una constante enorme yn es pequeña. codinghorror.com/blog/2007/09/... Por otra parte, n ^ n es extrema: D

— Coder

33

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:

Puede influir directamente en la calidad de su código antes de que se confirme el código, manteniendo así la alta calidad de la base del código
Evita que cometas errores similares que otro par de ojos pueden atrapar
En ausencia de pautas de codificación, las revisiones conducen naturalmente a la coherencia en el estilo de codificación
El intercambio de conocimientos. Si solo hay dos de ustedes y uno es atropellado por un autobús ...

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.

— nithins
fuente

3

La revisión del código de +1 es una excelente manera de hacerlo. Sugeriría redactarlo más a lo largo de las líneas de "¿Te importaría echar un vistazo a los cambios que hice para asegurarme de que no me perdí algo" en lugar de "Estas son las formas en que mejoré tu código".

— Steve Jackson

1

+1 Diría que la revisión de código es mucho mejor que cualquier "pauta de codificación de reglas de oro". No muchas cosas nunca están bien.

— Max

Realmente me gusta esta idea, gracias. ¡Ahora tendré que investigar un poco sobre buenas formas de hacer revisiones de código!

— TorelTwiddler

1

En realidad, hay un documento bueno y entretenido con algunos conceptos básicos disponibles en mumak.net/stuff/your-code-sucks.html . Se trata principalmente de técnicas conductuales para realizar revisiones de manera constructiva, lo cual es muy importante para las revisiones exitosas.

— nithins

@TorelTwiddler, solo recuerda que las revisiones de código son para aprender, no para culpar. Señale las cosas que hizo bien, para que sepa que son buenas al mismo tiempo que sugiere formas de mejorar.

— CaffGeek

5

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.

— Nicholas Smith
fuente

2

¿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.

— Angelo
fuente

0

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?

— Mouviciel
fuente