De acuerdo con este artículo de ACM, las siete construcciones de codificación que han sido la fuente más frecuente de los errores son las llamadas a funciones, tareas, condiciones, punteros, los usos de NULL, declaraciones de variables, declaraciones de funciones, y las declaraciones de retorno. Hay docenas de otras presentaciones en conferencias, libros y taxonomías que proporcionan orientación estadísticamente válida -o por lo menos opiniones- sobre las prácticas de codificación a evitar.

Pero hasta ahora, no he encontrado nada de eso para la codificación en la nube.

Y no se equivoque al respecto, el entorno distribuido -multi-lenguaje- inherente a la nube presenta algunos desafíos reales de codificación. Pero antes de que profundicemos en el tema por completo, hagamos un poco de triaje. Hay tres categorías interesantes de gusanos:

• Aquellos creados y encontrados durante la codificación y la integración inicial.
• Los que se encuentran antes de la implementación (es decir, durante la UAT, los candidatos de vista previa, y las pruebas finales de producción).
• Aquellos que solo se encuentra después de la implementación, que por lo general no han sido arreglados por el desarrollador original.

Si bien todos los gusanos son molestos, ha sido ampliamente documentado que la primera categoría es mucho menos costosa de resolver… y esos gusanos intramurales no disminuyen la credibilidad del equipo de desarrollo o del sistema en el que están trabajando. Los gusanos verdaderamente peligrosos son los últimos que podrían tener dos órdenes de magnitud más cara para repararse y causar fallas que están a la vista de los usuarios.

Vayamos un poco más allá. Los gusanos de la primera categoría son típicamente errores lógicos que pueden ser capturados por las herramientas y pruebas automatizadas. Los gusanos de la última categoría son causados por las debilidades humanas: comunicación imprecisa, documentación incompleta, fallas de memoria, las curvas de aprendizaje, manejo incompleto de errores, dejadez y pereza ante la presión. No hay herramientas de software que puedan arreglar la lista de lavandería, por lo que la clave es evitar los problemas de codificación que hacen que su proyecto sea más vulnerable ante esas debilidades humanas de codificación.

Así que vamos a inyectar algunos ejemplos humorísticos:

Evite todas las prácticas de codificación descritas en esta página.

Manténgase alejado de estas 5 ideas básicas.

No siga los procesos de gestión de proyectos que se describen aquí.

Mantenga sus proyectos Agile lejos de estos asesinos silenciosos.

Torre de Babel

En las más ambiciosas plataformas en la nube proliferan las opciones de idiomas, y para una complicada aplicación de Salesforce.com, sus desarrolladores tendrían que trabajar en seis idiomas a la vez (sí, en serio). Así que el consejo #1 es: No cambie idiomas frívolamente, ya que la depuración entre lenguajes es dolorosa. Si hay alguna biblioteca maravillosa de matemáticas en Python, realmente necesita utilizarla, encapsularla como un servicio Web y llamarla a través de REST.

Algunos lenguajes son más propensos a errores (o a tentar la decantación del desarrollador) que otros. Los idiomas con una gran escritura variable y de administración de memoria automática/recojo de basura, ayudan a evitar una amplia gama de errores. Por el contrario, se han escrito un sin fin de artículos sobre VB y C ++, pero incluso si se encuentra con ellos de la nube, trate de contener su maldad dentro de un servicio Web con el que no necesite trabajar en absoluto.

En la nube, probablemente su equipo funcione en Javascript y sus infinitas bibliotecas, y eso los hace vulnerables a la debilidad del tipeo de ese idioma, y una sensibilidad excesiva. El camino al infierno está empedrado con el medio excluido. Obtenga los mejores depuradores y herramientas de análisis estático que pueda. Si puede pasarse a lenguajes como Ruby on Rails, desaparecerán una serie de problemas.

Sepa que los errores costosos son los que alguien más va a arreglar

El peor de los errores será ubicado y corregido por alguien que no sea usted en algún momento en el futuro cuando tenga que extender la funcionalidad del sistema.

Aquí hay algunos consejos para hacer más fácil su trabajo:

Las expresiones más sencillas y los métodos más simples siempre ganan. Lo que piensa de la elegancia y la sofisticación pura es probable que sea visto por otros como incomprensible. Cualquier método que sea demasiado complicado para funcionar en su cabeza es demasiado largo.

La legibilidad del código es más importante que la compacidad. El uso abundante de espacios y saltos de línea puede hacer que algunos errores sean mucho más fáciles de detectar. No haga trucos como este algoritmo de descifrado CSS en línea.

