¿Cuál es el error más devastador que un programador podría cometer involuntariamente?

Answer 1

Para mí, los errores que recuerdo no se debieron a la programación, sino a un trabajo administrativo colateral, como quitar una base de datos en vivo varias veces y perder algunas horas de eventos (hubo una copia de seguridad), o golpear demasiado a un equilibrador Algunas veces, lo que hizo que los sistemas en vivo perdieran tráfico, no solo de mi empresa 🙂

Creo que los problemas reales aparecen en los sistemas de soporte de la vida. Esos son sistemas que pasan por muchas capas de prueba y, si existe un riesgo real, la administración debe asegurarse de que los errores sean improbables, no solo usted.

Como conclusión, en lugar de evitar los errores, abrácelos, es decir, céntrese en el crecimiento y en el fracaso, los errores son parte de su camino hacia un programador inteligente. Debe pensar, intentar mucho, iterar rápidamente sus intentos para que la mayoría de los errores se detecten pronto mediante pruebas unitarias, no tarde en la producción, perdiendo datos, dinero.

Su trabajo es realizar pruebas para su código, pero necesita experimentar mucho con ese código si desea aprender y comprender, de modo que conlleve un riesgo, que es necesario para el progreso.

Como pensamiento final, una manera de aceptar los “errores” es esta: erlang es la plataforma más robusta del mundo: ¿cómo hace eso? asume que los programas fallarán y que los programas se componen de millones de pequeñas tareas aisladas. cuando una tarea falla de alguna manera, no afectará a las otras. Devops es otra tendencia que mezcla a las personas de desarrollo con las personas de operaciones y hacen monitoreo, copias de seguridad, orquestación y una gran cantidad de mitigación de riesgos y mecanismos de protección o degradación elegante del servicio ante bombas imprevistas que se disparan en la producción. Como puede ver, a los gerentes y operadores también se les asigna la administración de riesgos, para que pueda concentrarse en crear un gran software.

Answer 2

Hay docenas de pequeños errores que son bastante comunes, como errores off-by-one (comienzas a iterar en una lista y empiezas en el índice 1 cuando deberías haber comenzado en el índice 0, o te detienes antes de llegar al final de la lista, o si pierde el final de la lista e intenta seguir avanzando una posición más, etc.)

Las referencias de puntero nulo son bastante comunes (está intentando hacer algo con datos que no se han cargado en la memoria o que ya se han descargado de la memoria cuando intenta verlos).

Así que hay muchas formas conocidas de cometer un error. Pero lo devastador que puede ser un error depende en gran medida de para qué se utilice el software. Y dado que el software se está volviendo cada vez más ubicuo, las consecuencias de los errores son cada vez más grandes. Creo que la referencia de Josh Begleiter a las tragedias aritméticas por computadora es un gran enlace para tener una idea de cómo el software ha fallado, pero agregaría que hay un tipo particular de problema que es especialmente devastador, y ese es el problema que no se nota hasta Ha estado alrededor por mucho tiempo.

Si tiene un error en su código que está corrompiendo o destruyendo datos de una manera que no detecta, entonces, mientras más tiempo esté presente ese error, más devastador será.

Answer 3

Si mantiene las proporciones adecuadas, puede comparar los programadores que construyen la lógica / código con los cirujanos que realizan una cirugía. Entonces, ¿cuál es el error más devastador que un cirujano podría cometer sin querer? No puedo imaginar todas las cosas que podrían estar mal, pero al final es solo: dejar que el paciente muera de alguna manera .

La peor consecuencia debida a los errores que un programador podría hacer es: hacer que la compañía pierda dinero de alguna manera .

¿Como hacemos eso? No puedo imaginar todas las cosas que podrían estar mal, pero aquí van algunos casos que he visto:

• datos perdidos :

• drop table user_accounts;
• delete from orders where due_date > current_date;

errores de matemáticas:

• interest_value = due_value*round(interest_rate/100,0);
• interest_value = due_value*(interest_rate/1000); -- yes, this was the "fix" for the previous bug

malentendidos de negocios:

• if (due_date > current_date) apply_interest();

comentando la linea equivocada :

• -- commit;

Answer 4

Depende del contexto de su programación, pero echa un vistazo a la página Tragedias de aritmética por computadora de Kees Vuik para ver algunos ejemplos muy buenos de cómo los programadores de computadoras (y los diseñadores de chips) han causado algunos errores muy costosos.

Aquí hay otro conjunto de ejemplos causados ​​por errores en la programación: Los 15 errores peores del software de la computadora.

Para el programador promedio, es probable que esté relacionado con la seguridad. La falta de saneamiento de los datos es un error simple y fácil de cometer y puede crear vacíos de seguridad, como ejemplo.

Answer 5

Cree un agujero de seguridad significativo en su producto: hay ejemplos bien conocidos de empresas destruidas debido al hecho de que su equipo de ingeniería (operaciones y desarrollo) no gestionó las credenciales de forma adecuada, lo que permitió a los piratas informáticos ingresar al sistema y eliminarlo.

Answer 6

Los proyectos de software están organizados para que los desarrolladores no puedan hacer ningún daño.

Los desarrolladores no pueden tocar bases de datos en vivo. No pueden enviar su código en el control de código fuente a menos que haya pasado todos los controles puestos por el gestor de proyectos.

Examen de la unidad.

Revisión de código.

Pruebas de rendimiento.

No hay código enredado.

Etc.

E incluso si pasa todos los aros y aún tiene problemas, el código está en el control de la fuente, por lo que siempre puede volver al tiempo en que funcionó el código … Y aplicar los cambios lentamente … Para que pueda detectar cuál es El check-in ofensivo.

En otras palabras, el proyecto mánager puede arruinar un proyecto apurándose y no poniendo suficientes controles en su lugar. Los desarrolladores no pueden.

El control más importante es que hay un cliente dispuesto a pagar por el producto.

Es por eso que Agile hace las cosas bien. El criterio más importante es que el software se acostumbre.

Answer 7

Mal diseño o acceso a la base de datos. Un comerciante para el que trabajaba tenía una combinación de ambos. Su diseño permitió a un usuario realizar cambios que hicieron que todas las transacciones de numerosas tiendas no fueran identificables por tienda. Teniendo en cuenta que las declaraciones financieras y gubernamentales se realizaron a nivel de tienda, fue un desastre.