Se me ha dado el papel de mejorar el desarrollo en nuestra empresa. Lo primero que quería comenzar era la revisión de códigos, ya que nunca antes se había hecho aquí.

Hay 3 programadores en nuestra empresa. Soy un programador web, mis lenguajes conocidos son principalmente PHP, ActionScript y JavaScript. Los otros 2 desarrolladores escriben aplicaciones internas en VB.net

Hemos estado haciendo revisiones de código durante un par de semanas. Me resulta difícil entender el código VB. Entonces, cuando dicen lo que está haciendo, en su mayor parte, solo tengo que aceptar su palabra.

Si veo algo que se ve mal, explico mi opinión y explico cómo lo abordaría en uno de los idiomas que conozco.

A veces mis sugerencias son bienvenidas, pero muchas veces me dicen cosas como "esta es la mejor manera de hacerlo en este idioma" o "que no se aplica a este idioma" o cosas similares de esa naturaleza.

Esto puede ser cierto, pero sin conocer el idioma no estoy seguro de cómo confirmar o refutar estas afirmaciones.

Sé que una posible solución sería aprender vb para poder hacer mejores revisiones de código. Realmente no tengo ningún interés en aprender vb (especialmente porque tengo una lista de otras tecnologías que estoy tratando de aprender para mis propios proyectos) y me gustaría mantener esto como último recurso, pero es una opción.

Otra idea que se me ocurrió es que ambos tienen interés en C # y yo también. Es relativo a ellos porque es .net y relativo a mí porque es más similar a los idiomas que conozco. Sin embargo, es nuevo para todos nosotros. Pensé en los beneficios de que todos colaboremos en un proyecto de C # .net y revisemos el código de los demás.

Supongo que también existe la posibilidad de contratar a un consultor para que nos brinde algunas revisiones de código.

¿Qué me recomendarías que haga en esta situación?

Sus deseos personales de aprender otras cosas deberían quedar en segundo plano para aprender lo que realmente necesita en este momento para su trabajo. Aprende VB.net. Puede codificar eficazmente el código de revisión que no comprende cuando conoce el idioma en el que se encuentra haciendo muchas preguntas (por lo general, es una señal de que el código no está bien escrito si conoce el idioma y no puede entender qué está haciendo y por qué). Pero sin entender el código, lo mejor que puede hacer es hacer que se lo expliquen y esperar que vean cualquier error a través del proceso de explicación. No es que no haya encontrado errores en mi propio código en una revisión al hacer eso, pero no es la forma más efectiva de revisar el código. La revisión de código ahora es parte de su trabajo, hágala cargo y aprenda lo que necesita aprender para hacerlo de manera efectiva.

Mientras aprende, cuando digan bien que esa no es la forma en que lo hacemos en este idioma, haga que le muestren una fuente que dice que es una buena técnica para usar. Depende de ellos justificarte en una revisión de código, no al revés. También mejorará el idioma una vez que comience a ver esos enlaces.

En realidad, no estoy de acuerdo con todo lo anterior. Con JS / PHP / ActiopnScript, tiene una comprensión fundamental de lo que tiene un lenguaje de programación y cómo funciona. De hecho, diría que hay muchas similitudes entre VB y JS. Sin embargo, ese no es mi punto. Incluso si eres muy competente con el lenguaje, es fácil pasar por alto algo cuando tratas de seguir los procesos de pensamiento de otra persona, por lo que lo que la revisión debe hacer es proporcionar una oportunidad para que el programador explique qué ha hecho y por qué.

Una vez, un amigo describió esto como "La teoría del conserje": al explicar los detalles a alguien, incluso al conserje, el programador expone cualquier debilidad en el código a sí mismo, lo cual es, por supuesto, el objetivo final de la revisión. proceso. Sin embargo, requiere que el código se explique de manera exhaustiva y abierta (las revisiones no funcionan cuando los desarrolladores están a la defensiva).

La versión corta

1. Recuerde que las revisiones de código son una oportunidad para que tanto el revisor como el revisor aprendan.
2. Frase comentarios como una pregunta.
3. No permita que la falta de conocimiento le impida proporcionar comentarios (siempre y cuando esté haciendo el n. ° 2).
4. Evite las "revisiones de preferencias" o al menos trate de dejar en claro que son sus propias preferencias personales y que no necesariamente tienen que estar de acuerdo.
5. Intente enviar parches en lugar de ser un "revisor del código del sillón".

La versión más larga

En primer lugar, recuerde que la revisión de código no es solo una oportunidad para que el repasado aprenda. También es una oportunidad para que el revisor aprenda también. De hecho, he oído hablar de varias organizaciones que hacen que los nuevos programadores comiencen a hacer revisiones de código para que puedan tener una idea del código.

Con esto en mente, hay un consejo de revisión de código que siempre he encontrado útil en general, pero es especialmente pertinente en su posición. Exprese sus comentarios en forma de una pregunta en lugar de una declaración. En otras palabras, en lugar de decir "¡Este código apesta!", Podrías decir "¿Por qué escribiste el código de esta manera en lugar de hacerlo ...?" Esto hace que el proceso de revisión del código sea más agradable y te permite aprender también.