Los comentarios en el código son un asunto de gran debate, en particular entre la gente de Clean Code. Pero una cosa que no es discutible: los comentarios engañosos son peores que todo. Idealmente, usted debe actualizar los comentarios de la misma manera que actualiza el código de prueba y la prueba vectores -como requisito antes de comprobar en el código. Si no puede mantener los comentarios en un módulo que está cambiando, sáquelos.

En la carrera por terminar un prototipo, los desarrolladores pueden pasar por alto algunos aspectos básicos en particular, ya que pueden estar trabajando en varios idiomas a la vez. El siguiente consejo es hacer siempre las siguientes comprobaciones de datos básicos antes de realizar cualquier operación:

Variables nulas o indefinidas

Cadenas vacías

Cadenas ridículamente largas

Los caracteres “ilegales” en las cadenas

Los intervalos numéricos

Matriz fuera de los límites

Fecha vs. fecha-hora

Un corolario de este consejo es tener cuidado con (y erradicar) los datos de la sobrecarga que algún genio deslizó en una “solución rápida” que fue olvidada hace tiempo.

Algunos cálculos y operaciones lógicas parecen alentar a los gusanos con más frecuencia de lo normal. Algunos de ellos no se pueden evitar, por lo que el siguiente consejo es presupuestar suficiente tiempo para desarrollar el código de prueba, escenarios y datos para probar a las personas mal intencionadas con el fin de obtener resultados adecuados (no solo de cobertura):

Declaraciones anidadas IF / THEN / ELSE (trate de utilizar CASE o SWITCH en su lugar).

Compuestos Booleanos (sobre todo relacionados con XOR, NOT, lessThan o GreaterThan).

Expresiones Regex.

Cálculos de días / fechas, especialmente fines de semana y días festivos (si el idioma en el que se está trabajando no tiene primitivas para esto).

Cálculos de la hora del día, especialmente los que implican “horas de oficina”.

Índices calculados para las matrices y listas.

Ramas calculadas (o, Dios no lo quiera, GOTO).

Roll-ups condicionales (sobre todo cuando se tiene plazos de entrega o necesita roll-ups sobre ventanas de tiempo).

Análisis multidimensionales (añada esto al almacén de datos, en lugar de codificarlo).

Transformaciones 3D coordinadas (con suerte, podrá utilizar una biblioteca para esto).

Cálculos Geoespaciales (ídem).

Código específico del navegador (en particular para Javascript y CSS … trate de utilizar una biblioteca de manejar esto).

Código específico para dispositivo móvil (en particular para los gestos, otros interactores y controladores específicos de OS para los mapas, libretas de direcciones, etc.).

No conocer el código IoT.

Código dinámico.

Métodos de tiempo de espera / reintento.

Y el abuelo de todos ellos: el código de control de errores.

Espagueti: Bueno para la cena, malo para el código

El hecho de que la nube aísle el código dentro de los servicios Web no significa que impida su ‘espaguetización’, sobre todo cuando los módulos se extienden a hacer cosas que nunca se previeron en el momento de la construcción inicial. El siguiente consejo: utilice perfiladores y rastreadores de tráfico de red para detectar en particular los servicios Web “habladores” que pueden indicar los métodos que necesitan refactorización.

El espagueti final (¿meta-Ghetti?) viene cuando hay una implementación incompleta de los cambios a través de varios módulos. Las cosas parecen funcionar, pero habrá errores efímeros que nunca ha visto antes y no puede reproducir su sistema de estadificación. Impulsar la producción en grandes sistemas de nubes es doloroso, y nunca he visto un sistema automatizado con múltiples plataformas en la nube (por ejemplo, AWS y Salesforce)… a pesar de que en teoría debería funcionar. Así que aquí está la última serie de recomendaciones:

* Todos los códigos, recursos y los artefactos de prueba para todos los nodos de servicio Web se gestionan por un único sistema de control de código fuente. Si tiene que utilizar más de un sistema de control, es necesario punteros de coordinación para mantener un estado determinista para todo lo requerido por cada una de las revoluciones de su aplicación en la nube.

* Si depende de archivos DLL de Windows o JVM para uno o más de sus nodos, mantenga ese sistema bajo un control serio (sí, desactive las actualizaciones automáticas). Considere el uso de máquinas virtuales para todos los nodos en una nube híbrida.

* Elabore una lista exhaustiva de todas las etapas de implementación (incluyendo “roll backs”) para que pueda evitar este nivel particular de demonios.

Lo que es viejo es nuevo otra vez

<p>Si todo esto parece una refundición de temas, desde el siglo pasado, no puedo estar en desacuerdo. Hacemos formas cada vez más sofisticadas para desperdiciar ciclos de CPU y desarrolladores.

-David Taber, CIO (EE.UU.)