visual-studio - extensions - visual studio code highlight closing tag
¿Cómo se hacen revisiones de código? (13)
Recientemente, me mudé de una empresa con aproximadamente 30 desarrolladores, todos basados en el mismo sitio, a una empresa más pequeña con un total de 6 desarrolladores que trabajan en todo el país.
Anteriormente, cuando estaba realizando revisiones de código, tenía a la persona sentada a mi lado, o iba a su PC y revisaba el código con ellos.
En mi nueva compañía esto no es factible ya que hay gente por todos lados. Me han pasado un par de miles de líneas de código para revisar y no puedo simplemente decirle a alguien mis pensamientos.
La única forma en que puedo pensar es escribir un documento de revisión de código. Así que he recurrido a pegar el código en Word y anotarlo usando las pequeñas burbujas de margen que obtienes.
¿Hay alguna forma más fácil de hacer esto? Durante mucho tiempo pensé que Visual Studio debería tener un sistema de comentarios meta, que le daría características de esquema similares, y le permite escribir comentarios en un nivel superior.
¿Hay alguna herramienta que haga esto? Si no, ¿cómo hacen las personas para hacer revisiones de códigos distribuidos?
En la empresa en la que trabajo, los parches generados a través de SVN se envían diariamente en un grupo de noticias. La revisión del código en vivo sigue siendo la manera más eficiente de completar una revisión, sin embargo, dado que estamos trabajando en equipos virtuales con desarrolladores en todo el mundo, en algún momento es imposible que el desarrollador y el revisor hablen entre sí.
Para ayudar a nuestros desarrolladores a realizar las revisiones, hemos creado una lista de verificación de revisión de código (disponible en: http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31 ).
Nuestro secreto detrás de las revisiones del código: revisión pequeña, revisión a menudo.
Estábamos exactamente en el mismo barco: desarrolladores en todo el país, no había suficiente tiempo de superposición durante el día ... Todos trabajando de forma asíncrona ... Así que tuvimos que idear una herramienta de revisión de código sin conexión.
Terminamos con un proceso razonablemente ligero: para cualquier pieza de código no trivial, una revisión por pares es obligatoria. - Para realizar una revisión, el autor crea una "lista de cambios empaquetada" (verifique su comunidad de control de fuente para tales cosas). Básicamente es un archivo ZIP expandible de un solo archivo de todos los cambios realizados en este pedazo de trabajo. - El autor envía un correo electrónico al revisor con la lista de cambios empaquetada (¡tenga en cuenta que aún no la enviaron!) - El revisor realiza el código de forma asincrónica y los incluye en un correo electrónico - Si el revisor tiene serias objeciones, codifique no está permitido entrar hasta otra ronda de revisiones; de lo contrario, el autor puede registrarse después de corregir las sugerencias O abrir errores para corregir las sugerencias.
Hay una herramienta: http://www.smartbear.com/codecollab.php
Hemos tenido cierto éxito utilizando la función de estante de TFS para hacer revisiones de código distribuido. Con el uso de shelvesets, un desarrollador puede "registrar" un conjunto de cambios sin comprometerlos con la sucursal. Otro desarrollador puede desmantelar el conjunto de cambios y revisar los diffs contra la rama comprometida. Una vez que todos los interesados estén contentos con el conjunto de cambios, están comprometidos con la sucursal.
Le gustaría leer el libro de Smart Bear: Los secretos mejor guardados de la revisión del código de pares
Es gratis (incluido el envío si se encuentra en los EE. UU.) Por lo que hay pocas razones para no obtenerlo. Por otro lado, es un gran librito con ejemplos del mundo real sobre la mejor manera de hacer revisiones de códigos de pares, por lo que hay muchas razones para pedirlo.
Me gustaría que hubiera un mejor soporte para este tipo de tareas integradas en Visual Studio. Sin embargo, hay algunos complementos interesantes que pueden ayudar. Si está utilizando Visual Studio Team System eche un vistazo a TeamReview . Le permite generar elementos de trabajo de revisión de código especiales que pueden ser "reproducidos" posteriormente.
Si es posible, comience con casos de prueba: haga que la persona lo guíe a través de los casos de prueba. Muestra el diseño y lo que el desarrollador pensaba que resolvería el problema (s). Sumérgete en casos de prueba y mira el código.
Además, eche un vistazo a los informes de cobertura de código generados automáticamente a partir de una compilación. Puede ser una buena métrica en las rutas de prueba.
Ahí es donde comenzaría.
Tenemos desarrolladores en todo el mundo. Usamos el colaborador de código de Smart Bear. Al igual que cualquier herramienta, no es perfecta, pero sin duda hace el trabajo. Está basado en la web y es fácil de aprender.
Un proceso muy liviano que hemos estado usando es usar Microsoft SharedView y Skype para tener sesiones de programación de pares y para revisar el código. De acuerdo, no es tan formal como una política de check-in, pero podría ser un buen lugar para comenzar a fin de desarrollar estándares antes de conmemorarlos en una política de check-in.
JIRA tiene la opción de asignar a alguien para revisar el código de su trabajo, él / ella puede hacer comentarios dentro de JIRA.
Vi este proyecto no hace mucho tiempo, quizás se vote si la gente lo usa.
Bueno, te diré lo que hace mi empresa, ya que nos funciona bien (aproximadamente 10 desarrolladores más PM). YMMV.
Hacemos nuestra gestión de cambios usando Subversion y ClearQuest (utilizados para usar ClearCase, buscando eliminar CQ). Hacemos nuestros cambios, creamos archivos de parches usando subversion y luego colocamos el parche en el registro CQ y pasamos el CQ. Baja tecnología, pero funciona. Obviamente, puedes modificarlo para que funcione con la aplicación de ticketing que utilices.
Mira las sugerencias de esta pregunta: