Revisar la calidad del código [duplicar]

7

Se me ha pedido que revise la calidad de dos bases de código. Nunca he hecho algo así, y necesito consejos sobre cómo realizarlo y reportarlo.

Background

Hay dos proveedores de código, uno en VB y otro en C (ISO 9899: 1999 (C99)). Estos dos programas no funcionan tan bien juntos y, por supuesto, los dos proveedores se culpan entre sí. Por lo tanto, como persona independiente revisaré ambos códigos, a un nivel comprensivo revisaré la calidad de los códigos para averiguar dónde es más probable que se encuentre el problema. No intentaré encontrar problemas, sino simplemente revisar la calidad y lo sencillo que es administrar y entender el código.

Editar : Todavía no he recibido mucha información sobre en qué consiste el problema. Me acaban de decir que examinaré el código en términos de calidad. No mucho más. No conozco los antecedentes de por qué tomaron esta decisión.

    
pregunta magol 29.05.2012 - 10:16

9 respuestas

16

Quita ese "fondo" de tu cabeza, es inútil para la tarea que tienes.

Para ambos programas, haga lo mismo: lea el código, archivo por archivo, línea por línea. Cualquier cosa que no se sienta bien, agréguela a la lista de problemas. Tipografías, código duplicado o muerto, cosas que son difíciles de entender, advertencias IDE / compilador, cualquier cosa. Use comentarios de forma gratuita, no se preocupe por la estructura en este momento, solo complete la lista con lo que le llame la atención.

Después de terminar con la lista, revísala. Vuelva a comprobar si sus notas son correctas. Si puede ver algún tipo de estructura / agrupación en los problemas que notó, reorganice la lista para que se ajuste. Envía la lista a quien te haya preguntado al respecto.

  

En el proyecto anterior, a mi colega se le pidió que revisara un componente que me asignaron para mantener, 5 o 10 K LOC si la memoria sirve. Lo revisó y presentó una lista de 180 artículos (se notaron problemas con ciento ochenta ). Una semana después, la administración me dio un poder completo y un tiempo ilimitado para volver a trabajar ese componente. Pasé alrededor de un mes, abordé todos los artículos que el tipo enumeró. Cinco años de uso intensivo que se aprobaron después de la revisión, se presentaron dos o tres errores contra este componente.

    
respondido por el gnat 29.05.2012 - 13:30
6

Para mí, tu pregunta suena como un "juego de culpa" .

¿El problema realmente es la calidad del código de los dos proveedores de código o más acerca de la descripción de la interfaz entre los dos?

Los requisitos escritos o las pruebas unitarias pueden ayudar a resolver este tipo de problemas en el futuro:

  • ¿Qué son las entradas / salidas válidas que no?
  • ¿Cómo se debe hacer la gestión de errores?
respondido por el k3b 29.05.2012 - 11:05
3

Si su tarea no es encontrar los errores reales, sino como dice, simplemente mida la calidad, entonces necesitará una forma de medirlo.

En C, esto es bastante fácil, simplemente puede verificar qué tan bien se ajusta el código a un estándar de codificación conocido. La autoridad más conocida y reconocida es probablemente MISRA-C , pero existe también es CERT C . Cualquiera de los dos puede usarse, aunque el primero es más adecuado para sistemas de alta integridad y el segundo para la programación de PC. Ambas normas se centran en prohibir las prácticas peligrosas.

A partir de este estándar de codificación, puede elegir una serie de reglas que deberían formar parte de la revisión. Por ejemplo, tendría mucho sentido incluir todas las reglas de MISRA-C que prohíben la dependencia de un comportamiento indefinido. Como resultado, debe obtener una serie de reglas que pueden utilizarse como un medio para medir la calidad.

Luego viene la revisión real. Seguramente necesitaría hacerlo manualmente, pero la forma profesional sería utilizar también una herramienta de análisis estático. Hay muchos de ellos que admiten MISRA-C, y algunos que admiten CERT C. Las herramientas más sofisticadas también pueden encontrar varios otros errores, como anomalías de datos, sobrecargas de búfer, complejidad innecesaria, etc. También pueden realizar cobertura de código, para ver si hay algún código en el programa que nunca se ejecutará.

En cuanto a VB, eso es mucho más difícil. Probablemente no hay una autoridad ampliamente reconocida que puedas citar, aunque quizás hay estándares de codificación que puedes usar, tal vez this ? (Lo encontré en Google, nunca lo he usado). Microsoft sería la mejor autoridad para citar, parecen tener algunas pautas vagas y superficiales sobre cómo escribir VB, pero no serán tan profesionales como los estándares de codificación C.

    
respondido por el user29079 29.05.2012 - 13:33
1

Me parece que lo que realmente necesita es una cierta instrumentación para sentarse entre las aplicaciones y espiar qué mensajes se están pasando entre sí (dependiendo de cómo se comuniquen, esto puede ser algo que necesita para escribirse o algo ya disponible). como Wirehark)

una vez que pueda ver los mensajes, puede decidir quién tiene razón y quién está equivocado en comparación con la especificación de la interfaz. Por supuesto, es posible que la especificación sea ambigua, en cuyo caso debe corregir la especificación (y posiblemente incurrir en más costos por los cambios en uno de los componentes) o convertir su herramienta de espionaje en una compatibilidad de compatibilidad

La revisión de su código ciertamente no tiene sus méritos, pero no lo ayudará a rastrear los problemas de la interfaz (especialmente si la especificación es incorrecta)

    
respondido por el jk. 29.05.2012 - 11:25
1

(Respecto al código, simplemente sumérgete, es la única forma de aprenderlo).

Le sugeriría que considere tener una API para que trabajen las dos partes (esencialmente un contrato). Si se ajustan a la API, el código debería funcionar en conjunto.

Muy parecido a cómo se hace con un WSDL en el mundo del Servicio Web.

Si es posible, entonces tenga un conjunto de pruebas en la API para que pueda ver que eso funciona. De lo contrario, puedes jugar al juego de la etiqueta de la culpa durante años.

    
respondido por el user1249 30.05.2012 - 15:05
1

Hacer las revisiones de código de una manera que sea aceptable para todas las partes involucradas es difícil. Un buen proceso ayudará, así como un estándar objetivo, que juntos aseguren que la revisión sea verificable y repetible. Además, el análisis y la obtención de los datos técnicos es uno, informar de una manera que resuelve la situación del problema, incluida la gestión de las diferentes perspectivas, posiciones, sentimientos, es otra.

La inspección visual y hacer una lista de todas las cosas que están mal con el código suele ser solo una buena idea, no hay restricciones de tiempo y presupuesto o la base del código es realmente pequeña. De lo contrario, las inspecciones en sí podrían ser demasiado trabajo o las correcciones que usted sugiera podrían llevar demasiado tiempo para realizarlas. Ten esto en cuenta cuando vengas con recomendaciones.

¿Qué preguntas de investigación tiene su cliente para la revisión del código y qué se hará con los resultados?

    
respondido por el zwartbont 01.06.2012 - 19:57
0

Realmente depende de lo que quieran y significan por calidad de código.

Pero, en general, su objetivo sería hacer una revisión de cómo funciona el código en términos de:

  • facilidad de mantenimiento y extensibilidad,
  • estabilidad y seguridad,
  • rendimiento.

La mayoría de las métricas se encuentran en estas categorías de porte-manteau (en realidad, ni siquiera consideraría el rendimiento en general, y lo considero la mayor parte del tiempo como un efecto secundario adicional de las buenas puntuaciones en términos de estabilidad y mantenibilidad, por lo tanto, buen diseño de código).

Hay algunas cosas más absolutas que buscar, como las certificaciones de código que se pueden aplicar y medir directamente en algunos códigos de código, pero no dan necesariamente una revisión detallada de estas categorías.

Te aconsejo:

  • abra un IDE y comience a buscar el código,
  • coloque puntos de interrupción para saber qué sucede en el tiempo de ejecución e identifique inquietudes transversales interesantes y cuellos de botella importantes,
  • encuentre algunos verificadores de código y pídales que marquen las violaciones e identifiquen "puntos de acceso" en su base de código,
  • realice algunos perfiles en la aplicación para identificar cuellos de botella,
  • también puede ver las herramientas utilizadas y la compilación del sistema (no lo que pidieron directamente, pero algunas se pueden inferir de eso, y puede ayudar a identificar otros problemas),
  • defina el proceso y las prácticas para luego comenzar a mejorar las métricas que identificó y explique cómo beneficiará al código base, a los desarrolladores y al producto final.

Sé que etiquetaste vb , pero solo para darte un ejemplo, Sonar sería una buena ejemplo de una herramienta que puede ayudarlo a cuantificar la calidad de un código base en muchos aspectos, desde la calidad del código desde un punto de vista técnico o incluso desde una perspectiva empresarial, vinculando (de forma más o menos precisa) algunos marcadores a los costos empresariales. Desea encontrar una herramienta equivalente o un conjunto de herramientas que le permitan lograr resultados similares en su área. Sonar tiene un complemento C, si lo desea, y estoy bastante seguro de que Visual Studio tiene algunos analizadores de buena calidad de código integrados o externos, para VB.

    
respondido por el haylem 02.06.2012 - 03:04
0

¿Cuánto tiempo se le ha asignado? a menos que la magnitud aproximada sea de 20% a 50% del tiempo de desarrollo de las aplicaciones que está revisando, está perdiendo el tiempo y realizando un ejercicio político para hacer que alguien se sienta bien. eso.

La mayoría de las cosas sugeridas para buscar son (aunque es lo mejor que sabemos) una forma inexacta de determinar la calidad del software, y es muy poco probable que se enfrente a un escrutinio riguroso. Considere cuidadosamente lo que escribe en su informe (puede que tenga que defenderlo en una casilla de testigos), ¿hasta dónde llegará esta disputa y cuánto dinero está en juego, las partes quieren encontrar una solución o culpar?

Suponiendo que usted es un programador, no un analista forense con una especialización en programación (en cuyo caso, sabría que no hizo esta pregunta en un foro público), si fuera usted, rechazaría la tarea de la manera más fuerte posible. podría. Se está configurando para enfrentar a los proveedores de software que se caen uno contra el otro sin nada más que su opinión ... Si uno de esos proveedores encuentra esta Q & A, ¿cómo le hará lucir?

Antes de completar su informe, deberá estar seguro de para qué se utilizará. Asegúrese de que esté redactado con frases como "aparece" y "creo" en lugar de absolutos como "el código es una mierda". Si debe hacer afirmaciones, se requerirá la referencia a estándares publicados y ampliamente aceptados. p.ej. "El código no cumple con los estándares especificados en las pautas de MISRA para C" es un hecho, pero declarar que debe cumplir con esas pautas no lo sería (a menos que su contrato así lo indique o lo afirmen).

    
respondido por el mattnz 30.05.2012 - 23:55
0

Tirar un dado de 6 caras. 1-3 es el código VB, 4-6 es el código C Tome unas vacaciones de 2 meses y dígales a todos qué código es malo después de que regrese. Usted está en una lucha política que parece.

O mejor aún, dígales que va a revisar el código, pero no lo haga. Regrese con arreglos de trabajo para ambos conjuntos de códigos que les permiten trabajar juntos.

    
respondido por el Andrew T Finnell 03.06.2012 - 02:46

Lea otras preguntas en las etiquetas