|
|
3 回复 | 直到 11 年前
|
1
2
这是一个非常复杂的问题。虽然美国国家航空航天局确实为生命关键系统或必须远距离运行的机器人系统提供了高质量的代码(想想最近在“旅行者2号”上安装的软件,距离地球13个小时),但美国国家航空航天局的质量并不便宜,也不快。一行接一行,它可能是业界最昂贵的软件。 企业中的基本报表应用程序不需要这种质量。它也不具有成本效益。提高质量的方法有很多,从简单和廉价(编码标准)到资源密集型、困难和非常耗时(每种方法都有书面的、正式的数学证明)的成本各不相同。 项目管理工具,如风险评估、项目事后分析和持续改进,可以帮助组织达到一套合适的质量实践。 不必指责某个特定行业,我会说,就质量而言,最具破坏性的做法是时间压力。没有什么比严格的人为截止日期更能诱使程序员编写草率的代码了。 提高质量的要求是什么? 沟通至关重要。团队中的每个开发人员都应该知道其他开发人员正在做什么,至少在广泛的范围内是这样。 第二,理解质量从项目验收之日开始。需要理解和验证需求。关键因素包括确保需求识别出要解决的问题,而不是使用建议的解决方案来避免问题定义;确保需求是可度量的并且足够具体,开发人员和客户都能够识别出解决方案满足需求;确保需求与需求的所有消费者(包括开发人员、测试人员、技术编写人员、支持人员和管理人员)进行清晰的沟通。质量最好是根据明确规定的要求来衡量的;如果你的要求不明确,那么质量最好是HAP危害。 评论至关重要。不仅仅是代码评审,还有需求分析、设计,也许最重要的是测试计划。测试的作用是验证是否满足了要求。您不能测试坏的或不存在的需求。 这将导致理解测试的作用。你不能在产品中测试质量。测试可以验证质量。测试可以发现缺陷并确认它们已经修复。但是如果质量实践一直没有被跟踪到测试开始的时候,测试就不能解决这个问题。 虽然我不喜欢瀑布式开发模型,但我认为敏捷开发可以将事情推向另一个极端,并且很容易以损害质量的方式被滥用。我认为Scrum有助于缓解敏捷的一些问题;Scrum促进了团队内部的沟通,它认识到评估只不过是有根据的猜测,随着知识的提高,这些猜测可以被改进。 |
|
|
2
4
我一直很喜欢 "They Write the Right Stuff" 详细介绍了NASA承包商的软件开发过程。 航天飞机软件绝对是最后一个你想看到你的错误持续存在的地方!
我想说的是网络。主要是因为它非常容易部署,许多更新/修复可以在没有客户通知(或输入)的情况下完成。与盒装软件相比,似乎有一种更放松的心态。 |
|
|
3
3
不得不说银行写的是最糟糕的代码——他们需要各种定制的解决方案,但写代码并不是他们的主要关注点,所以他们倾向于选择“以某种方式让它工作”。再加上把代码当作一个小部件来处理,你可以把它发送给出价最低的人,结果出来的东西真的是值得畏惧的。 当然,在这些银行中,不同的银行、不同的组织、不同的组织,这是不同的,但总的来说,我看不出有太多的质量代码出现。作为一个在银行工作了10年的人,我认为自己是一个蹩脚的银行软件专家。 |
推荐文章