Control de calidad del código fuente: ya no es solo para desarrolladores

Hace veinte años, cuando trabajaba en la industria automotriz, el director de una fábrica solía decir: "Tenemos un día para construir un automóvil, pero nuestro cliente tiene toda la vida para inspeccionarlo". La calidad era de suma importancia. De hecho, en sectores más maduros como las industrias automotriz y de la construcción, la garantía de calidad es una consideración clave que se integra sistemáticamente en el proceso de desarrollo de productos. Si bien esto es sin duda impulsado por la presión de las compañías de seguros, también está dictado, como señaló el director de la fábrica, por la vida útil del producto resultante.

Sin embargo, cuando se trata de software, los ciclos de vida más cortos y las actualizaciones continuas significan que la integridad del código fuente a menudo se pasa por alto en favor de nuevas características, funcionalidades sofisticadas y velocidad de lanzamiento al mercado. Los gerentes de producto a menudo le restan prioridad a la garantía de calidad del código fuente o dejan que los desarrolladores lo manejen, a pesar de que es uno de los factores más críticos para determinar el destino de un producto. Para los gerentes de productos preocupados por construir una base sólida para el desarrollo de productos y eliminar riesgos, es esencial definir e implementar una evaluación sistemática de la calidad del código fuente.

Definición de "Calidad"

Antes de explorar las formas de evaluar y promulgar correctamente un proceso de control de calidad del código fuente, es importante determinar qué significa "calidad" en el contexto del desarrollo de software. Este es un tema complejo y multifacético, pero en aras de la simplicidad, podemos decir que la calidad se refiere al código fuente que respalda la propuesta de valor de un producto sin comprometer la satisfacción del consumidor ni poner en peligro el modelo comercial de la empresa de desarrollo.

En otras palabras, el código fuente de calidad implementa con precisión las especificaciones funcionales del producto, satisface los requisitos no funcionales, garantiza la satisfacción de los consumidores, minimiza los riesgos legales y de seguridad, y se puede mantener y ampliar de manera asequible.

Dada la amplitud y rapidez con la que se distribuye el software, el impacto de los defectos del software puede ser significativo. Los problemas como los errores y la complejidad del código pueden dañar los resultados de una empresa al dificultar la adopción de productos y aumentar los costos de gestión de activos de software (SAM), mientras que las infracciones de seguridad y las infracciones de cumplimiento de licencias pueden afectar la reputación de la empresa y generar problemas legales. Incluso cuando los defectos de software no tienen resultados catastróficos, tienen un costo innegable. En un informe de 2018, la empresa de software Tricentis descubrió que 606 fallas de software de 314 empresas representaron $1,7 billones en ingresos perdidos el año anterior. En un informe de 2020 recién publicado, CISQ calculó el costo del software de mala calidad en los EE. UU. en $ 2,08 billones, con otros $ 1,31 billones estimados en costos futuros incurridos a través de la deuda técnica. Estos números podrían mitigarse con intervenciones anteriores; el costo promedio de resolver un problema durante el diseño del producto es significativamente menor que resolver el mismo problema durante la prueba, que a su vez es exponencialmente menor que resolver el problema después de la implementación.

Manejo de la patata caliente

A pesar de los riesgos, la garantía de calidad en el desarrollo de software se trata de forma fragmentaria y se caracteriza por un enfoque reactivo en lugar del proactivo adoptado en otras industrias. Se cuestiona la propiedad de la calidad del código fuente, cuando debería verse como la responsabilidad colectiva de diferentes funciones. Los gerentes de producto deben ver la calidad como una característica impactante en lugar de una sobrecarga, los ejecutivos deben prestar atención al estado de calidad e invertir en él, y las funciones de ingeniería deben resistirse a tratar la limpieza de código como una "papa caliente".

Para agravar estos desafíos de delegación está el hecho de que las metodologías y herramientas existentes no abordan el problema de la calidad del código en su totalidad. El uso de metodologías de integración continua/entrega continua reduce el impacto del código de baja calidad, pero a menos que CI/CD se base en un análisis de calidad completo y holístico, no puede anticipar y abordar de manera efectiva la mayoría de los peligros. Los equipos responsables de las pruebas de control de calidad, la seguridad de las aplicaciones y el cumplimiento de las licencias trabajan en silos utilizando herramientas diseñadas para resolver solo una parte del problema y evaluar solo algunos de los requisitos no funcionales o funcionales.

Teniendo en cuenta el papel del gerente de producto

