¿Cómo reviso mi propio código? [cerrado]

Estoy trabajando en un proyecto solo y tengo que mantener mi propio código. Por lo general, la revisión del código no la realiza el autor del código, por lo que el revisor puede mirar el código con nuevos ojos; sin embargo, no tengo ese lujo. ¿Qué prácticas puedo emplear para revisar más efectivamente mi propio código?

En primer lugar, utilice herramientas para verificar todo lo que pueda. Las pruebas (respaldadas con una cobertura de código razonable) le darán cierta confianza en la exactitud del código. Las herramientas de análisis estático pueden atrapar muchas de las mejores prácticas. Sin embargo, siempre habrá problemas que necesitará la atención de los humanos para determinar y nunca hará un buen trabajo revisando sus propias cosas como alguien más, sin embargo, hay algunas cosas que puede hacer para ayudar

• las pruebas de verificación existen y pasan (posiblemente tengan una cobertura de prueba objetivo, aunque es posible que deba romper esto en ciertos casos, pero debería poder justificar por qué)
• marque el análisis estático pasa (también habrá falsos negativos aquí, pero eso está bien siempre que pueda justificar por qué, entonces está bien suprimirlos)
• mantenga una lista de verificación de otras cosas para revisar en la revisión (idealmente agregue esto como nuevas reglas de análisis estático si es posible) asegúrese de verificar cualquier cosa que la SA no pueda verificar, por ejemplo, si los comentarios siguen siendo válidos, las cosas se nombran apropiadamente (nombrar cosas es por supuesto, uno de los 2 problemas difíciles conocidos por la informática)
• si se identifica una falla, verifique si la causa es sistémica y vea por qué no se encontró en pruebas o revisiones anteriores

Por supuesto, esto también es útil cuando está revisando el código de otros

Eche un vistazo al sitio de intercambio de pila de revisión de código . Es para compartir código de proyectos en los que está trabajando para la revisión por pares :

Code Review Stack Exchange es un sitio de preguntas y respuestas para buscar la revisión por pares de su código. Estamos trabajando juntos para mejorar las habilidades de los programadores de todo el mundo al tomar el código de trabajo y mejorarlo.

Si está buscando comentarios sobre un código de trabajo específico de su proyecto en las siguientes áreas ...

• Mejores prácticas y uso de patrones de diseño
• Temas de seguridad
• Actuación
• Corrección en casos imprevistos

También puede usar herramientas de análisis estático de código para detectar cierto tipo de problemas, pero en algunos casos producirán falsas alarmas y no pueden sugerir cómo mejorar el diseño.

He desarrollado varias personas totalmente diferentes en mi cabeza. ¡Uno de ellos ni siquiera es un programador! Estamos charlando, discutiendo las últimas noticias y revisando el código del otro.

Recomiendo encarecidamente mi enfoque.

PD No está bromeando.

Estoy de acuerdo con la opinión de jk-s de que la revisión de una sola persona no es tan eficiente como la revisión de 2 personas. sin embargo, puedes intentar sacar lo mejor de esto:

revisión a corto plazo (poco después de que se produjo el código)

Estoy usando git como repositorio local. Cada vez que termino una función o corrijo un error, transfiero los cambios al repositorio.

Antes de registrarme, comparo lo que he cambiado en mi código y pienso:

• ¿Las variables / método / nombres de clase todavía reflejan para qué se usan?

revisión a largo plazo (6 meses después de que se produjo el código)

Me pregunto:

• ¿Puedo describir en una oración lo que hace una clase / método / variable?
• ¿Qué tan fácil es usar una clase aislada (sin las otras clases) o escribir una prueba unitaria?

Primero, ponga su código a un lado por el tiempo que sea práctico. Trabaja en otra cosa, alguna otra pieza de código. Incluso después de un día, se sorprenderá de lo que encontrará.

Segundo, documente su código. Muchos programadores odian documentar su código, pero siéntate y escribe la documentación, cómo usar el código y cómo funciona. Al mirar su código de una manera diferente, encontrará errores.

Se ha dicho que el verdadero dominio de un tema es la capacidad de enseñarlo a otra persona. Con la documentación, está tratando de enseñarle a otra persona su código.

Transforme esta técnica de depuración en una técnica de revisión de código: http://en.wikipedia.org/wiki/Rubber_duck_debugging

El concepto funciona de maravilla para ponerlo en una mentalidad adecuada para trabajar a través del código como si fuera nuevo.