Otro consejo que tengo para ti es que no dejes que tu falta de conocimiento te haga retroceder. Si ve algo que percibe como incorrecto, y recibe una respuesta manual del revisor, no retroceda (al menos no por falta de conocimiento). Recuerde, lo que hace un buen código en un idioma rara vez es diferente de lo que hace un buen código en cualquier otro idioma. Sí, ciertos idiomas tienen modismos diferentes para ayudarlo a escribir un buen código. Pero es importante darse cuenta de que esos modismos son herramientas en lugar de fines en sí mismos.

Después de todo, trate de evitar hacer "revisiones de preferencias". Esto es algo en lo que yo (y muchos otros) tengo que hacer un esfuerzo muy consciente. En otras palabras, trate de evitar hacer revisiones que estén en la línea de "Usted hizo x , pero prefiero y ". Ahora, no hay nada malo en indicar las preferencias, pero debe etiquetarlas claramente como tales y tomar nota de que la otra parte es libre de estar en desacuerdo. Esto es importante, porque la mayoría de las cosas que son diferentes de un idioma a otro entran en esta categoría.

Por último, ¿utilizan un sistema de control de versiones distribuido? Una cosa que podría ayudar es que, en lugar de simplemente señalar lo que está mal con el código, podría volver a escribir el código de la forma en que lo habría escrito, probarlo y luego enviar un parche para ello. Esto ayuda a demostrar que está realmente interesado en mejorar su código y no solo en ser un "revisor del código del sillón" y le brinda la oportunidad de aprender mejor el idioma. Además, generalmente es más fácil estar en desacuerdo con "Creo que deberías hacer esto" que con "Así es como lo habría hecho, y aquí hay un parche si estás de acuerdo". Supongo que no necesariamente necesita un DVCS para esto, pero ciertamente ayuda.

Has perdido el foco en el problema y has encontrado una solución pobre. Se le ha encomendado la tarea de mejorar el desarrollo y su solución es poner a una persona a cargo de la revisión del código (usted mismo) que no entienda el idioma. ¿Quién está revisando tu código? ¿Por qué no pueden revisarse entre sí hasta que aprendes el idioma?

Tiene que haber alguna otra área problemática que podría haber seleccionado para tener una mejora más inmediata. De esta manera, solo te arrojan humo y nada mejora.