La calidad del código fuente juega con numerosos dilemas que enfrenta un gerente de producto durante el diseño del producto y durante todo el ciclo de vida del desarrollo del software. La deuda técnica es una carga pesada. Es más difícil y más costoso agregar y modificar funciones en un código base de baja calidad, y admitir la complejidad del código existente requiere inversiones significativas de tiempo y recursos que, de otro modo, podrían gastarse en el desarrollo de nuevos productos. A medida que los gerentes de producto equilibran continuamente el riesgo con la velocidad de comercialización, deben considerar preguntas como:

• ¿Debo usar una biblioteca de OSS (software de código abierto) o crear una funcionalidad desde cero? ¿Qué licencias y responsabilidades potenciales están asociadas con las bibliotecas seleccionadas?
• ¿Qué pila tecnológica es más segura? ¿Cuál asegura un ciclo de desarrollo rápido y de bajo costo?
• ¿Debo priorizar la configurabilidad de la aplicación (alto costo/retraso en el tiempo) o implementar versiones personalizadas (alto costo de mantenimiento/falta de escalabilidad)?
• ¿Qué tan factible será integrar productos digitales recién adquiridos mientras se mantiene una alta calidad de código, se minimizan los riesgos y se mantienen bajos los costos de ingeniería?

Las respuestas a estas preguntas pueden afectar seriamente los resultados comerciales y la propia reputación del gerente de producto, pero las decisiones a menudo se toman en base a la intuición o la experiencia pasada en lugar de una investigación rigurosa y métricas sólidas. Un proceso exhaustivo de evaluación de la calidad del software no solo proporciona los datos necesarios para la toma de decisiones, sino que también alinea a las partes interesadas, genera confianza y contribuye a una cultura de transparencia, en la que las prioridades son claras y acordadas.

Implementación de un proceso de 7 pasos

Un proceso completo de evaluación de la calidad del código fuente da como resultado un diagnóstico que considera el conjunto completo de determinaciones de calidad en lugar de unos pocos síntomas aislados de un problema mayor. El método de siete pasos que se presenta a continuación está alineado con las recomendaciones de CISQ para la mejora de procesos y está destinado a facilitar los siguientes objetivos:

• Encuentre, mida y solucione el problema cerca de su causa raíz.
• Invierta de manera inteligente en la mejora de la calidad del software en función de las mediciones generales de calidad.
• Aborde el problema analizando el conjunto completo de medidas e identificando las mejoras mejores y más rentables.
• Considere el costo total de un producto de software, incluidos los costos de propiedad, mantenimiento y alineación de la regulación de licencia/seguridad.
• Supervise la calidad del código en todo el SDLC para evitar sorpresas desagradables.

1. Mapeo de producto a código: rastrear las características del producto hasta su base de código puede parecer un primer paso obvio, pero dada la velocidad a la que aumenta la complejidad del desarrollo, no es necesariamente simple. En algunas situaciones, el código de un producto se divide entre varios repositorios, mientras que en otras, varios productos comparten el mismo repositorio. Es necesario identificar las diversas ubicaciones que albergan partes específicas del código de un producto antes de que pueda llevarse a cabo una evaluación adicional.

2. Análisis de pila tecnológica: este paso tiene en cuenta los diversos lenguajes de programación y herramientas de desarrollo utilizados, el porcentaje de comentarios por archivo, el porcentaje de código generado automáticamente, el costo promedio de desarrollo y más.

Herramientas sugeridas: cloc

Alternativas: Tokei, scc, sloccount

3. Análisis de versiones: según los resultados de esta parte de la auditoría, que implica identificar todas las versiones de un código base y calcular las similitudes, las versiones se pueden fusionar y eliminar las duplicaciones. Este paso se puede combinar con un análisis de puntos de error (puntos calientes), que identifica las partes difíciles del código que se revisan con mayor frecuencia y tienden a generar costos de mantenimiento más altos.

Herramientas sugeridas: cloc, scc, sloccount

4. Revisión de código automatizada: esta inspección investiga el código en busca de defectos, violaciones de prácticas de programación y elementos riesgosos como tokens codificados, métodos largos y duplicaciones. La(s) herramienta(s) seleccionada(s) para este proceso dependerán de los resultados de la pila tecnológica y los análisis de versiones anteriores.

Herramientas sugeridas: SonarQube, Codacy

Alternativas: RIPS, Veracode, Micro Focus, Parasoft y muchas otras. Otra opción es Sourcegraph, una solución de búsqueda de código universal.

5. Análisis de seguridad estática: este paso, también conocido como prueba de seguridad de aplicaciones estáticas (SAST), explora e identifica posibles vulnerabilidades de seguridad de aplicaciones. La mayoría de las herramientas disponibles escanean el código contra los problemas de seguridad frecuentes identificados por organizaciones como OWASP y SANS.

