¿Puedes crear un error a propósito?

Nosotros, los desarrolladores, nos encontramos con errores con regularidad, es solo parte de nuestro trabajo. Por lo tanto, a primera vista, la pregunta "¿Se puede crear un error a propósito?" Puede parecer banal: "Sí, por supuesto, puedo escribir un error". Sin embargo, si lo piensas bien, ya no todo parece tan obvio.

El hecho es que el error no es lo mismo que el código roto . Un error es un error, una falla en un sistema generalmente

programa de trabajo.

¿Cuál es el problema?

Se sabe que el mundo está bien descrito mediante fórmulas matemáticas. Y las fórmulas son en realidad los algoritmos. Por lo tanto, si pudiéramos describir matemáticamente algún fenómeno, entonces corregir la fórmula resultante para que solo a veces dé un resultado incorrecto no es una tarea trivial. Sin embargo, no es momento de desesperarse. Las condiciones límite pueden venir a ayudarnos aquí. Todos los hemos visto if index == 0 {…} else if index == n-1 {…} . Siempre hay algo mal con los límites 🤷‍♀️. Entonces, observemos la primera idea para crear un error: ignorar los casos extremos .

En general, la iteración a través de matrices es un almacén de errores potenciales. Y el más común de ellos es el índice fuera de límites . Si nunca te has topado con algo así, nunca has codificado. Desafortunadamente, este error es tan popular que la gente comenzó a escribir contenedores seguros para matrices, algo así como array[safe: index] . Así que hoy en día, tus colegas difícilmente aprobarán ningún código sin esto. Puedes intentarlo, pero es poco probable...

Los errores frecuentes incluyen el desbordamiento de pila . Un algoritmo recursivo puede repetirse infinitamente cuando no existe una condición de salida. La recursividad parece opcional aquí: escriba while true y listo. Sin embargo, una vez más, la popularidad del error juega en nuestra contra. Los desarrolladores son muy conscientes de los problemas potenciales de los bucles sin fin, y sus ojos definitivamente se darán cuenta de algo como esto en la revisión del código 👮

Para seguir impulsando su insidioso plan a producción, intente utilizar una variable global para las condiciones de salida y cámbiela silenciosamente desde el exterior .

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

Consejos generales

Es curioso que incluso ChatGPT se niegue a ayudar cuando se trata de escribir errores. Quizás solo necesito una suscripción premium… 🤔

Lo positivo es que la IA ofrece un conjunto de reglas generales que contribuyen a escribir código sin errores: codificar en pequeños incrementos, seguir estándares de codificación, escribir pruebas unitarias y bla-bla-bla. Podemos intentar hacer lo contrario: escribir código espagueti y olvidarnos de SOLID. Sin embargo, de esta forma perdemos el control sobre todo el código que escribimos. En lugar de un arma elegante y puntiaguda, obtenemos un caos inmanejable que conquistará nuestro programa.

Al resolver el problema de crear un error, vale la pena determinar las subtareas. Primero, necesitamos encontrar algunos casos extremos poco comunes. En segundo lugar, debemos disfrazar el error como código normal para que pase la revisión del código. En tercer lugar, tenemos que desviar la atención del departamento de control de calidad. Cuarto, no se deje atrapar de inmediato. Pero esto ya es opcional.

Mi consejo general es el siguiente (y tú compartes el tuyo en los comentarios):

• Manipular el nivel de acceso . Para retroceder, cambie los valores de parámetros importantes desde los lugares más inesperados. Hazlo a través de varias clases como si fueras una VPN.

• Implemente alguna lógica inesperada en la clase secundaria. En resumen, rompa el principio L en SOLID .

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• Oculte sus cambios insidiosos en funciones más importantes. Cuantas más colas, mejor : piérdete entre la multitud.

• Utilice el mismo principio en las solicitudes de extracción. En un PR pequeño, la probabilidad de hacerse notar es mayor.

• Intente dividir el error en partes y colóquelas en diferentes solicitudes de extracción . Si es posible, también a diferentes revisores.

• Encuentre las debilidades de su control de calidad y gane su confianza. O distraerlos con conversaciones durante el control.

Por cierto, ¿has oído hablar de Heisenbug? Este es un error que desaparece o cambia su comportamiento durante la investigación/ depuración . Como el gato de Schrodinger. Perfecto si no se le asignará el problema solucionado.

Puede

¡Creer en ti mismo! La historia conoce ejemplos de casos en los que un error fue admitido en producción en empresas muy serias.

Vuelo 501 del Ariane 5: Uno de los errores de software más costosos se produjo en 1996, cuando el cohete Ariane 5, que llevaba la misión Cluster, explotó apenas 40 segundos después del despegue. La falla se debió a un error de software en el sistema de guía del cohete.

Mars Climate Orbiter de la NASA: En 1999, la NASA perdió el Mars Climate Orbiter debido a un error de software. El software utilizó unidades imperiales (libra-segundo) en lugar de unidades métricas (newton-segundo), lo que provocó que la nave espacial se quemara en la atmósfera marciana.

Además, algunos errores pueden convertirse en características, como el salto de pared en Mario o el comportamiento de Mahatma Gandh en Civilization ... probablemente.

Desarrollar un error es la capacidad de pensar en su algoritmo y anticipar posibles problemas a fondo. Por lo tanto, incluso si no tiene motivos para dejar un error en el código, vale la pena considerarlo.