问哪些行业开发出最高质量的软件？最低质量？为什么？

EN

这是一个非常复杂的问题。虽然美国国家航空航天局( NASA )肯定会为生命关键系统或必须在很远的距离运行的机器人系统提供高质量的代码(想想最近对距离地球13光小时的旅行者2号( Voyager 2)的软件修复)，但美国国家航空航天局的质量并不便宜，也不快。逐行，它可能是业界最昂贵的软件。

企业中的基本报表应用程序不需要这种质量。它也不符合成本效益。有许多提高质量的方法，它们的成本从简单而廉价的(编码标准)到资源密集型的、困难的和非常耗时的(每种方法的书面、正式的数学正确性证明)都不同。

风险评估、项目事后检查和持续改进等项目管理工具可以帮助组织获得一套合适的质量实践。

在不针对特定行业的情况下，我会说，就质量而言，最具破坏性的做法是时间压力。没有什么比紧凑的、人为的截止日期更能诱使程序员编写草率的代码了。

对更好的质量有什么要求？

沟通是至关重要的。团队中的每个开发人员都应该知道其他每个开发人员都在做什么，至少在很大范围内是这样。

第二，理解质量从项目被接受的那一天开始。需要理解和验证需求。关键因素包括确保需求确定要解决的问题，而不是使用建议的解决方案来避免问题定义；确保需求是可衡量的和足够具体的，以便开发人员和客户都能够认识到解决方案满足需求；确保需求清楚地传达给所有需求消费者，包括开发人员、测试人员、技术作者、支持人员和经理。根据清晰的需求来衡量质量是最好的；如果你的需求定义得很差，那么质量充其量是偶然的。

评论是至关重要的。不仅仅是代码审查，还有需求分析、设计，也许最重要的是测试计划。测试的作用是验证需求是否得到了满足。你不能测试坏的或者不存在的需求。

这有助于理解测试的作用。你不能测试产品的质量。测试可以验证质量。测试可以发现缺陷并验证它们是否已经修复。但是，如果质量实践没有被跟进到测试开始的地步，测试就不能解决这个问题。

虽然我不是瀑布开发模型的粉丝，但我认为敏捷开发可能会将事情推向另一个极端，并且很容易被滥用，从而损害质量。我认为scrum有助于缓解敏捷的一些问题；scrum促进了团队内部的沟通，它认识到，评估只不过是经过深思熟虑的猜测，可以随着知识的改进而改进。

我一直很喜欢"They Write the Right Stuff"，它详细介绍了美国宇航局承包商的软件开发过程。

穿梭软件绝对是你最不愿意看到你的bug持续存在的地方之一！

另一方面，您认为哪些行业生产的软件质量最差？为什么？

我会说是网络。主要是因为它非常容易部署，许多更新/修复都可以在没有客户通知(或输入)的情况下完成。与盒装软件相比，似乎有一种更轻松的心态。

不得不说，银行写的代码最糟糕--他们需要各种各样的自定义解决方案，但编写代码并不是他们的主要关注点，所以他们倾向于“以某种方式让它工作”。再加上把代码当做一个小工具，你可以把它卖给出价最低的人，这样出来的东西才是真正值得畏缩的。

当然，这会因银行和组织的不同而有所不同，但总的来说，我没有看到很多高质量的代码出来。作为一个在银行工作了10年的人，我认为自己是一个糟糕的银行软件专家:)