软件质量对Application Developer来说真的很重要 - *实际上*?

时间:2009-08-06 04:02:39

标签: software-quality

  

软件质量真的很重要吗?   对于Application Developer的实践?

我知道这个问题似乎是最愚蠢的问题。但请看下面为什么我会问这个问题。

我喜欢这样的工程原理和模式,并且到目前为止一直在实施和享受。但现在我意识到这些原则对Application Developer来说无关紧要,但重要的是“开发时间”,“应用程序正常工作”和“完成但那没关系。“

我现在对应用程序开发人员的软件质量和原则的实际重要性感到困惑。因此,在我的所有时间指南之后寻找实际答案无法回答software quality impact organization和[设计代码质量的重要性] [2]

有很多信息可以讨论软件质量和软件工程,但实际上它们是在应用程序开发中实施的吗?

我问这个问题是一个应用程序开发人员而不是谈论操作系统,语言或编译器开发/创新。


谢谢大家的回复。让我更多地说明为什么我在第一时间提出这个问题。

我也相信并且认为在考虑这些原则时应该毫不犹豫。我认为这是一种艺术,策略无法根据某事进行切换。

但是如果你看到关于这个主题的任何内容或者说这篇文章,请注意诸如“取决于什么”之类的短语。现在的实际问题是谁能直接受益于这样的质量代码,除了你自己,这也是你的成圣,道德,道德。

让我们举一个非常普遍的例子;一个拥有数百万次点击的网站。最终用户很高兴,因为网站看起来很有吸引力,他们得到了订单管理层很高兴,因为开发/改进是在预算范围内完成的,所有功能都已实施。 PM很高兴,因为不知何故,团队及时交付了它。 Tech Lead很高兴,因为所有异构子系统都按预期进行通信,并且满足基础设施约束。由25名开发人员组成的团队感到高兴,因为所有错误都已修复,现在他们的代码正在运行;当然他们有信心,因为他们使用了类型安全的语言,很棒的IDE,他们会找到任何运行时错误的行号,因为try catch block无处不在。

在这里,我们可以说,他们没有遵循任何模式或最佳实践。因此代码不可重用或逻辑层依赖于数据格式或......但对于下一个开发,会有新的预算,新的开发计划和开发人员获得可能不符合过去任务的新任务。

通过遵循某些原则,谁直接受益或必须强制执行消除这些原则,可能需要在时间和预算方面支付一些额外费用?

然后谁会关心这些呢?每个人都知道它的理论重要性,但在实践中,它是“金色触摸”还是“有好处”特征或“必须具备”要求?如果它真的重要,那么正如许多人所说,为什么预算或时间被赋予最重要的意义,质量是第二重要。

18 个答案:

答案 0 :(得分:15)

您制作高质量的软件有三个原因:

  1. 要做得好,必须精心设计,精心设计的软件写得更快。
  2. 制作精良的软件更易于维护,一切都得到维护。
  3. 我们写得很好,因为我们关心,因为我们是专业人士。

答案 1 :(得分:5)

应用程序按预期工作并不总是理想的解决方案。内部工作如何发生也是需要注意的一点,而不是单独获得所需的输出。

如果不存在公司中 软件质量保证 的支持。

软件质量通常被忽略,因为我们经常倾向于 短期优化

为什么您认为应用程序开发与质量无关?

答案 2 :(得分:5)

第一步是定义质量。

最重要的是,重要的是软件给消费者带来的价值。所以,就我而言,只有两件事构成了“质量”代码。

  1. 直接向用户提供价值。 (外部质量)
  2. 为软件增加更多价值是多么容易(包括测试,验证缺乏回归,构建过程等) - 内部质量。
  3. 高质量的代码库让您可以快速轻松地进行更改,您可以放心地打破世界,并且可以降低构建/验证更改的成本。低质量的代码库很脆弱,很难进行更改,并且需要很长时间才能构建/验证。

    其他一切只是针对这两点之一的指导方针。一致且良好的命名提高了质量,因为它清楚地表明了代码正在做什么,并且理解代码正在做什么使得更容易进行更改。单元测试套件可提高质量,因为它们可以更轻松地更轻松地更改代码。 “良好设计”原则(例如关注点分离)可以轻松地对代码进行更改,因为更改往往更加孤立。

    所以,是的,这些事情甚至对应用程序开发也很重要。内部质量因素使得在给定的时间段内为应用程序添加更多功能变得容易 - 但是,这必须与可以在开发人员工作量相同的情况下实现的功能进行平衡。

