code review - que - Revisión de código en la academia
code review tools (10)
Soy un estudiante de doctorado en ingeniería mecánica sin una amplia experiencia en informática. Escribimos código como parte de nuestra investigación, pero por lo general es de alto nivel (por ejemplo, Matlab) y, a menudo bastante ad-hoc.
Parece que las revisiones de código entre los académicos aquí serían valiosas para (a) técnicas de aprendizaje de otras personas, y (b) para detectar deficiencias en su código. (¡A veces pienso que da miedo que se publiquen documentos en los que se ejemplifica la teoría en un código que nadie más que el autor haya visto alguna vez!). ¿Deben los académicos tener revisiones obligatorias de códigos con sus pares? (¿Alguien ha visto algo así antes?)
Más importante aún, ¿cuánto tiempo lleva hacer una revisión efectiva del código en este contexto? Parece difícil justificar el tiempo extra cuando ese recurso en particular siempre es muy escaso.
Addendum: Un par de personas han preguntado si la "publicación" constituye una revisión suficiente. No, en absoluto, en mi campo. Los resultados son la parte importante, por lo que si escribe su algoritmo y / o análisis de datos con un código incomprensible que escupe un gráfico después de horas de procesamiento, no es diferente de un código limpio, compartible y rápido.
Puede escribir código defectuoso que produzca resultados que se vean bien y nunca sepas que hay un error allí.
Pero creo que sería una gran idea tener publicaciones distribuidas electrónicamente junto con el código que se usó para producir los resultados en el manuscrito. El problema, una vez más, es el tiempo: el código de todos es feo y no se puede mantener (para generalizar, después de todo somos ingenieros, no programadores), por lo que limpiarlo para su publicación llevaría demasiado tiempo. Las revisiones de código pueden ayudar a esta situación, un poco.
En lugar de ir directamente a las revisiones de código, podría ser una buena idea probar algún tipo de analizador de código. Algo como FindBugs es excelente para señalar problemas flagrantes que tienden a existir en el código de "prueba de concepto".
Escriba un código mejor la primera vez, aunque solo sea para que sea más fácil revisar el código usted mismo meses después. Colabore con científicos e ingenieros de ideas afines que crean en escribir un buen código. Enorgullézcase de su código y recuerde que una de las razones por las que escapé del código de máquina e inventé idiomas de alto nivel fue para comunicarme mejor con otros humanos. No sirve de mucho si alguien más no puede entender sus métodos, especialmente en el mundo académico, donde la repetibilidad de los resultados de otros investigadores es tan importante.
La duración del tiempo de revisión del código depende de:
- Longitud del código
- Complejidad del código
- Habilidad del revisor
por lo que es difícil cuantificar exactamente cuánto tiempo llevará. Conozco a algunas personas donde trabajo que pueden revisar ~ 400loc / h, pero varios proyectos han puesto un tope a la velocidad loc / h máxima en 200 ya que sienten que ir más rápido reduce la calidad de la revisión del código.
Además, las revisiones de código se realizan con mayor frecuencia frente a un estándar de codificación, ya que la revisión es para garantizar que cumpla con el estándar. Una revisión de código no es un lugar para rediseñar el código, por lo que si no tiene un estándar de codificación, entonces las revisiones de código son difíciles de implementar.
Mi consejo es tener 1 o 2 sesiones y ver cómo lo manejan el equipo / compañeros. La respuesta a "¿es efectivo?" Es que básicamente depende de las personas.
He estado en muchas revisiones donde la gente que revisa no se tomó el tiempo de sentarse y rastrear el código. Muchas veces las personas simplemente pasan por alto la fuente y escriben los errores de ortografía y el tipo de "defectos" de "necesita comentarios aquí". Si bien esta información es buena, no ayuda mucho a las razones que mencionaste anteriormente.
Tenga en cuenta que también he estado en revisiones que fueron muy productivas.
Mi último consejo es revisar pequeñas secciones de código a la vez. Enviar una revisión para el proyecto completo no arrojará los resultados que espera. La mayoría de las personas se cansarán cuando revisen una gran cantidad de código y empiecen a revisarlo solo para superarlo todo.
En mi última posición, lo que funcionó mejor fue la revisión improvisada de códigos. Entonces, si tengo una sección de código que acabo de terminar, llamo a otro desarrollador para que mire antes de verificar cualquier cosa en nuestra rama de control de código fuente. Nada formal, solo una mirada rápida para que alguien más sepa lo que se decidió con el código.
Supongo que hay una gran diferencia: los académicos y los desarrolladores de software trabajan juntos de maneras muy diferentes.
Las revisiones de código generalmente se hacen como parte de un equipo con una agenda común. Nos pagan si la aplicación se vende. Está en el interés de todos que entiendan todo el código y que el código sea lo mejor posible.
Los académicos tienen una agenda muy diferente: estoy seguro de que conoces al menos un estudiante de doctorado que ha sido frustrado constantemente por alguien de alto rango porque contradice su trabajo de hace 20 años (la mayoría de los universitarios parecen hacer esto mucho).
Como estudiante, es posible que deba elegir con quién revisar cuidadosamente y no tendrán un interés automático en mejorar su código.
Las revisiones de código no (a menudo) corrigen errores, o realmente validan el código. Simplemente comparten su comprensión y proporcionan comentarios.
Si su código funciona, pero lamentablemente es ineficiente, ¿es eso un problema? Si es una pesadilla mantener, mal documentada e inviable, ¿eso importa si realmente funciona?
Hasta cierto punto, creo que el código ad-hoc puede ser la herramienta adecuada para el trabajo, si ese trabajo no es el desarrollo profesional de software. Hay cosas que hice con Matlab (durante mi licenciatura en matemáticas) que no soñaría hacer ahora, pero el código que escribo ahora es compartido por mi equipo y revisado regularmente, el código que escribí entonces no ha sido visto desde que graduado.
Suponiendo que su grupo de revisores conoce el idioma en el que está escribiendo y entiende las fórmulas / matemáticas que está usando, generalmente no lleva demasiado tiempo. Hay estudios publicados y citas sobre cosas tales como la cantidad de líneas de código para revisar por hora y otras estadísticas similares, pero se necesita más tiempo para revisar el código que hace un montón de matemáticas que para hacer algo menos intensivo en matemáticas, particularmente si está transfiriendo sus propias funciones a X o Y.
Cuando estaba en la escuela, no hacíamos revisiones de código (excepto cuando nos quedamos perplejos, y luego solo para encontrar el error) pero sin duda habría sido bueno tener en mis ojos más código.
Al hacer revisiones de código, mi equipo normalmente les proporcionaba el código a los revisores un par de días antes (dependiendo del volumen de código) y lo dividía un poco en fragmentos que se agrupaban lógicamente si había MUCHO código. ) y deje que los revisores lo revisen. Luego nos encontraríamos por una hora más o menos y repasaremos los hallazgos. Hay muchas formas de hacerlo, pero eso funcionó razonablemente bien para nosotros.
Supongo que me sorprendió un poco que ya no había algo como esto en su lugar.
¿No son todos los artículos de investigación revisados por pares antes de la publicación? Y la investigación en sí misma, ¿no hay alguna forma de mentor? (No conozco el término adecuado, no estoy en la academia ...)
Entonces, ¿por qué no incluye la revisión de código también? La revisión por pares del trabajo de investigación también debería ser una revisión del código. (La verdad, pocas personas saben cómo realizar una revisión efectiva del código, pero ese es un problema diferente ...)
Para aclarar, asumí que la revisión por pares (¿antes de la publicación?) Verificará todas las suposiciones, confirmará las conclusiones, validará los rastros de datos, etc.
Parte de la validación de los rastros de datos (y, por lo tanto, la validez de las conclusiones de esos datos), debe ser examinar el programa que procesa o genera esos datos. Por lo tanto, la revisión del código es algo necesario ...
Mi formación es como académico de física en un campo no computacionalmente intensivo.
La mentalidad en la programación académica es que el documento revisado por pares proporciona una descripción del algoritmo que se utiliza para procesar los datos. Esto puede ser puro modelado, ajuste de datos con alguna forma funcional o algún otro tipo de procesamiento. Se supone que el autor ha implementado competentemente los algoritmos que describieron. Un crítico entusiasta puede intentar repetir parte del análisis (pero me imagino que esto es raro).
En general, esperaría ver la validación de la acción de un programa en un documento probando con datos sintéticos, o una comparación con un resultado analítico conocido (simple), si el programa era central para el trabajo o la novela.
Pensando en los grupos en los que trabajé no habrían sido muchas las personas (algunas cercanas a una) que hubieran podido hacer una revisión útil del código. En un grupo de simulación, varias personas trabajarían en el mismo código y bien podrían estar desarrollando una nueva metodología a medida que avancen.
La calidad del código no suele ser una gran preocupación en la Academia. Por lo general, el único consumidor del código es el investigador, por lo que la estabilidad y la facilidad de uso son menos importantes que simplemente hacer el trabajo. Además, el código de investigación es necesariamente experimental y las especificaciones cambian cada vez más drásticamente que con otros tipos de código, por lo que el código final tendrá numerosos cambios injertados en él.
Pero creo que el factor más importante es simplemente que los académicos no se consideran programadores profesionales, la programación es solo una pequeña parte de su trabajo. Como resultado, simplemente no existe el nivel de cuidado o pasión que sería capaz de mantener un proceso de revisión de código.
Después de pasar un poco de tiempo en el mundo académico, me he dado cuenta de que gran parte del código producido es solo código para hacer el trabajo.
El código generalmente es pirateado por una persona para probar cualquier hipótesis que se esté probando. Mientras que en la industria, el código se produce en equipos pequeños, y el mantenimiento es un factor importante.
A menos que el revisor esté familiarizado con la base del código, y la cantidad de código sea muy pequeña (¿Un par de miles de líneas?) La revisión del código requerirá mucho tiempo o no será muy estricta.
Pasé un día revisando un programa de 5000 líneas que un colega había escrito y sí, encontré bastantes problemas, pero diría que no estaría dispuesto a hacerlo con demasiada frecuencia. En mi experiencia, la revisión de código funciona mejor en piezas que evalúan elementos de funcionalidad en lugar de una aplicación como un todo.
Para ser honesto, la revisión del código sí se hace correctamente sería una bendición para la academia, sin embargo, las posibilidades de encontrar a alguien con tiempo suficiente para revisar su código son escasas en el mundo académico ya que todos intentan hacer su propio proyecto lo más rápido posible. En esencia, el entorno de la academia no es realmente propicio para la revisión del código.
Y obtener pasantes de pregrado para hacerlo es estúpido, idealmente una revisión de código debe ser realizada por alguien con más experiencia en desarrollo de software que su estudiante promedio. Entonces, a menos que la estudiante tenga un talento extraordinario, es probable que no obtenga muchos beneficios de la revisión de su código.