Code BEAM STO 2022 fue una buena experiencia como comenté en un artículo anterior y nos dejó mucho aprendizaje para ir analizando como la charla de Brujo Benavides sobre las herramientas para Integración Continua de Erlang, ¿las conoces?
La Integración Continua (CI o Continuous Integration en inglés) es una práctica para ir probando y mezclando cada nueva característica en la rama principal mientras cumpla los estándares de calidad auto-impuestos en la organización donde trabajamos. También puede aplicarse en proyectos de software libre como por ejemplo ephp.
Pero Brujo no se quedó únicamente en las pruebas y la cobertura, sino que profundizó mucho más con todas las herramientas disponibles en el ecosistema de Erlang y que tienen un plugin para rebar3.
EUnit y Common Test
Comenzaremos de forma fácil con los entornos de pruebas. Son fáciles y de seguro si sabes algo sobre CI, ya te habrás peleado con EUnit o como CommonTest para sacarles el mayor partido. En la comunidad hay mucha polaridad alrededor de la elección de uno u otro. Por mi parte suelo emplear normalmente EUnit porque lo considero mucho más simple, pero en mi carrera profesional he empleado ambos y según el caso, resulta simple emplear uno u otro dependiendo de la situación.
Como dije inicialmente, este es fácil, si los tests pasan y no se origina ningún fallo entonces el código está probado. No obstante, y como dijo Dijkstra:
los tests muestran la presencia, no la ausencia de fallos
Así que tendremos que basarnos no solo en esta herramienta sino también en otras.
Aún no tengo nada escrito con respecto a estas herramientas pero estoy preparando un documento para pruebas con Erlang. Sígueme en Twitter (Altenwald) para obtener información sobre cada boletín y novedades en Altenwald.
Cobertura
Suele estar integrada dentro de los entornos de pruebas, pero podemos encontrar librerías como coveralls que agregan más potencia y permiten publicar el resultado en cualquier proveedor de coverage.
Incluso teniendo el código cubierto al 100% con tests es posible que surjan fallos no contemplados en los tests. Una alta cobertura no garantiza la ausencia de fallos pero sí mejora mucho la situación con respecto a refactorizaciones y cambios en el código.
EDoc
Documentación. Por mi parte he estado comprobando que documentar el 100% del código: agregar documentación para el módulo, los tipos y cada una de las funciones; ayuda a entender mejor el código y corregir errores de diseño en caso de que haya alguno.
La documentación de EDoc provista por Erlang nos ayuda a generar documentación que puede emplearse para mantener el código y ayudar a usuarios de nuestro código en caso de haber escrito una librería de código que será empleada en diferentes proyectos.
Esta sea quizás una tarea pendiente en Erlang proporcionar un comando que nos permita obtener una cobertura del código con respecto a la documentación y origine un fallo en caso de no llegar al mínimo exigido.
El tema de la documentación la comento en el libro Erlang/OTP Volumen II: Las bases de OTP, en el apéndice A titulado Documentación de Erlang EDoc.
Análisis de discrepancias
La herramienta de Dialyzer es un camino intermedio entre la potencia de tener un lenguaje de tipado dinámico y poder agregar los tipos a posteriori, para realizar comprobaciones. El sistema hace una análisis estático del código y determina los tipos de los argumentos, las funciones y nos avisa en caso de encontrar discrepancias.
Un código sin avisos ni problemas de dialyzer puede potencialmente contener errores, pero un código que presenta avisos y errores en dialyzer de seguro contendrá errores aunque no se hayan manifestado en los tests o las ejecuciones realizadas.
Esta herramienta junto con la especificación de tipos en Erlang lo comento en Erlang/OTP Volumen II: Las bases de OTP en el capítulo hablando de las especificaciones de los tipos de datos en Erlang y el apéndice B sobre Dialyzer.
Elvis (lint)
Realiza un análisis de estilo de código para mostrar "malos olores" en el código. Elvis es lo que se conoce como un lint por el nombre de la primera herramienta que realizaba esta tarea de buscar código sospechoso o posiblemente erróneo a nivel de diseño.
Encontrar código duplicado o con un nivel de anidamiento muy alto, con demasiadas variables en la llamada a una función o funciones poco útiles son algunos de los elementos señalados por estas herramientas.
Elvis permite su uso de forma fácil a través del plugin rebar3_lint, lo que facilita mucho su adición para el sistema de integración continua.
Formateador
Un código legible ayuda mucho a su mantenimiento, pero un código legible, siguiendo las normas impuestas por el equipo de desarrollo y uniforme en cada fichero de código es una ayuda inestimable. En esto, rebar3_format es la herramienta indicada para poder llevar a cabo esta tarea.
A nivel de desarrollo es una buena práctica si antes de cada commit realizamos la ejecución de esta herramienta para unificar el estilo de escritura y así mantener con un buen formato el código.
Quizás una mejora podría ser una opción dry-run con salida errónea (errorlevel) en caso de encontrar ficheros no formateados correctamente.
Detector de código muerto
Una herramienta nueva en el entorno de Erlang recientemente es el detector de código muerto u oxbow code. Esta herramienta muestra código que puede ser eliminado con seguridad de nuestro proyecto por no ser empleado en absoluto.
Este se encuentra también disponible a través de rebar3_hank, otro plugin para rebar3 que nos permite ejecutarlo fácilmente en nuestro proyecto.
Conclusiones
Estas herramientas fueron detalladas y enumeradas en una charla de Brujo Benavides, no en vano, él es el creador y/o mantenedor de estas librerías y/o plugins para rebar3 así que mis kudos y saludos para Brujo y ánimo a todos para ampliar vuestros flujos de trabajo con todas estas herramientas. Lo agradeceréis.
¿Ya empleas alguna de estas herramientas en tu flujo de trabajo? ¿las conocías todas? ¿cuál te ha llamado más la atención? ¿se te ocurre alguna otra que agregar al flujo? ¿alguna mejora? ¡Déjanos tu comentario!