Además de las herramientas útiles mencionadas en otras respuestas, creo que modificar su mentalidad es útil al hacer una revisión de código. Es una tontería, pero me digo a mí mismo: "Me estoy poniendo el sombrero de revisión de código". Yo hago lo mismo con QA.

Entonces es importante limitarse a esa mentalidad. Usted es el revisor o el revisor, no puede ser ambos a la vez. Entonces, como revisor, tomo notas objetivas para compartir con el revisor. No cambio el código mientras lo reviso, eso no es algo que un revisor deba hacer.

La formalidad se siente un poco absurda a veces, pero cuando trabajo en solitario encuentro que a menudo me empujan en muchas direcciones. Por lo tanto, es posible que no cierre necesariamente el ciclo de revisión antes de que surja algo más: esa formalidad (y realmente, estoy hablando de notas aproximadas en una herramienta wiki), es útil para asegurarme de que la revisión se realice. Del mismo modo, con mi sombrero de control de calidad, agrego tickets para errores antes de corregirlos.

Parece que el sentimiento común es que la autoevaluación no es efectiva. No estoy de acuerdo, y creo que la autoevaluación puede detectar muchos problemas si se hace a fondo.

Aquí hay consejos de mis pocos años de experiencia:

• Tenga una lista de verificación aproximada a mano. Estas son cosas que desea marcar mientras lee su código.
• Ponga su revisión de código fuera de línea. Puede parecer un desperdicio, pero tome impresiones que pueda anotar y voltear de un lado a otro, o el equivalente digital de archivos PDF bien resaltados sincronizados con un iPad que luego se desconecta. Aléjese de su escritorio, para que todo lo que haga sea revisar su código sin distracciones.
• Hágalo temprano en la mañana, en lugar del final de una jornada laboral. Un par de ojos frescos es mejor. De hecho, podría ser útil haber estado alejado del código un día antes de revisarlo nuevamente.

Solo un FYI: estas pautas formaron parte de las recomendaciones de Oracle hace unos años cuando trabajaba allí, donde el objetivo era detectar errores "en sentido ascendente" antes de que el código entrara a prueba. Ayudó mucho, aunque muchos desarrolladores lo consideraron un trabajo aburrido.

La técnica del proceso de software personal para las revisiones puede ser útil, aunque se basa en tener datos históricos sobre su trabajo y la calidad de los productos.

Comienza con datos históricos sobre sus productos de trabajo, específicamente el número y los tipos de defectos. Existen varios métodos para clasificar defectos, como este de un curso de PSP . Puede desarrollar el suyo propio, pero la idea es que necesita saber qué errores está cometiendo en el camino.

Una vez que sepa qué errores está cometiendo, puede desarrollar una lista de verificación que puede usar durante una revisión. Esta lista de verificación cubriría los principales errores que está cometiendo y que cree que se pueden detectar mejor en una revisión (en lugar de utilizar alguna otra herramienta). Cada vez que revise un producto de trabajo, use la lista de verificación y busque esos errores o errores, documente y corríjalos. Revise periódicamente esta lista de verificación de vez en cuando para asegurarse de que se está enfocando en problemas reales y relevantes en su código.

También recomendaría usar el soporte de herramientas cuando tenga sentido. Las herramientas de análisis estático pueden ayudar a encontrar algunos defectos, y algunos incluso admiten la verificación de estilo para garantizar la coherencia y un buen estilo de código. Usar un IDE con finalización de código y resaltado de sintaxis también puede ayudarlo a prevenir o detectar algunos problemas antes de hacer clic en "construir". Las pruebas unitarias pueden cubrir problemas lógicos. Y si su proyecto es lo suficientemente grande o complejo, la integración continua puede combinar todo esto en un proceso de ejecución regular y producir buenos informes para usted.

Trabajar solo significa que, a menos que confíe en extraños completos para revisar el código en su nombre, deberá observar la forma en que escribe su software para mantener la calidad del código.

En primer lugar, debe tener un medio para asegurarse de que su código coincida con los requisitos, y en segundo lugar, que su código será relativamente fácil de cambiar si luego decide que algo está mal. Mi sugerencia sería aplicar un enfoque de Desarrollo impulsado por el comportamiento por las siguientes razones:

1. BDD significa escribir primero la prueba de código. Esto garantiza que todo su código esté cubierto por las pruebas.
2. BDD es esencialmente TDD, pero con un enfoque y un "lenguaje" ligeramente diferentes. Lo que esto implica es que continuamente refactoriza su código mientras trabaja en él, y utiliza sus pruebas para garantizar que sus esfuerzos de refactorización continúen para garantizar que su código satisfaga las especificaciones de su producto.
3. El lenguaje BDD fomenta que las pruebas se escriban en forma de declaraciones que esencialmente codifican los requisitos como pruebas unitarias.

Entonces, la idea aquí es que su refactorización continua del código, incluso después de que aprueben sus pruebas, significa que está revisando efectivamente su propio código y está utilizando sus pruebas unitarias como el "par de ojos extra" que aseguran que su código no Evite los requisitos codificados en las pruebas. Además, la alta cobertura de prueba basada en los requisitos garantiza que podrá cambiar su código en el futuro sin incumplir los requisitos.

El verdadero problema para usted será si puede detectar o no problemas potenciales en su código que indiquen la necesidad de refactorizar. Existen varias herramientas de creación de perfiles en el mercado que pueden ayudarlo con esto, así como otras herramientas relacionadas con las métricas de calidad del código. Esto a menudo puede decirle muchas cosas que las revisiones de código pueden pasar por alto, y son imprescindibles al desarrollar proyectos por su cuenta. Sin embargo, en realidad, la experiencia es la clave, y una vez que tenga la costumbre de ser despiadado en su refactorización, es probable que se vuelva mucho más crítico con su propio código. Si aún no lo ha hecho, le sugiero que lea el libro de Refactorización de Martin Fowler como punto de partida y busque una buena API de BDD que considere que funcionará para usted en el idioma con el que haya elegido trabajar.

Siempre que he estado en la misma situación que usted, he tratado de resolver el problema de "estar demasiado cerca del código para examinarlo objetivamente" mediante el uso de herramientas de métricas / revisión de código. No hace falta decir que una herramienta no puede dar el mismo valor que un revisor experimentado, pero aún puede usarlos para identificar áreas de mal diseño.

Una herramienta que he encontrado bastante útil a este respecto fue SourceMonitor . Es un poco simplista, pero ofrece una buena opinión de nivel medio de su código, como la cantidad de métodos en una clase y la complejidad de cada método. Siempre he sentido que este tipo de información era tan importante (si no más importante) que la aplicación de estilos de codificación a través de herramientas como StyleCop, etc. (que son importantes, pero a menudo no son la fuente de los mayores problemas). Use estas herramientas con los descargos de responsabilidad habituales: sepa cuándo romper una regla de oro, y algo que es todo verde en una herramienta de métrica de código no es automáticamente de buena calidad.

No puedo decirte la cantidad de veces que he estado explicando algo a un revisor de códigos y la bombilla en mi cabeza se enciende y dice: "Oye, espera un minuto". Así que a menudo encuentro mis propios errores en la revisión del código que la otra persona no vio. Para intentarlo, simplemente comience a explicar el código como si hubiera una persona sentada a su lado que intentara entender lo que hizo y por qué.

Otra cosa que encuentro con frecuencia en las revisiones de código es que el desarrollador en realidad no siguió el requisito. Entonces, al comparar su código y lo que hace, el requisito real es una buena verificación.

Frecuentemente hacemos cosas como paquetes SSIS que tienen necesidades estructurales similares: para las revisiones de código desarrollé una lista de verificación de cosas para verificar (es la configuración correcta, está configurada el registro, usa la base de datos de metadatos, son los archivos en la ubicación estándar, etc.) Es posible que también tenga algunas cosas que sería útil verificar cada vez en una revisión de código. Siéntese y piense qué incluiría en una lista de verificación de las cosas que desea asegurarse de verificar en su revisión de código (primer elemento, asegúrese de que se cumpla el requisito, el siguiente elemento podría tener algo que ver con errores de captura y registro). A medida que comete errores y los corrige, puede agregar otros elementos a la lista (diga algo como, ¿me muevo al siguiente registro en un bucle o voy a repetir sin cesar el mismo primer elemento? Solo toma un bucle sin fin para ¡Te enseño a buscar eso!).

Déle 3 meses, luego regrese y mire su código. Te lo prometo, si no puedes encontrar algo malo en ello (¡o pregunta quién escribió esta basura!) ¡Eres un hombre mejor que yo!

