¿Cómo garantizar el rendimiento y seguridad de las aplicaciones?

Casos prácticos
¿Cómo nos puede ayudar el Análisis Estático de Código?
Existen diferentes tipos de pruebas que pueden utilizarse para comprobar que el código software de una aplicación funciona correctamente. Sin embargo, estas pruebas no son apropiadas cuando lo que se busca es verificar el rendimiento de la aplicación o la seguridad de su código. En esos casos, no habrá más remedio que recurrir a herramientas específicas o a una consultoría especializada.
El análisis estático de código ayuda, en esas situaciones, a poner de manifiesto problemas no funcionales del aplicativo, previniendo y evidenciando problemas potenciales en etapas tempranas del ciclo de vida del software, pero sin pretender ocupar el lugar de una herramienta de pruebas de carga o el de una específica de seguridad.
Una ventaja importante del análisis estático de código es que proporciona importantes ahorros de costes. Al poder anticipar posibles problemas antes de que se hagan realidad, la organización puede evitar el gasto que suponen las correcciones de defectos que, no lo olvidemos, aumenta exponencialmente a medida que va avanzando el ciclo de vida. Es decir, cuanto más tarde se descubra un defecto, más caro resultará resolverlo.
¿Qué se necesita para abordar el análisis estático de código?
Para abordar de forma más clara los distintos el análisis de código es necesario clasificar las características del código software en Factores de Salud, que serán diferentes según los estándares que se apliquen. De forma genérica podemos agrupar las características del código en:
Confiabilidad: Se trata de evitar comportamientos inesperados. Es necesario controlar todos los casos posibles y no realizar operaciones que puedan provocar resultados indeterminados.
Rendimiento: Los recursos no son ilimitados. Hay ocasiones en las que tendemos a pensar que todo se soluciona asignando más recursos, pero lo conveniente es hacer un uso eficiente de los que ya tenemos a nuestra disposición.
Seguridad: La información debe estar suficientemente compartimentada, cada usuario debe poder acceder solo a aquello para lo que tiene permiso.
Mantenibilidad: Cualquier cambio que haya que abordar será tanto más traumático cuanto más complejo y peor documentado sea el código.
Los factores como la confiabilidad, rendimiento y seguridad buscan evitar riesgos en el entorno productivo, mientras que la mantenibilidad y factores similares pretenden dar una idea del coste de propiedad del software.
Hay que tener también en cuenta que cada lenguaje de programación presenta sus particularidades y buenas prácticas, que se traducen en reglas que se asignan a los factores de salud mencionados. Así, no es lo mismo analizar código Cobol que Java, y aunque pueden compartir algunas reglas, otras serán específicas del lenguaje.
Por otra parte, habría que decidir la conveniencia de acudir al análisis manual o al automatizado. Los criterios para elegir uno u otro vienen condicionados por aspectos como la tecnología que se pretende analizar, el método de licenciamiento preferido por la organización o el establecimiento de prioridades, es decir la necesidad de una mayor profundidad en el análisis frente a un mayor tiempo de respuesta.
Cuando se prestan servicios de análisis manual de código no es necesario disponer de ninguna herramienta, aunque sí de un profundo conocimiento del lenguaje y sus buenas prácticas, aparte del entorno y el contexto del cliente. Si se trata de análisis automatizado, habría que acudir a herramientas como Cast, Kiuwan, SonarQube o PMD.
Finalmente, es necesario tener en cuenta que, aunque el análisis sea automatizado, el resultado está sujeto a interpretación, ya que algunas reglas en algunas herramientas causan falsos positivos o pueden no ser de aplicación en ciertos ámbitos.
Casos prácticos del uso de análisis estático de código
En el momento en que el análisis estático de código se introduce en el ciclo de vida se produce un cambio en los equipos de desarrollo. Se dan ocasiones en las que se adoptan malas prácticas simplemente por el hecho de que “siempre se ha hecho así”. En estos casos, el efecto de evidenciar el problema, explicar y justificar la forma correcta de hacerlo, suele ser inmediato.
MTP ha llevado a término algunos estudios sobre la correlación entre incidencias en producción y calidad de código. Por ejemplo, para una compañía del sector de utilities se determinó que solo 16 objetos que aglutinaban el 80% de las incidencias de producción del último año resultaron ser, con mucha diferencia, los más complejos y peor documentados de entre los 22.000 evaluados.
En otro caso fue posible encontrar la causa de las continuas caídas en producción de un aplicativo en la deficiente liberación de recursos que se llevaba a cabo. Este problema suele ser recurrente y conviene detectarlo cuanto antes.
Recientemente, se ha detectado en un aplicativo en desarrollo en el que no se reutilizaban las conexiones a base de datos, resultando en un rendimiento paupérrimo. Como consecuencia, se recomendó la aplicación de un pool de conexiones, con la consiguiente mejora en rendimiento.
¿Qué es la deuda técnica?
El término deuda técnica no solo es aplicable al análisis estático de código. Se trata de un concepto que pretende poner en términos financieros cualquier carencia técnica de un producto.
En el caso que nos ocupa, la deuda técnica se define como el coste de desarrollo en que se incurriría para eliminar los riesgos debidos a la calidad de código en un entorno productivo y, adicionalmente, el coste asociado a la complejidad, falta de documentación, difícil testabilidad etc., presentes en el mismo.
Según la herramienta que se utilice, la deuda técnica puede venir dada en jornadas o en un valor monetario. Independientemente de cómo se exprese, el cálculo se realiza en base a los siguientes factores:
Asignación de un tiempo de corrección a cada incumplimiento de cada regla.
Ponderación de dicho tiempo con un factor de complejidad asociado al elemento en el que se produce el incumplimiento.
De esta forma, dos incumplimientos de la misma regla resultarán más costosos de corregir según la complejidad del objeto en el que se producen.