答案 3 :(得分:4)

这实际上取决于您的受众。如果您是独立开发人员并且直接向最终用户销售产品,那么您真的应该关注质量。

如果您正在处理某些公司内部使用的应用程序,那么您可能不必关心质量,只要您能解决出现的问题并且您的用户讨厌你的胆量。

竞争越少,产品的生存质量越不重要。虽然高质量的应用程序可以更有用并且节省时间和金钱,但这并没有考虑到。

答案 4 :(得分:4)

我正在添加第二个答案,因为这是我个人的意见,也是我尝试操作的方式,不仅仅是软件质量,还有我得到报酬的任何事情。

随着一切,当有人付钱给我做某事时,我会尽我所能去做。我不会采取捷径,我不会吝啬,我不会偷工减料。我会尽我所能,因为人们注意到,他们欣赏它,他们会回来。这是我(或我公司的)在我给他们的产品上的名字,而且我不想把我的名字放在一块狗屎上。它可能比其他人花费更多的时间和成本,但这没关系。

我想要对自己正在做的事情感到满意,如果我知道自己已经跳出来,我就无法做到这一点。不幸的是,不是每个人都这样运作。法拉利没有让自己的名字偷工减料。人们会注意到你花时间做正确的事情,而且通常情况下,如果你偷工减料,你可能不得不回去修理它。你真的想要制造破碎的声誉吗?

有一种说法,如果顾客有一个良好的经历,他会告诉3个人,如果他有一个坏人,他会告诉10.这是事实,而且修复起来要困难得多一个坏名声,而不是保持良好的声誉。有时那些怀疑的阴影永远不会消失,而且会受到伤害。

第一次做正确的事总是比第一次做得更好,然后第二次修好,然后提出废话的借口。

道德,道德,等等等等。

答案 5 :(得分:4)

编写糟糕的代码真的没有充分的理由。

  • 几乎所有软件都将大部分时间用于维护。因此,几乎所有代码都应该是可维护的。

  • 一旦养成习惯,构建可维护代码不会花费更多时间来构建不可维护的代码。但是你不会养成通过编写不可维护的代码来编写可维护代码的习惯。因此,即使是你想丢弃的代码也应该是可维护的。

  • 导致可维护代码的相同做法也会产生可测试的代码。如果你还没有测试过代码,那么你就不能说它按预期工作了。因此,即使是你想丢弃的代码,也应该进行测试。

  • 编写为可维护且可测试的代码具有更少的错误。即使是经过良好编写的,未经过测试的可测试代码也不太可能出现错误,而不是那些未经过测试的编写错误,难以测试的代码。因此,即使您未测试的代码也应该写得很好。

你需要防范的是没有时间浪费使代码变得更好。浪费时间使代码工作不好。

答案 6 :(得分:3)

这取决于应用程序的重要程度。编写医疗软件和简单的实用程序应用程序之间存在差异。

我不确定你的质量是什么意思?

源代码的整洁性?

用户界面?

可靠性?

速度?

大小?

这些都与谁付钱给你,他们想要什么,他们期望什么(这些可能是不同的,非常令人沮丧的),当他们需要它等等有关。

答案 7 :(得分:3)

defined的代码质量为multiple factors

你基本上是说,只有外部可见因素或其中一部分(“按预期工作”)才重要。这些肯定是最明显的,但普遍的共识是,如果没有内部代码质量因素,您将无法实现高外部质量。

类比 - 真正伟大的汽车不仅仅依赖于对最终原型的非常严格的测试。设计和开发过程本身必须采用高质量的技术,以实现一辆候选人成为一辆好车的汽车。

答案 8 :(得分:2)

大多数开发人员都能够提供能够按预期及时或接近完成工作的软件。真正的问题是维护。对于短期项目,维护在可交付成果之后开始。对于大型项目,它甚至在达到v1.0之前就开始了。良好实践和高质量的开发人员可以创建可维护的代码。

当然,您的项目按预期工作 。但到目前为止我见过的每个项目都符合预期不是根据需要。始终客户意识到某些要求的功能甚至不能满足需要,并且不可避免的设计变更请求也会进入。或者项目成功并被客户组织中的更多团队采用,每次都有一个小的变化要求更好地满足他们的需求。或者原始需求量表是当前部署使用量的十分之一,并且软件必须适应更大的用户群。

根据要求,项目只能正确实施。我们都是人,犯错误,我们误解了要求,有时候我们提出了一些问题。