Herramientas sugeridas: WhiteSource, Snyk, Coverity

Alternativas: SonarQube, Reshift, Kiuwan, Veracode

6. Análisis de componentes de software (SCA)/Análisis de cumplimiento de licencias: esta revisión implica identificar las bibliotecas de código abierto vinculadas directa o indirectamente al código, las licencias que protegen cada una de estas bibliotecas y los permisos asociados con cada una de estas licencias.

Herramientas sugeridas: Snyk, WhiteSource, Black Duck

Alternativas: FOSSA, Sonatype, y otras

7. Análisis de riesgo comercial: esta medida final implica consolidar la información recopilada de los pasos anteriores para comprender el impacto total del estado de calidad del código fuente en el negocio. El análisis debe dar como resultado un informe integral que proporcione a las partes interesadas, incluidos los gerentes de productos, los gerentes de proyectos, los equipos de ingeniería y los ejecutivos de C-suite, los detalles que necesitan para sopesar los riesgos y tomar decisiones informadas sobre los productos.

Aunque los pasos anteriores en este proceso de evaluación pueden automatizarse y facilitarse a través de una amplia gama de productos comerciales y de código abierto, no existen herramientas que respalden el proceso completo de siete pasos o la agregación de sus resultados. Debido a que la compilación de estos datos es una tarea tediosa y que requiere mucho tiempo, se realiza al azar o se omite por completo, lo que puede poner en peligro el proceso de desarrollo. Este es el punto en el que un proceso de inspección de software completo a menudo se desmorona, lo que hace que este último paso sea posiblemente el más crítico en el proceso de evaluación.

Selección de las herramientas adecuadas

Si bien la calidad del software afecta el producto y, por lo tanto, los resultados comerciales, la selección de herramientas generalmente se delega a los departamentos de desarrollo y los resultados pueden ser difíciles de interpretar para quienes no son desarrolladores. Los gerentes de productos deben participar activamente en la selección de herramientas que aseguren un proceso de control de calidad transparente y accesible. Si bien anteriormente se sugirieron herramientas específicas para los diversos pasos de la evaluación, hay una serie de consideraciones generales que deben tenerse en cuenta en cualquier proceso de selección de herramientas:

• Pila de tecnología admitida: tenga en cuenta que la mayoría de las ofertas disponibles admiten solo un pequeño conjunto de herramientas de desarrollo y pueden generar informes parciales o engañosos.
• Simplicidad de instalación: las herramientas cuyos procesos de instalación se basan en secuencias de comandos complejas pueden requerir una importante inversión en ingeniería.
• Informes: se debe dar preferencia a las herramientas que exportan informes detallados y bien estructurados que identifican problemas importantes y brindan recomendaciones para solucionarlos.
• Integración: Las herramientas deben ser seleccionadas para una fácil integración con las otras herramientas de desarrollo y administración que se utilizan.
• Precios: las herramientas rara vez vienen con una lista de precios completa, por lo que es importante considerar cuidadosamente la inversión involucrada. Varios modelos de precios suelen tener en cuenta aspectos como el número de empleados, el tamaño del código y las herramientas de desarrollo involucradas.
• Implementación: al sopesar la implementación local versus la nube, considere factores como la seguridad. Por ejemplo, si el producto que se está evaluando maneja datos confidenciales o sensibles, las herramientas locales y las herramientas que utilizan el enfoque de auditoría ciega (FOSSID) pueden ser preferibles.

Mantenerlo en marcha

Una vez que los riesgos han sido identificados y analizados metódicamente, los gerentes de producto pueden tomar decisiones bien pensadas sobre la priorización y clasificación de defectos con mayor precisión. Los equipos podrían reestructurarse y asignarse recursos para abordar los problemas más emergentes o predominantes. Los "simpáticos", como las infracciones de licencia de alto riesgo, tendrían prioridad sobre los defectos de menor gravedad, y se pondría más énfasis en las actividades que contribuyen a la reducción del tamaño y la complejidad de la base de código.

Sin embargo, este no es un proceso de una sola vez. La calidad del software de medición y monitoreo debe ocurrir continuamente en todo el SDLC. La evaluación completa de siete pasos debe realizarse periódicamente, y los esfuerzos de mejora de la calidad deben comenzar inmediatamente después de cada análisis. Cuanto más rápido se identifique un nuevo punto de riesgo, más barato será el remedio y más limitadas serán las consecuencias. Hacer que la evaluación de la calidad del código fuente sea central para el proceso de desarrollo de productos enfoca a los equipos, alinea a las partes interesadas, mitiga los riesgos y brinda a un producto su mejor oportunidad de éxito, y ese es el negocio de cada gerente de producto.