Cuarta «Automate Your Coding Standard»

Tabla de Contenidos

0. Introducción
1. ¿Cuándo las cosas se empiezan a poner mal?
2. ¿Por qué utilizar estandarización del código?
3. Herramientas de estandarización del código y sugerencias 
4. Conclusiones
5. Glosario
6. Referencias

Introducción

En mi experiencia personal, y ahora que tengo la oportunidad de leer el artículo de Filip van Laenen -Automate Your Coding Standard-, quiero dedicar este artículo a hablar de mi experiencia en proyectos como freelancer y en empresas de desarrollo, y contrastarla con los mensajes del autor del artículo en cuestión.

Para empezar, menciono la importancia de las reuniones de los equipos de desarrollo al inicio del proyecto. En estas reuniones, se muestra los elementos más importantes del proyecto, como son:

• Arquitectura de la solución
• Tecnologías a utilizar
• Cronograma de actividades
• Asignación de roles
• Etc.

Además, entre las consideraciones que en mi experiencia no he puesto muchos esfuerzos está la de automatizar el estándar de codificación. De acuerdo a [2], en las primeras reuniones todo el equipo de desarrollo debe definir un esquema de pautas para la estandarización del código, y se debe invertir recursos para que los miembros sigan los estándares y se produzca código fácilmente mantenible en futuras modificaciones.

Lo anterior, resulta un reto, debido a que los desarrolladores y programadores tienden a ir omitiendo las reglas impuestos por el estándar, o simplemente seguirlas medianamente. Y para empeorar el asunto, al final del proyecto se tendrá una cantidad ingente de código desordenado.

En las siguientes partes de este artículo veremos cómo las cosas empiezan a ponerse mal, el porqué es importante utilizar un estándar de codificación, y algunas sugerencias para el uso de herramientas de automatización de los estándares de codificación.

1. ¿Cuándo las cosas empiezan a ponerse mal?

Admito francamente que muchas reuniones resultan aburridas por la metodología monolítica en que son presentadas. A veces acompañadas de presentaciones de filminas de decenas de diapositivas repletas de texto que conduce a romper la atención y prestarla en el dispositivo que a uno lo acompaña, o simplemente de ir al grano, es decir, a empezar con la construcción de la solución.

Por otro lado, y según [2], estos son otros síntomas que muestran el momento en que las cosas se empiezan a poner mal:

• Los miembros del equipo de desarrollo no prestan la atención suficiente y necesaria al estándar de codificación establecido y acordado.
• Los miembros no entienden (desde el comienzo) cuál es el propósito del estándar de codificación.
• Algunos miembros prefieren configurar su IDE con las preferencias personales para codificación. Algunos pueden llegar a ser tan arbitrarios, que dan la impresión de ir contra del estándar. Miremos por ejemplo la Figura 1 donde de forma privativa el programador podría cambiar los parámetros de indentación del código.
• Otros miembros aceptan el estándar, pero a medida que avanzan irán omitiendo el esquema por la presión por parte de los clientes, o líderes del proyecto.

Figura 1. Parametrización de la indentación en C#.

También estoy de acuerdo con el autor, cuando expresa que el estándar de codificación no hará más feliz al cliente, pues éste lo que exige y espera es una aplicación con la funcionalidad especificada. Pero el valor que conseguirá el equipo de desarrollo en un futuro próximo, es la facilidad para la mantenibilidad y la refactorización del código.

2. ¿Por qué utilizar un estándar de codificación?

En su artículo Filip se cuestiona: But if it's such a problem, why is it that we want a coding standard in the first place? Este es un asunto importante, debido a que dar libertad a cada miembro para el establecimiento de un estándar de codificación arbitrario, generará propiedad individual del código y provocará en el corto plazo dificultades para la mantenibilidad y refactorización del código: en el caso que un miembro abandonará su puesto y llegará un nuevo programador con ideas diferentes.

También aclara el autor, que en un estándar de codificación el más mínimo detalle debe ser respetado y seguido minuciosamente. Al final, el equipo se beneficiará cuando el stakeholder (cliente, usuario) requiera actualización de aspectos funcionales de la aplicación.

3. Herramientas de automatización del estándar de codificación y sugerencias

En este punto admito mi desconocimiento respecto a las herramientas de automatización de estándares de codificación, pero me permito tomar las sugerencias dadas por Filip van Laenen en [2]:

• Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile code.
• Use static code analysis tools to scan the code for unwanted antipatterns. If any are found, break the build.
• Learn to configure those tools so that you can scan for your own, project specific antipatterns.
• Do not only measure test coverage, but automatically check the results, too. Again, break the build if test coverage is too low.

4. Conclusiones

Hemos visto la importancia de usar un estándar de codificación en proyectos software. Este esquema nos facilitará la mantenibilidad y refactorización en actualizaciones del producto. Además se ha presentado, al principio, cómo las cosas puede empezar a ir mal cuando permitimos a cada miembro establecer su propio estándar de codificación. Finalmente, algunas sugerencias para el uso de herramientas de automatización para generar reportes en tiempo de construcción para medir el grado de cumplimiento del esquema de codificación.

5. Glosario

- Estándar de codificación
- Stakeholder

6. Referencias

[1] 97 Things Every Progammer Should Know - https://docs.google.com/file/d/0B7fdLEVE609Ga3RTSmxSZHlSN0U/edit?usp=sharing
[2] Automate Your Coding Standard - http://programmer.97things.oreilly.com/wiki/index.php/Automate_Your_Coding_Standard
{3} Automating C# Coding Standards using StyleCop and FxCop - http://www.slideshare.net/BlackRabbitCoder/automating-coding-standards

H