这一切都归结为软件永远不会冻结的事实,只要有赞助商支付所需的更改。写得不好的黑客软件是不可能改变的。良好实践在开发过程中施加了负担,以确保最终产品可以更改,重构,调试和维护。

答案 9 :(得分:2)

大多数非开发人员会将Quality应用程序定义为满足其期望的应用程序。总体而言,不同的利益相关者会有不同的定义:

  • 用户 - 应用程序快速,易用,并提供我需要的功能
  • 营销人员 - 它看起来漂亮且易于销售
  • 管理 - 按时完成并符合业务要求
  • 开发人员 - 长期维护很容易

许多从事小型项目的开发人员都在考虑使用XYZ模式,或者使用正确的框架/语言进行思考。这些事情对大型企业应用程序或大型性能关键型网络应用程序(即Facebook,谷歌等)都很重要,但在更好地使用解决方案时,这些应用程序通常不那么重要。

最后,企业主/负责人是决定您就业的人,他们对质量的定义是最重要的。

答案 10 :(得分:1)

我没有得到你的问题。但是如果你质疑是否需要始终遵循设计原则以及这些原则如何影响项目的质量,那么这就是我的答案。

这取决于项目的阶段,团队的规模以及预计完成的时间。

有时快速而肮脏很重要。让它尽快运作。在这些情况下使用最佳设计模式是过度的,而不是必要的。能够使用/任何解决方案快速交付的开发人员获胜。他们的头在天空中失去了。

然而,有时候(通常)快速而肮脏的方法会失败。例如,如果项目已经拥有或将拥有大量开发人员(超过4人)或多个团队,那么遵循可靠/成熟的开发模式和技术是长期成功的唯一途径。此外,如果存在大量复杂的遗留代码,则实现新模式通常会失败。最后,预期的时间线对于保持一致是至关重要的。如果客户在一天中期待某种原型,那么就不要花费一周的时间来整合一个完整的MVC框架。

答案 11 :(得分:1)

谢谢大家的回复。让我更多地说明为什么我在第一时间提出这个问题。

我也相信并且认为在考虑这些原则时应该毫不犹豫。我认为这是一种艺术,策略不能根据某些东西进行切换。

但是如果你看到关于这个主题的任何内容或者说这篇文章,请注意诸如“取决于什么”之类的短语。现在的实际问题是谁能直接受益于这样的质量代码,除了你自己,这也是你的成圣,道德,道德。

让我们举一个非常普遍的例子;一个拥有数百万次点击的网站。最终用户很高兴,因为网站看起来很有吸引力,他们得到了订单管理层很高兴,因为开发/改进是在预算范围内完成的,所有功能都已实施。 PM很高兴,因为不知何故,团队及时交付了它。 Tech Lead很高兴,因为所有异构子系统都按预期进行通信,并且满足基础设施约束。由25名开发人员组成的团队感到高兴,因为所有错误都已修复,现在他们的代码正在运行;当然他们有信心,因为他们使用了类型安全的语言,很棒的IDE,他们会找到任何运行时错误的行号,因为try catch block无处不在。

在这里,我们可以说,他们没有遵循任何模式或最佳实践。所以代码不是可重用的,或者逻辑层依赖于数据格式或......但是对于下一个开发,会有新的预算,新的开发计划和开发人员获得可能不符合过去任务的新任务。

通过遵循某些原则,谁直接受益或必须强制执行消除这些原则,可能需要在时间和预算方面支付一些额外费用?

然后谁会关心这些呢?每个人都知道它的理论重要性,但在实践中,它是“金色触摸”还是“有好处”特征或“必须具备”要求?如果它真的重要,那么正如许多人所说,为什么预算或时间被赋予最重要的意义,质量是第二重要。

答案 12 :(得分:1)

应用程序质量对开发人员来说意义重大,主要仅针对开发人员,很少对管理层而言。

当您关注良好的应用程序体系结构时,考虑到可扩展性和可维护性,在尝试调试代码并修复在某个阶段刚刚开始崩溃的事情时,您将节省自己的时间和痛苦。< / p>

开发人员试图制造这些小黑客和快速解决方案的术语 - 开发者债务。如果你做得足够多,在未来的某个时候你会陷入困境 - 技术破产。这意味着现在几乎不可能添加新的功能或改变一些东西而不会让其他东西分崩离析。现在,从头开始重写所有内容,现在更便宜,更简单。管理层永远不想这样做。作为一个自豪的开发人员,你永远不想帮助“实现”这种情况,甚至可能不参与具有该开发理念的项目。

