Quel est le morceau de code le plus important que vous avez écrit et comment l'avez-vous abordé?

Question

En d'autres termes: quel code avez-vous écrit que ne peut pas échouer. Je suis intéressé à entendre ceux qui ont travaillé sur des projets portant sur les moniteurs cardiaques, les analyses de l'eau, les fondements économiques, les trajectoires des missiles ou la concentration d'O2 dans la navette spatiale.

Comment vous êtes-vous préparé à écrire ce type de code: méthodologiquement, intellectuellement et émotionnellement?

Modifier

J'ai marqué ce wiki au cas où le problème de représentant est empêcher les gens de répondre. Je pensais qu'il y aurait beaucoup plus de perspective sur cette question qu'il n'y en a eu.

Answer 1

Bien que je ne sois pas personnellement impliqué dans ce qui est décrit ici, cet article contribuera, je l'espère, à l'esprit de votre question: They Write the Right Stuff.

Answer 2

En ce moment, je travaille sur un code de base pour un système qui récupère les informations médicales des patients dans les cliniques et les hôpitaux pour un bureau de facturation médicale. Nous commençons avec un client plus petit et une longue période de rodage pour assurer la qualité, mais finalement ce code doit gérer en toute sécurité une grande variété de formats de rapports à partir d'un certain nombre de clients dans différentes installations. Ce n'est pas tout à fait à la même échelle que vos exemples, mais une mauvaise erreur pourrait se traduire par la facturation de mauvaises personnes ou la facturation de la mauvaise adresse (falsification des rapports de solvabilité) ou l'ouverture à l'usurpation d'identité, donc c'est encore assez critique. Oh oui, et cela pourrait signifier que les médecins ne sont pas payés aussi rapidement. Cela est également important, surtout du point de vue commercial, mais pas dans la même catégorie que la protection et l'intégrité des données. J'ai écrit l'interface d'ordinateur à une machine d'IRM.

Answer 3

Il n'avait aucune chance de blesser l'utilisateur final car il ne s'agissait que de gestion des dossiers, mais il pouvait potentiellement avoir donné un diagnostic incorrect ou omettre des informations importantes.

Tests, lots et beaucoup de tests.

Tests unitaires, tests de niveau moyen et élevé. Simuler toutes les combinaisons d'entrée possibles. Aussi beaucoup de tests avec le matériel lui-même. Les tests doivent être effectués de manière complète et méthodique. Cela devrait prendre beaucoup plus de temps à tester qu'à écrire.

Rapport d'erreurs

Toutes les erreurs doivent être signalées et être évident. Si cela ne fait pas de mal au brevet de le faire, échouez rapidement.

Pour quelque chose qui maintient activement une personne en vie, les choses sont encore pires. Il ne doit jamais cesser de fonctionner. Si cela échoue, il doit redémarrer et continuer à essayer. Les composants internes redondants sont également indispensables en cas de panne du matériel. Dans la mauvaise entreprise, il peut vraiment être difficile de travailler. Cependant, si tout va bien, vous êtes bien financé et la pression de relâchement n'est pas élevée, cela peut être un espace de travail très gratifiant.

Answer 4

J'ai écrit un pilote pour un appareil de mesure de la tension artérielle à usage hospitalier. En cas d'échec, le patient ne verra pas sa pression artérielle vérifiée à l'heure prévue; Si sa tension artérielle est anormale, aucune alarme (dans le système plus grand) ne sera déclenchée. Un tel événement pourrait être cliniquement significatif.

Mon approche consistait à lire complètement la spécification/documentation dans un environnement non-travail (pour éviter la tentation de commencer à coder tout de suite), puis le relire au travail. Après cela, j'ai résumé les états possibles et les actions sur papier et ai "tracé" un algorithme, et j'ai annoté tous les "mauvais événements" potentiels du monde réel (câbles débranchés, piles en train de mourir, etc.). Enfin, j'ai écrit et réécrit le pilote trois fois, chacun avec des mécanismes différents (par exemple FSM), et j'ai comparé leurs résultats. Chaque itération m'a aidé à identifier les faiblesses que je n'avais pas encore découvertes. La troisième réécriture était le résultat "officiel". J'ai examiné chaque itération avec mon collègue.

La préparation émotionnelle consistait à me convaincre que si l'impensable se produisait, au moins je n'étais pas volontairement négligent - juste incompétent (l'ancienne excuse «je suis seulement humain»). ;-)

Answer 5

Pas vraiment une réponse, mais:

J'ai un ami qui écrit un logiciel de contrôle intégré pour les machines de chirurgie oculaire au laser. Lorsqu'il a lui-même subi une chirurgie oculaire au laser, il s'est assuré de consulter un ophtalmologiste qui utilisait le système de son entreprise. J'ai une grande admiration pour ce type. Je ne peux pas penser à un logiciel que j'ai jamais écrit et dont le niveau de qualité était suffisamment élevé pour que j'aie confiance en ma propre vision.

Answer 6

Bien que rien d'aussi important qu'une machine IRM ou un tensiomètre, j'ai été sollicité pour réécrire Blackjack quand je travaillais pour un fournisseur de jeux en ligne. Blackjack est de loin le jeu en ligne le plus populaire, et des millions de dollars allaient passer par ce logiciel (et l'ont fait).

J'ai écrit le moteur de jeu séparément du serveur et du client, et j'ai utilisé le développement piloté par les tests pour m'assurer que ce que je supposais était perceptible dans les résultats. J'ai également eu un wrapper "serveur" qui avait une sortie console qui me permettrait de jouer. C'était en fait seulement utile car il imitait l'interface réelle du serveur, puisque jouer une version texte de blackjack n'est pas très amusant ou facile ("Vous dessinez un 10. Vous avez maintenant un 10 et un 6, tandis que le concessionnaire a un 6 [bsd]> ")

Le jeu est toujours en cours sur certains sites, et à ma connaissance, n'a jamais eu de bugs financiers après des années de jeu.

Answer 7

J'ai entendu des histoires folles des processus utilisés pour écrire du code à la NASA pour les navettes spatiales. Chaque ligne de code a environ 10-20 lignes de documentation, avec des tests, l'historique complet des révisions, etc. Chaque fois qu'un bogue est trouvé, non seulement le code est évalué et réparé, mais toute la procédure d'écriture de code, la commande entière chaîne, etc. est passée en revue pour répondre à la question: "Qu'est-ce qui s'est passé dans notre processus qui a permis à ce bug d'être inclus en premier lieu?"

Answer 8

Mon premier travail «réel» de logiciel était l'écriture d'une application GUI pour la planification de la chirurgie stéréotaxique du cerveau. Tester, tester, tester ... absolument pas de méthodes formelles, des pensées de style ingénieur, juste des programmeurs plus jeunes. Quand ils ont commencé à parler de l'utilisation du logiciel pour contrôler un bras robotisé avec un laser, sans aucune méthode d'ingénierie sérieuse en place, je me suis un peu inquiété, je suis parti pour plus de bureaux.

Answer 9

J'ai créé l'application du système d'information pour les cultures de gouvernement local et du tourisme dans l'île de Bali qui ont été installés dans plusieurs denstinations touristiques, fournissant des informations importantes sur la culture, des cartes, hébergement, etc.

si elle a échoué alors probablement les touristes ne pouvaient pas obtenir les bonnes informations dont ils ont le plus besoin, tricher par les coureurs, ou perdu quelque part :)