Dirigir el nuevo desarrollo a un lenguaje que ninguno de ustedes entienda (C #) tomará mucho tiempo en pagar, especialmente si todos traen consigo sus malos hábitos.

Centrarse en el diseño (eso ha sido mencionado). Si tienen dificultades para mantener el código actual, busque algunas herramientas de refactorización para VB. Muchas de las prácticas básicas son las mismas.

Puede ' revisar la lectura' de cosas que realmente no conoce, pero no puede revisarlas adecuadamente . Soy altamente competente en C, conozco C ++ bastante bien, pero no soñaría con revisar algo en C #.

No creo que tenga que ir tan lejos como para traer un consultor, ya que algunas empresas se especializan en ejecutar su código a través de un montón de pruebas y decirle qué podría estar mal con él.

Aún así, dependería del desarrollador individual que conozca el idioma para interpretar el resultado. Por ejemplo, si un revisor de códigos me criticara por no usar el valor de retorno de printf(), los miraría de manera extraña y cuestionaría su sobriedad, luego preguntaría "Ok, genial, ¿qué puedo hacer cuando no se puede imprimir nada en la consola? ser útil?

Lo que quizás desee considerar es hablar con sus jefes sobre cómo configurar departamentos y líderes de equipo, para que pueda ser efectivo en su dominio, mientras que otra persona es efectiva en su dominio.

Aún así, creo que podría utilizar un tercero para la auditoría. La mayoría de los programadores que valen la pena prestarán atención a las preocupaciones legítimas , incluso si descartan la mitad como falso (como lo haría en mi printf()ejemplo).

Brindar orientación sobre algo que no comprende es similar a que el ciego guíe al ciego, como usted bien sabe.

Un enfoque sería hacer uso de herramientas de pelusa como FxCop y StyleCop que abordarán el frente del análisis estático de la base del código. Esto le proporcionaría un punto de partida para debatir los informes que se generan a partir de las herramientas.

Otro enfoque sería convertir las revisiones de código en revisiones de diseño. Las revisiones de diseño con más frecuencia no descubren problemas mucho antes incluso de que se escriba el código. Si un programador tiene un diseño desde el que puede trabajar, en general es mucho más eficiente en su enfoque y los errores disminuyen debido a esto. Cuando un diseño no existe, se vuelve ad hoc en el enfoque y el código sufre con el aumento del conteo de errores. Detecte los problemas en la revisión del diseño antes de que aparezcan en la revisión del código asegurándose de que cada uno de ustedes tenga un diseño concreto para implementar; UML es tu amigo aquí y las herramientas como umlet son rápidas y rápidas de usar.

La mala noticia es que para participar de manera efectiva en las revisiones de código, tendrá que aprender VB. También será útil usar VB en algún tipo de proyecto (no necesariamente para la producción).

La buena noticia es que una vez que haya hecho esto, algo de lo que haya aprendido aún será útil cuando pase a C #.

La idea que debe tener en todo momento al hacer una revisión por pares es:

"¡SOY EL SIGUIENTE EN MANTENER ESTE CÓDIGO!"

Debe comprenderlo lo suficientemente bien como para poder hacerlo como parte de su preparación para la revisión, y su trabajo es hacer que el programador original esté al tanto de cualquier deficiencia que lo haga más engorroso de lo necesario para comprender el código lo suficientemente bien como para mantenerlo .

Si no puede programar en VB, no puede mantener el código y no está calificado para ser el revisor inter pares.

No debes revisar el código que no entiendes, eso solo molestará a los desarrolladores que tienen que explicar cada cosa extraña que han hecho.

Qué puede hacer elegir / definir pautas de codificación y verificar el código con estas pautas. Cuando algo no cumple con las pautas, puede pedirle una explicación al desarrollador.

Comenzaría por elegir las pautas existentes (no conozco ningún estándar de codificación de VB.net pero google me dio:

• Directrices de codificación de VB .Net
• Sub principal
• Todo en un marco de código

Utilice herramientas similares a stylecop para VB .net

Analice las fuentes con NDepend (tiene reglas sobre complejidad ciclomática, longitudes, profundidades, etc.)

Cuando haya hecho eso, puede decir que el código cumple con los estándares elegidos, no dice nada acerca de que la funcionalidad sea correcta o que el código utilice los principios OOP adecuados. Pero al menos es algo.

Una buena revisión del código trata sobre cosas que requieren que usted comprenda el lenguaje (uso apropiado del lenguaje, API y bibliotecas, estilo, nombres de variables, etc.) y sobre qué tan bien el código resuelve el problema: buenos comentarios, arquitectura adecuada, diseño relevante patrones, considera todos los casos de error, etc. Cuando comienza a hacer revisiones de código, tiende a concentrarse en el primero. Son más fáciles de ver y más fáciles de elegir. (por ejemplo, no me gustan sus nombres de variables. Debería usar nombres de estilo XXXX).

La revisión del código se vuelve más valiosa cuando hay un mayor enfoque en qué tan bien el código resuelve los problemas. Dado que ahora no puede proporcionar tanto valor en la primera área, concéntrese en hacer preguntas y ofrecer consejos sobre la solución del problema, no sobre cómo se hace.

Por supuesto, hay una superposición entre los dos. Conocer VB.NET le permitiría brindarle consejos sobre por qué cierto patrón de diseño no es una buena opción en una situación particular, por ejemplo.

Sobre todo, sé humilde en esta etapa. El proceso de cambio es difícil. Incluso si fueras un gurú de VB.NET, el cambio probablemente no sería fácil. A las personas que no han usado la revisión de código no les gusta al principio. Hacer que otros vean tu código es una experiencia difícil. Se necesita tiempo para ver el valor y la paciencia a su alrededor. Es un gran proceso cuando obtienes el buy-in, pero llevará tiempo.

¿Podría cambiar el enfoque para centrarse más en las pruebas en lugar de mirar el código directamente? No estoy diciendo que abandone las revisiones de código, pero inicialmente puede tener más sentido hacer que esas aplicaciones internas tengan suficientes pruebas que puedan ayudar a decodificar algo de lo que está sucediendo. La idea aquí es que las pruebas también podrían ayudarlo a familiarizarse un poco más con algunas de las funciones. Solo veo esto como una ruta diferente a tomar. La idea aquí es que las revisiones vuelvan más tarde y se puedan hacer en un par de partes, ya que puede valer la pena tener una sesión general / inicial y luego un descanso. Ese descanso será hasta el próximo día o dos para que haya tiempo suficiente para cualquiera que quiera dormir una noche pensando en el código o algo similar antes de volver con preguntas y tener una discusión.

Por supuesto, si ya tienes pruebas, desafortunadamente esto no es tan significativo. El otro pensamiento es dar un ejemplo de dónde afirman que en VB.Net esto se hace de una manera particular, ya que eso puede ayudar a aclarar esta pregunta de una manera que podría imaginar que varía de pequeños estándares de código a parte de El corazón de cómo VB.Net fue construido en cierto sentido.

Incluso si aprende los conceptos básicos de VB, realizar una revisión de código sin conocer todas las características del idioma no le permitirá detectar el uso de características inseguras en el idioma.

Suponga que no sabía que la función input () en Python 2 realmente evaluó la entrada antes de devolverla, para facilitar el análisis de los tipos de entrada que no son cadenas. Entonces el código sería vulnerable a la Ejecución de Código Arbitrario, permitiendo al usuario ingresar algo como __import__('os').execl('/bin/sh', '/bin/sh')en un sistema Linux para convertir el proceso de Python en un shell. En su lugar, raw_input () debe usarse para obtener los datos de entrada no procesados.

Intentar realizar una revisión del código sin conocer todas las características del lenguaje no solo puede evitar que se dé cuenta de una mejor manera de realizar un determinado procedimiento en el idioma; También podría conducir a defectos de seguridad perjudiciales.