Las piezas de software construidas y/o entregadas por Elun deben cumplir con estándares mínimos para asegurar su escalamiento, mantenibilidad y observabilidad.
Tanto en este capítulo como en los siguientes (3. Documentación y 4. Monitoreo) se revisarán las definiciones de estos estándares mínimos.
En Elun, una pieza de software Escalable es aquella que tiene la capacidad de adaptarse y dar respuesta a un requerimiento o un propósito, de manera consistente y medida respecto al aumento significativo en su uso.
Un software Escalable permite que sea future proof, es decir, si en el tiempo cambian ciertas condiciones del ambiente o el negocio, el software podrá adaptarse con un menor esfuerzo y recursos.
De cara a los spin-off o clientes de Elun, esto se traduce en ganar una ventaja significativa con las áreas de negocio, ya que aumenta la confianza en la resolución de los proyectos, y en consecuencia, mejora el foco que le puede dar Elun a las iniciativas relacionadas con levantamiento, consultoría y negocio.
Este es uno de los tantos valores diferenciadores que tiene Elun frente a otros proveedores de software que puedan tener sus clientes.
A continuación se declararán los Estándares con los que Elun considera piezas de software Escalables.
No es el propósito de este documento enseñar cada uno de los puntos a continuación, sino más bien declararlos para que sean considerados dentro de los procesos de construcción.
El concepto de código limpio es acuñado por Robert C. Martin (más conocido coloquialmente como “el tio Bob”), un ingeniero de software y autor de varios libros sobre ciencia de la algoritmia. Es reconocido por desarrollar varios principios de diseño de software y ser uno de los coautores del Manifiesto Ágil.
Dentro de los conceptos relevates del Clean Code propuesto por “el tio Bob” se encuentra el de Alta cohesión y Bajo acoplamiento.
Un software altamente cohesionado es aquel en que sus distintos componentes están apropiadamente interconectados y trabajan juntos de manera efectiva.
Un software bajamente acoplado es aquel en que sus distintos componentes presentan cierto grado de independencia sin depender de otros componentes para cumplir su propósito.
En resumen, un software altamente cohesionado y bajamente acoplado es más fácil de entender, mantener, extender.
Para cumplir lo anteriormente declarado, se debe implementar de manera práctica en todas las piezas de software construidas lo declarado bajo el principio SOLID:
El esperado es que los constructores de software de Elun, tanto internos como externos, entiendan, practiquen e implementen los principios anteriormente señalados para segurar las medidas de calidad de cohesión y acoplamiento.
Los patrones de diseño son siempre bienvenidos dentro del desarrollo. Es de libre elección el patron de diseño por parte del constructor de software siempre y cuando sea uno documentado y probado. En general, los patrones de diseño que sugerimos deben ser considerados como un mínimo exigible siempre y cuando no haya una propuesta con mejores y probadas ventajas.
Para ayudar en la mantenibilidad, es necesario ser consistente con la guía de estilo de codificación de cada lenguaje. Para los lenguajes:
Adicional a la guía de estilo, es necesario también implementar en el pipeline de codificación el uso de Lintters de código.
En el procesos de pipeline de CI/CD se establecerá un paso específico para la revisión de formato con los lintters indicados. Por lo que es importante que durante el desarrollo el constructor de la pieza de software siempre se preocupe de cumplir estos estándares.
Es un requerimiento obligatorio que todas las piezas de software implementadas presenten evidencia de pruebas, ya sea manual o automatizada.
En general, esta evidencia debe poder certificar que el componente de software implementa sus funcionalidades de manera correcta para todos los posibles casos, tanto comunes como de borde. Es obligación del constructor o del mismo proveedor el entregar esta evidencia en cada entrega. Esto se detalla de mejor manera desde la perspectiva de la gestión de la entrega en el capítulo de 5. Entregas, pero en este capítulo se revisarán las pruebas correspondientes a la dimensión de programación.
Si se consensúa que la entrega de evidencia no será exhaustiva a través de pruebas manuales, el constructor o proveedor deberá implementar pruebas unitarias que certifiquen los distintos escenarios de ejecución de la pieza a probar.
Estas pruebas deberán implementarse bajo la estructura Given-When-Then.
También se deberá considerar que las pruebas unitarias se puedan ejecutar en un entorno autocontenido, con una base de pruebas limpia e independiente para asegurar un procesamiento consistente independiente de variables del entorno, como por ejemplo, la máquina, el día, la hora o quién ejecute las pruebas.
Junto con las pruebas unitarias, se establecerá también la métrica de cobertura de pruebas en el código. Los módulos de pruebas unitarias en general implementan componentes que calculan la cobertura, y entregan, de manera específica por archivo o general del proyecto, el porcentaje de cobertura. Estos informes pueden ser levantado por servicios externos como Codecov para ser expuestos y gestionados.
Elun considerará un software correctamente cubierto si el porcentaje de cobertura general oscila entre el 80% y 95%. Es importante considerar que el código a cubrir sea el generado y propio del servicio, y no el de sus bibliotecas o componentes.
Es sugerible que el constructor o proveedor implante en sus procesos de desarrollo el modelo Test Driven Development. Esto asegura:
Como producto de un buen desarrollo sobre TDD, se tendrán evidencias duras y concretas de que el software hace lo que tiene que hacer, con evidencia de sus casos. De cara a Elun o a terceros, es mucho más fácil corregir y mantener el código.
Los componentes cloud y el software programado está siempre sujetos a presentar comportamientos anómalos cuando aumenta significativamente la tasa de utilización, sobre todo cuando se implementan flujos asíncronos, paralelismo o escritura/lectura hacia almacenes de datos. En resumen, el comportamiento atómico de los flujos debe ser tan consistente como el comportamiento bajo presión.
Para certificar lo anterior, es requerimiento obligatorio considerar qué flujos son susceptibles a problemas con altos niveles de utilización y ejecutar las pruebas correspondientes para validarlo.
En Elun se utiliza las herramienta Taurus, para la orquestación de pruebas de carga, junto con BlazeMeter, par ala generación de informes de este tipo de pruebas.
Las pruebas de estrés deben ser conceptualizadas por el integrador considerando de manera exhaustiva los casos de uso, validada por el equipo de arquitectura de Elun y ejecutadas para generar su evidencia.