Por lo general, imprimo todo mi código y me siento en un ambiente tranquilo y lo leo, encuentro muchos errores tipográficos, problemas, cosas que refactorizar, limpiar al hacer eso. Es una buena autocomprobación que creo que todos deberían hacer.

De vuelta en la universidad, fui tutor de escritura. Ciertamente me ha dado algunas perspectivas sobre la codificación que creo que muchos desarrolladores nunca habrían pensado. Uno de los más importantes es leer su código en voz alta. No parece mucho, pero daré un ejemplo perfecto con el que creo que todos pueden identificarse.

¿Alguna vez ha escrito un correo electrónico o un documento, releído varias veces para asegurarse de que es correcto, luego lo envió, solo para descubrir que tiene un error de ortografía, error tipográfico o gramatical? Acabo de hacer esto ayer cuando le pedí a un cliente que presione la tecla de mierda en lugar de la tecla Mayús. Cuando lees en tu cabeza, ves lo que quieres ver.

Este es un atajo para las sugerencias de 'solo espera un día o una semana o un mes' que otros han hecho. Si lo lees en voz alta, captas las mismas cosas. No sé por qué es tan efectivo, pero después de sentarme con cientos de estudiantes y hacer que lean en voz alta, todo lo que puedo decir es que funciona.

La mayoría de las personas tienden a considerar su código como sus propios bebés y alimentarlos con ego en lugar de realidad. Al igual que cualquier otra revisión de código, revísela cuando vea el código de otra persona. Olvida completamente que has escrito algo. Revise cada línea del código. Una lista de verificación sería útil para ser estético sobre la revisión de código propio. Las herramientas automatizadas para la revisión de código pueden ayudar en cierta medida. He usado algunas herramientas como klocwork (software comercial). Esto es bastante útil mientras trabajas en proyectos grandes y varios desarrolladores trabajan para ello. Siempre enfóquese en la detección de defectos en lugar de la corrección.

Pero una mejor práctica sería, revisarse y luego involucrar al menos a otras dos personas para su revisión con roles distinguidos.

Considere hacer una inspección de Fagan usted mismo: tendrá que adaptar el proceso porque está solo, pero debería poder obtener un poco de valor. El truco será encontrar el "conjunto de reglas" correcto para evaluar su código como un desarrollador en solitario, y luego tener la disciplina para hacer esas preguntas en un estado mental crítico, analítico y despiadado cada vez. Sospecho que es posible que desee hacer una lluvia de ideas para comenzar con sus 4-5 preguntas cruciales, y luego evolucionar con el tiempo. Algunas personas están en contra de las inspecciones formales porque parecen consumir mucho tiempo ... antes de decidir que son demasiado caras, tenga en cuenta toda la evidencia estadística de que hacer las inspecciones correctamente realmente reduce el tiempo del proyecto. Aquí hay un enlace de Wikipedia con el que puede comenzar más investigación:

http://en.wikipedia.org/wiki/Software_inspection

También ha habido algunos libros, por ejemplo, Google para "Proceso de inspección de software" de Strauss y Ebenau.

Otra opción es pagarle a alguien para que inspeccione un proyecto importante, o tal vez pagarle ocasionalmente para que inspeccione todo su código. Este tipo es bastante bueno, lo hemos volado varias veces para entrenar a nuestros nuevos desarrolladores:

http://www.javaspecialists.eu/

Además de todas las recomendaciones para la revisión del código, puede usar las herramientas como PMD y findBug para hacer el primer nivel de cordura para su código.

En realidad, esto aún no se ha colocado en una respuesta (pero se ha agregado como un comentario a una respuesta existente)

Revise su código después de una buena noche de sueño, por ejemplo, comience el día revisando el código que escribió el día anterior.

Por supuesto, esto no le brindará la experiencia colectiva de un equipo, pero le permitirá revisar el código desde una nueva perspectiva.

Por ejemplo, si dejó un fragmento de código con un truco desagradable, es posible que no esté demasiado inclinado a arreglarlo, si revisa su código inmediatamente después. Después de todo, cuando comienzas a revisar tu código, ya sabes y has aceptado la presencia de este truco. Pero si ha dormido bien por la noche, probablemente esté más motivado para encontrar una mejor solución.

Cuando dormimos, el cerebro en realidad no deja de trabajar en los problemas que tenemos, por lo que en realidad puede encontrar una solución allí, aunque esas soluciones a veces pueden presentarse de manera extraña .