答案 13 :(得分:1)

看起来你说的真正重要的是,正如你所说的那样,“开发时间”,“应用程序按预期工作”,“完成时间稍晚但没关系”。这基本上是开发时间,功能和......开发时间。

你是对的。重要的是您的产品按预期工作并按时出货。有时甚至按预期工作也不如仅仅把它带到那里那么重要。

但是这里有一个问题:如何让产品快速按预期运行?对于一个非常小的代码库,答案可能只是将快速和脏的东西扔在一起。有些情况下the raptor won't attack you for using a goto

但是浩大的大多数情况下,你正在研究一些你将花费至少几个星期的事情。快速而肮脏的代码有一种失控的方式,让你的产品成为一堆阴影,未被捕获的异常和竞争条件。它可能发生在第二天,第二周或第二个月,但它总会在你预期之前发生,而在它发生时它没有任何好的选择。您可以在前几个截止日期前完成所有功能,但最终您的快速而脏的代码将不再快速并且继续变脏,这将影响您的开发时间,功能和......开发时间。 / p>

或者,您可以花时间编写可读的,惯用的,可扩展的代码,以正确使用设计模式。起初,这似乎是一种更慢的做事方式。 那是因为它是,但仅限于现在。三个月后,你的老板会告诉你做一些改变。也许它将您的整个系统从Solaris移植到Linux:既然您已经编写了与平台无关的良好代码,那么您可以更改一些函数调用,并且编译时没有错误。或者它可能会增加对第三方插件的支持:由于所有渲染都是根据DRY原则在同一区域处理的,因此您只需要为一个类添加插件支持。与此同时,您的快速和肮脏的竞争对手正在考虑对其产品进行完全重写,因为他们的原始代码标准和设计(或缺乏代码)并未考虑到可移植性或可扩展性。

简而言之,软件质量就是您满足最后期限并创建正常工作功能的方式。

答案 14 :(得分:1)

当然重要。

就像你说的那样,有很多信息可以用它们设计的方式来设计应用程序,并按照它们的编码方式进行编码。

即使你是一个像你所说的APplication开发者,如果你马虎,你的队友和同事也不会想和你合作。您的工作质量反映在您的所有团队中。

你可以在不学习原则和架构的情况下开发你的职业生涯,但不要期望永远被认可或扩展到更高职位。您将永远无法自己设计应用程序的体系结构,因为您只知道开发最基本的功能/屏幕。

是的,是的......重要的是。去学习!

答案 15 :(得分:1)

我靠拾取由不尊重软件质量的开发人员启动的项目谋生。

的确,我拥有源源不断的客户,这意味着我们不会雇佣像我这样的人,而是雇佣了一个做了一份草率工作的人。所以是的,从某种意义上说,你可以逃脱并仍然谋生,这无关紧要。

但对我而言,这不仅仅是短期的。随着我的技能和经验的增长,我想领导更大的项目,如果我不注意软件的质量,我就无法做到这一点。

此外,当你这样做时,它看起来更漂亮。

答案 16 :(得分:1)

我一般会同意,特别是如果您不打算大规模推广您的产品。对我来说,我工作的大部分应用程序都是单独出售的,因此应用程序的外观并不像功能那么重要。我发现很少有应用程序胜出,因为它的功能较少时看起来更好。此外,当我做出改变以使某些东西看起来更好时,我让客户感到非常恼火,但它要么会破坏功能,要么会大幅改变他们的工作流程,可能会使其变得更慢或更乏味。

另一方面,如果产品看起来不错或甚至漂亮,我认为用户体验要好得多,使用它们会更快乐。我认为他们甚至会要求更多修改/添加,因为他们喜欢使用该应用程序并希望更多地使用它。我还认为有时美容伴随着功能:许多不错的应用程序看起来很不错,因为它们具有很好的功能,例如Web应用程序中的AJAX。

最后,如果应用程序是面向公众的应用程序,那么我认为应用程序的外观非常重要。 (当你处理内部应用程序时,它并不那么重要。)如果一个应用程序在人们点击谷歌的结果时乍一看看起来很丑陋,那么他们就不那么容易留下来看到更多了,并且会去找那个拥有漂亮网站的竞争对手/应用

还有一件事:我通常会尝试让事情看起来不错。我会花费额外的时间,即使不是引用它使它更令人愉快。我是一个完美主义者,我想要能向其他客户展示的东西,而不是我感到羞耻的东西。

答案 17 :(得分:0)

我总是为自己的满足感写好代码。 =)