2013-03-31

97/4 cosas que todos los programadores deberían saber


Automatice su estándar de codificación

Usted probablemente ha estado allí también. Al inicio de un proyecto, todo el mundo tiene un montón de buenas intenciones - las llaman "las resoluciones nuevo proyecto." Muy a menudo, muchas de estas resoluciones están escritas en los documentos. Los aproximadamente código terminar en estándar de codificación del proyecto. Durante la reunión inicial, el desarrollador principal pasa por el documento y, en el mejor de los casos, todo el mundo está de acuerdo en que van a tratar de seguirlos. Una vez que el proyecto se ponga en marcha, sin embargo, estas buenas intenciones son abandonados, uno a la vez. Cuando el proyecto es finalmente entregado el código es un desastre, y nadie parece saber cómo llegó a ser así.
¿Cuándo las cosas van mal? Probablemente ya en la reunión inicial. Algunos de los miembros del proyecto no le presté atención. Otros no entienden el punto. Peor aún, algunos no estuvieron de acuerdo y ya estaban planeando su rebelión codificación estándar. Por último, algunos entendieron el mensaje y estuvo de acuerdo, pero, cuando la presión en el proyecto se puso demasiado alto, tenían que dejar algo ir. Bueno con formato de código no se ganan puntos con un cliente que quiere una mayor funcionalidad. Por otra parte, a raíz de un estándar de codificación puede ser una tarea aburrida si no está automatizado. Sólo trata de una clase de guión desordenado a mano para averiguar por ti mismo.
Pero si es un problema, ¿por qué es que queremos tener un estándar de codificación en el primer lugar? Una de las razones para dar formato al código de una manera uniforme a fin de que nadie puede "poseer" un pedazo de código justo al formatearlo en su camino privado. Es posible que desee evitar que los desarrolladores el uso de ciertos anti-patrones, con el fin de evitar algunos errores comunes. En total, un estándar de codificación debería hacer más fácil para trabajar en el proyecto, y mantener la velocidad de desarrollo desde el principio hasta el final. Se deduce entonces que todo el mundo debe estar de acuerdo en el estándar de codificación también - no sirve de nada si un desarrollador utiliza tres espacios para indentar el código, y otro cuatro.
Existe una gran cantidad de herramientas que pueden ser usadas para producir informes de calidad del código y de documentar y mantener el estándar de codificación, pero que no es la solución completa. Debe ser automatizado y ejecutadas cuando sea posible. Aquí están algunos ejemplos:
  • Asegúrese de que el formato de código forma parte del proceso de construcción, por lo que todo el mundo que se ejecuta automáticamente cada vez que se compila el código.
  • Utilice las herramientas de análisis de código estático para escanear el código anti-patrones no deseados. Si se encuentra alguno, romper la construcción.
  • Aprenda a configurar las herramientas para que pueda buscar sus propios proyectos específicos anti-patrones.
  • No sólo miden la cobertura de pruebas, pero comprueban automáticamente los resultados también. Una vez más, romper la construcción si la cobertura de la prueba es demasiado bajo.
Trate de hacer esto por todo lo que considere importante. Usted no será capaz de automatizar todo lo que realmente importa. En cuanto a las cosas que usted puede no automáticamente bandera o arreglar, consideran que son un conjunto de directrices complementarias para el estándar de codificación que es automático, sino aceptar que usted y sus colegas no les podemos seguir con tanta diligencia.
Por último, el estándar de codificación debe ser dinámico y no estático. A medida que el proyecto evoluciona, las necesidades de la modificación del proyecto, y lo que puede parecer en un principio inteligente, no es necesariamente inteligente unos meses más tarde.