Instrucciones para la protección de código de calidad
La lista siguiente proporciona varias instrucciones para proteger el código de calidad.
Se requiere
Insista en proteger código de calidad.
No acepte código de baja calidad durante la protección del código; provoca problemas más delante en el ciclo del producto. Tenga en cuenta que los equipos normalmente no corrigen los problemas que son demasiado complejos u ocultos o que se detectan demasiado tarde en el ciclo del producto.
Utilice listas de comprobación.
Realice el seguimiento de los tipos de errores que suele cometer y utilícelos como lista de comprobación para el código que desarrolle en el futuro. Puede comenzar la lista de comprobación con los errores comunes que ha cometido su grupo o división y, a continuación, personalizarla para su propio uso.
Realice revisiones del código.
Las revisiones de código le permiten explicar y entender mejor su propio código y ofrecen a los demás la oportunidad de ver el código de nuevo.
Escriba pruebas unitarias.
La mejor manera de garantizar la calidad es escribir pruebas que validan los datos y algoritmos y comprueban que los errores anteriores no se repiten. Existen cuatro tipos de pruebas unitarias:
Las pruebas unitarias positivas ejecutan el código como está previsto y comprueban que el resultado es correcto.
Las pruebas unitarias negativas realizan intencionalmente un uso incorrecto del código y comprueban si el control de errores es sólido y apropiado.
Las pruebas de esfuerzo llevan el código al límite, con la esperanza de poner de manifiesto errores sutiles de recursos, coordinación o reentrada.
Las pruebas de inserción de errores ponen de manifiesto las anomalías en el control de errores.
Para obtener más información, vea Crear y ejecutar pruebas unitarias para código existente.
Utilice las herramientas de análisis de código.
La manera más simple de detectar los errores desde el principio es aumentar el nivel de advertencia del compilador y utilizar las herramientas de análisis de código. Es vital no pasar por alto nunca una advertencia y corregir el código.
Para obtener más información, vea Analizar la calidad del código administrado mediante el análisis de código.
Analizar la calidad de código de C/C++ mediante el análisis de código y Analizar el código de base de datos para mejorar la calidad del código.
No utilice lenguaje impropio en el código fuente.
No debe haber ningún tipo de lenguaje ni referencias impropios en el código fuente. Muchos clientes de todo el mundo son muy sensibles a determinadas expresiones o nombres, especialmente a las referencias a entidades políticas cuya categoría se pueda cuestionar. Busque cualquier referencia o lenguaje que puedan ser políticamente incorrectos en el código fuente y, a continuación, comunique todos los errores.
Cree elementos de trabajo.
No se olvide del trabajo inacabado; asegúrese de crear elementos de trabajo para los comentarios TODO, REVIEW, BUG y UNDONE. Para obtener más información, vea Crear un elemento de trabajo.
Se debe evitar
Las características sin una especificación.
No escriba código sin una especificación. En primer lugar, escriba una especificación y pida que la revisen. Sin una especificación, es imposible que el equipo de pruebas sepa qué funciona bien y qué no. Si escribe código sin una especificación, se pueden producir malentendidos entre los miembros del equipo, o interpretarse incorrectamente los deseos del cliente, y distribuir un producto de baja calidad. Para obtener más información, vea Planear y seguir proyectos.
Alcanzar el punto central del primer hito sin haber instalado el producto.
El equipo de pruebas debe tener alguna manera de instalar el producto en sus equipos, aunque se trate de un prototipo de instalación. Para obtener más información, vea Compilar la aplicación.
Se recomienda
Utilice un estilo de codificación uniforme.
Cuando todo el equipo escribe el código con el mismo estilo, el producto es más fácil de leer y mantener, y también goza de mayor coherencia y calidad en general. Cuáles sean las instrucciones específicas no es tan importante. Lo verdaderamente importante es establecer una serie de instrucciones y exigir al equipo que las siga a rajatabla. Los beneficio principales que se derivan de la elección de un estilo son la coherencia y la facilidad para reconocer los patrones de codificación. Por ello, es importante elegir un estilo y utilizarlo.
Escriba las pruebas unitarias antes de escribir el código.
Desarrollar las pruebas en primer lugar constituye una metodología fundamental tomada del desarrollo ágil y la programación extrema. Escribiendo primero las pruebas unitarias se logran varios objetivos de calidad:
Se garantiza que se escriben las pruebas unitarias.
Se garantiza que el código se pueda probar con facilidad, lo que suele dar lugar a una mayor cohesión y un acoplamiento más flexible entre los módulos.
Con frecuencia permite detectar el diseño adecuado para el trabajo, al determinar antes cómo se va a probar el diseño.
Para obtener más información, vea Crear y ejecutar pruebas unitarias para código existente.
Escriba código portable a otras plataformas.
Un código diseñado y escrito para la portabilidad lo hace más robusto, aunque en realidad no tenga intención de distribuirlo en otra plataforma. Al crear código portable:
Se toman mejores supuestos.
Se aumenta la claridad sobre los tipos de datos y la intención del diseño.
Se garantiza que el código es más capaz de admitir nuevas plataformas en el futuro.
Refactorice el código existente en funciones más pequeñas.
La refactorización puede renovar el código antiguo. Tratar de corregir sistemas antiguos de gran tamaño puede resultar difícil, porque las interacciones en algunos de ellos son tan complejas que el desarrollador se resiste a cambiar siquiera un comentario.
Para refactorizar correctamente, en primer lugar debe incorporar pruebas unitarias sólidas, a fin de garantizar que la refactorización no introduce nuevos errores. A continuación, separe las funciones grandes en colecciones de funciones más pequeñas, sin cambiar la funcionalidad en absoluto. Las instrucciones son:
Cada función más pequeña debe realizar un solo tipo de tarea, como una interfaz de usuario, acceso a la base de datos, interacción COM a una sola interfaz, etc.
Después de haber refactorizado completamente todas las funciones de un subsistema, puede introducir modificaciones en las funciones individuales, más pequeñas, sin que ello afecte al sistema en su conjunto. Puede agregar, quitar o mejorar la funcionalidad de las funciones de una en una.
Para obtener más información, vea Refactorización de clases y tipos (Diseñador de clases).
Revise el código existente.
Los errores suelen agruparse en módulos concretos. Cuando el nuevo código está limpio pero hay algunos módulos del código anterior que contienen errores, revise esos módulos solamente. Si el nuevo código está demasiado interrelacionado con el anterior, con frecuencia resulta más fácil resolver los errores si se refactoriza antes.
Para obtener más información, vea Analizar la calidad del código administrado mediante el análisis de código.
Analizar la calidad de código de C/C++ mediante el análisis de código y Analizar el código de base de datos para mejorar la calidad del código.
Recorra paso a paso todas las rutas de acceso de código en un depurador.
Una de las mejores maneras de comprobar el código es recorrerlo paso a paso en un depurador. En cada línea, compruebe que sucede lo que está previsto. Recorrer paso a paso todas las rutas de acceso de código en un depurador es igual que realizar una prueba unitaria línea a línea. Se trata de un procedimiento tedioso, pero comprueba con eficacia si el comportamiento es el esperado.
No se recomienda
Utilizar un documento de requisitos como una especificación.
No intente interpretar la especificación partiendo de un documento de requisitos. Su interpretación podría ser diferente de la del administrador de programas o la del evaluador. Si su interpretación es diferente, su implementación no estará a la altura de lo que los demás esperan.