¿Cuál es la pieza de código más importante que has escrito y cómo te acercas?

Question

Ponlo de otra manera: ¿qué código has escrito que no puede error. Estoy interesado en escuchar a aquellos que han trabajado en proyectos relacionados con monitores cardíacos, pruebas de agua, fundamentos económicos, trayectorias de misiles o la concentración de O2 en el transbordador espacial.

¿Cómo te has preparado para escribir este tipo de código: metodológica, intelectual y emocionalmente?

Editar

He marcado este wiki en caso de que el problema es mantener representante de la gente de responder. Pensé que habría mucha más perspectiva sobre este tema que antes.

Answer 1

Si bien no estoy involucrado personalmente en lo que se describe allí, este artículo contribuirá con suerte al espíritu de su pregunta: They Write the Right Stuff.

Answer 2

En este momento estoy trabajando en un código base para un sistema que recupera información médica del paciente de clínicas y hospitales para una oficina de facturación médica. Estamos comenzando con un cliente más pequeño y un período de adaptación prolongado para garantizar la calidad, pero finalmente este código necesita de forma segura manejar una gran variedad de formatos de informes de una serie de clientes en diferentes instalaciones.

No está exactamente en la misma escala que sus ejemplos, pero un error grave puede ocasionar que se facture a la persona incorrecta o que se facture a una dirección difunta (atornillar informes de crédito) o abrir personas al robo de identidad. así que sigue siendo bastante crítico. Ah, sí, y podría significar que los médicos no cobran tan rápido. Eso también es importante, especialmente desde una perspectiva empresarial, pero no en la misma clase que la protección e integridad de datos.

Answer 3

He escrito la interfaz de la computadora a una máquina de MRI. No tenía ninguna posibilidad de perjudicar al usuario final, ya que solo era gestión de registros, pero podría haber dado un diagnóstico incorrecto u omitir información importante.

Pruebas, lotes y montones de pruebas.

Pruebas unitarias, pruebas de nivel medio y alto. Simula todas las combinaciones de entrada posibles. También una gran cantidad de pruebas con el hardware en sí. Las pruebas deben hacerse de forma completa y metódica. Debe tomar mucho más tiempo para probar que escribir.

de informe de errores

Todos los errores deben ser informados y ser obvio. Si no dañará la patente para hacerlo, fallará rápidamente.

Para algo que mantiene activamente viva a una persona, las cosas son incluso peores. Nunca debe dejar de funcionar. Si falla, necesita reiniciarse y seguir intentándolo. Los internos redundantes también son obligatorios en caso de que el hardware falle.

En la compañía equivocada, puede ser realmente difícil trabajar en una situación difícil. Sin embargo, si las cosas van bien, está bien financiado y la presión de descarga no es alta, puede ser un espacio muy gratificante para trabajar.

Answer 4

Escribí un controlador para un dispositivo de medición de la presión arterial para uso hospitalario. Si "falla", el paciente no verificará su presión arterial a la hora programada; si su presión sanguínea es anormal, no se activará ninguna alarma (en el sistema más grande). Tal evento podría ser clínicamente significativo.

Mi enfoque fue leer minuciosamente la especificación/documentación en un entorno que no sea de trabajo (para evitar la tentación de comenzar a codificar de inmediato) y luego volver a leerla en el trabajo. Después de eso, resumí los posibles estados y acciones en papel y "diagrama de flujo" un algoritmo, y anoté todos los posibles "malos eventos" del mundo real (cables que se desconectan, baterías que mueren, etc.). Finalmente, escribí y reescribí el controlador tres veces, cada una con diferentes mecanismos (por ejemplo, FSM), y comparé sus resultados. Cada iteración me ayudó a identificar debilidades que aún no había descubierto. La tercera reescritura fue el resultado "oficial". Revisé cada iteración con mi compañero de trabajo.

La preparación emocional consistió en convencerme a mí mismo de que si ocurría lo impensable, al menos no era intencionalmente negligente, sino incompetente (la vieja excusa de "soy solo humano"). ;-)

Answer 5

No es realmente una respuesta, pero:

Tengo un amigo que escribe incrustado software de control para máquinas de cirugía ocular con láser. Cuando tuvo cirugía ocular con láser, se aseguró de consultar a un oftalmólogo que usó el sistema de su compañía. Tengo una gran admiración por este tipo. No puedo pensar en una pieza de software que haya escrito, cuyo nivel de calidad sea lo suficientemente alto como para confiar en mi propia visión.

Answer 6

Aunque no hay nada tan importante como una máquina de resonancia magnética o un monitor de presión arterial, me hicieron tapping para hacer una reescritura de Blackjack cuando trabajaba para un proveedor de juegos de azar en línea. El Blackjack es, de lejos, el juego en línea más popular, y millones de dólares iban a ir a través de este software (y lo hicieron).

Escribí el motor de juego separado del servidor y el cliente, y usé Test Driven Development para asegurarme de que lo que asumía venía en los resultados. También tenía un "servidor" contenedor que tenía salida de consola que me permitía jugar. Esto solo fue útil porque imitaba la interfaz real del servidor, ya que jugar una versión de texto de blackjack no es muy divertido o fácil ("Sacas un 10. Ahora tienes un 10 y un 6, mientras que el distribuidor tiene un 6 mostrando. [bsd]> ")

El juego todavía se está ejecutando en algunos sitios, y que yo sepa, nunca ha tenido ningún error financiero después de años de juego.

Answer 7

He escuchado historias locas de los procesos utilizados para escribir código en la NASA para los espaciales. Cada línea de código tiene alrededor de 10-20 líneas de documentación, junto con pruebas, historial completo de revisiones, etc. Cada vez que se encuentra un error, no solo se evalúa y repara el código, sino que se procesa todo el procedimiento de escritura, todo el comando cadena, etc. se revisa para responder a la pregunta: "¿Qué sucedió mal en nuestro proceso que permitió incluir este error en primer lugar?"

Answer 8

Mi primer trabajo de software "real" fue escribir una aplicación GUI para planear la cirugía estereotáctica del cerebro. Pruebas, pruebas, pruebas ... absolutamente ningún método formal, pensamientos de ingeniería, solo programadores más jóvenes arrancándolo. Cuando comenzaron a hablar acerca de usar el software para controlar un brazo robótico con un láser, sin ningún tipo de métodos de ingeniería serios, me preocupé un poco y me fui a más oficinas.

Answer 9

He creado la aplicación del sistema de información para las culturas del gobierno local y departamento de turismo en la isla de Bali, que se instalaron en varios denstinations turismo, proporcionando amplias informaciones sobre la cultura, mapas, alojamiento, etc.

si fallaba entonces probablemente los turistas no pudieron obtener la información correcta que más necesitan, engañar por los arroceros, o perder en algún lugar :)