您编写的最关键的代码是什么？您是如何处理它的？
换句话说：您编写的哪些代码不会失败。 我很想听听那些从事过心脏监测器、水测试、经济基础、导弹轨迹或航天飞机氧气浓度等项目的人的意见。
您是如何准备编写此类代码的：方法上、智力上和情感上？
编辑
我已标记此维基，以防代表问题阻碍人们回复。 我认为对于这个问题将会有比以往更多的观点。
Put it another way: what code have you written that cannot fail. I'm interested in hearing from those who have worked on projects dealing with heart monitors, water testing, economic fundamentals, missile trajectories, or the O2 concentration on the space shuttle.
How did you prepare for writing this sort of code: methodologically, intellectually, and emotionally?
Edit
I've marked this wiki in case the rep issue is keeping people from replying. I thought there would be a good deal more perspective on this issue than there has been.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
虽然我个人没有参与其中所描述的内容，但本文有望有助于您的问题的精神： 他们写了正确的东西。
While I am not personally involved in what is described there, this article will hopefully contribute to the spirit of your question: They Write the Right Stuff.
我为医院使用的血压测量设备编写了一个驱动程序。 如果“失败”，患者将不会在预定时间测量血压； 如果他的血压异常，则不会触发警报（在较大的系统中）。 这样的事件可能具有临床意义。
我的方法是在非工作环境中彻底阅读规范/文档（以避免立即开始编码的诱惑），然后在工作中再次阅读。 之后，我在纸上总结了可能的状态和动作，并绘制了算法的“流程图”，并注释了现实世界中所有潜在的“不良事件”（电缆被拔掉、电池耗尽等）。 最后，我对驱动程序进行了三次编写和重写，每次都采用不同的机制（例如FSM），并比较了它们的结果。 每次迭代都帮助我发现了我尚未发现的弱点。 第三次重写是“官方”结果。 我和我的同事一起审查了每次迭代。
情感准备包括说服自己，如果不可想象的事情发生，至少我不是故意疏忽——只是无能（古老的“我只是人类”借口）。 ;-)
I wrote a driver for a blood pressure measuring device for hospital use. If it "fails", the patient will not have his blood pressure checked at the scheduled time; if his blood pressure is abnormal, no alarm (in the larger system) will be triggered. Such an event could be clinically significant.
My approach was to thoroughly read the spec/documentation in a non-work environment (to avoid the temptation to start coding right away), then read it again at work. After that, I summarized the possible states and actions on paper and "flowcharted" an algorithm, and annotated all the potential real-world "bad events" (cables getting unplugged, batteries dying, etc). Finally, I wrote and rewrote the driver three times, each with different mechanisms (e.g. FSM), and compared their results. Each iteration helped me identify weaknesses I hadn't yet discovered. The third rewrite was the "official" result. I reviewed each iteration with my co-worker.
Emotional preparation consisted of convincing myself that should the unthinkable happen, at least I wasn't willfully negligent -- just incompetent (the old "I'm only human" excuse). ;-)
我已经编写了 MRI 机器的计算机接口。 它不可能伤害最终用户，因为它只是记录管理，但它可能会给出错误的诊断或遗漏重要信息。
测试，很多很多的测试。
单元测试、中级和高级测试。 模拟所有可能的输入组合。 还对硬件本身进行了大量测试。 测试必须以完整且有条理的方式进行。 测试应该比编写花费更多的时间。
错误报告
所有错误都必须报告并且是明显的。 如果这样做不会损害专利，那就尽快失败。
对于那些积极维持人生命的事物来说，情况更糟。 它绝不能停止工作。 如果失败，则需要重新启动并继续尝试。 冗余内部结构也是必须的，以防硬件出现故障。
在错误的公司工作确实会是一种困难的情况。但是，如果事情进展顺利，资金充足并且释放压力不高，那么这可能是一个非常有价值的工作空间。
I have written computer interface to a MRI machine. It had no chance of hurting the end user as it was just record management, but it could potentially have given an incorrect diagnosis or omit important information.
Tests, lots and lots of tests.
Unit tests, mid and high level tests. Simulate all possible input combinations. Also a great deal of testing with the hardware itself. Testing must be done in a complete and methodical way. It should take a great deal more time to test than to write.
Error Reporting
All errors must be reported and be obvious. If it won't hurt the patent to do so, fail fast.
For something that is actively keeping a person alive things are even worse. It must never stop working. If it fails it needs to restart and keep trying. Redundant internals are also a must in case the hardware fails.
At the wrong company it can really a difficult kind of situation to work in. However, if things are going well, you are well funded and release pressure is not high, it can be a very rewarding space to work in.
这并不是一个真正的答案，但是：
我有一个朋友为激光眼科手术机编写嵌入式控制软件。 当他自己进行激光眼科手术时，他一定要去找使用他公司系统的眼科医生。 我非常钦佩这个人。 我想不出我曾经编写过的任何一款软件的质量水平足以让我相信自己的眼光。
Not really an answer, but:
I've got a friend who writes embedded control software for laser eye surgery machines. When he had laser eye surgery himself, he made sure to go to an ophthalmologist who used his company's system. I have great admiration for this guy. I can't think of a piece of software I've ever written whose level of quality was high enough that I'd trust my own eyesight to it.
现在，我正在为一个系统编写一些基本代码，该系统为医疗计费办公室从诊所和医院检索医疗患者信息。 我们从较小的客户端开始，并需要较长的磨合期来确保质量，但最终此代码需要安全地处理来自不同设施的多个客户端的各种报告格式。
它与您的示例的规模不太一样，但一个严重的错误可能会导致错误的人被计费或正确的人被计费到一个失效的地址（搞砸信用报告）或让人们面临身份盗窃，所以它仍然很漂亮批判的。 哦，是的，这可能意味着医生不会那么快得到报酬。 这也很重要，尤其是从业务角度来看，但与数据保护和完整性不同。
Right now I'm working on some base code for a system that retrieves medical patient information from clinics and hospitals for a medical billing office. We're starting out with a smaller client and a long break-in period to ensure quality, but eventually this code needs to securely handle a large variety of report formats from a number of clients at different facilities.
It's not quite in the same scale as your examples, but a bad mistake could result in the wrong people being billed or the right person billed to a defunct address (screwing up credit reports) or open people up to identity theft, so it's still pretty critical. Oh yeah, and it could mean doctors don't get paid quite as quick. That's important, too, especially from a business perspective, but not in the same class as data protection and integrity.
我听说过关于在 NASA 为航天飞机编写代码的过程的疯狂故事。 每行代码都有大约10-20行文档，以及测试、完整的修订历史记录等。每次发现错误时，不仅会评估和修复代码，还会评估和修复整个代码的过程，整个命令审查链等以回答以下问题：“我们的流程中发生了什么错误，导致该错误首先被包含在内？”
I've heard crazy stories of the processes used to write code at NASA for the spaceshuttles. Every line of code has about 10-20 lines of documentation, along with tests, full revision history, etc. Every time a bug is found, not only is the code evaluated and repaired, but the entire procedure of writing code, the entire command chain, etc. is reviewed to answer the question: "What happened wrong in our process that allowed this bug to get included in the first place?"
虽然没有什么比 MRI 机器或血压监测仪更重要的了，但当我在一家在线赌博提供商工作时，我确实被邀请重写 Blackjack。 二十一点是迄今为止最受欢迎的在线游戏，数百万美元将通过该软件进行（并且确实如此）。
我将游戏引擎与服务器和客户端分开编写，并使用测试驱动开发来确保结果符合我的假设。 我还有一个包装器“服务器”，它具有控制台输出，可以让我玩。 这实际上只是有用，因为它模仿了真实的服务器界面，因为玩文本版本的二十一点不是很有趣或容易（“你抽到了 10。你现在有 10 和 6，而庄家有 6 [bsd] >”）
该游戏仍在某些网站上运行，据我所知，经过多年的游戏，从未出现过任何财务问题。
While nothing quite so important as an MRI machine or a blood pressure monitor, I did get tapped to do a rewrite of Blackjack when I worked for an online gambling provider. Blackjack is by far the most popular online game, and millions of dollars was going to go through this software (and did).
I wrote the game engine separate from the server and the client, and used Test Driven Development to ensure that what I was assuming was coming through in the results. I also had a wrapper "server" that had console output that would allow me to play. This was actually only useful in that it mimicked the real server interface, since playing a text version of blackjack isn't very fun or easy ("You draw a 10. You now have a 10 and a 6, while the dealer has a 6 showing. [bsd] >")
The game is still being run on some sites out there, and to my knowledge, has never had any financial bugs after years of play.
我的第一份“真正的”软件工作是编写一个用于规划立体定向脑部手术的 GUI 应用程序。 测试、测试、测试……绝对没有正式的方法、工程风格的思想，只是年轻的程序员把它搞出来。 当他们开始谈论使用软件来控制激光机械臂，而没有任何严肃的工程方法时，我有点担心，离开了更多的办公室。
My first "real" software job was writing a GUI app for planning stereotactic brain surgery. Testing, testing, testing... absolutely no formal methods, engineering-style thoughts, just younger programmers cranking it out. When they started talking about using the software to control a robotic arm with a laser, without any serious engineering methods in place, i got a bit worried, left for more officey lands.
我为巴厘岛当地政府文化和旅游部门创建了信息系统应用程序，该应用程序安装在多个旅游目的地，提供有关文化、地图、住宿等的广泛信息。
如果失败，那么游客可能无法获得他们需要的正确信息大多数，被布鲁克斯欺骗，或者迷失在某个地方:)
I've created information system application for local government cultures and tourism department in Bali island which were installed in several tourism denstinations, providing extensive informations about the culture, maps, accomodations etc.
if it failed then probably tourists couldnt get the right informations they need most, cheat by brookers, or lost somewhere :)