【问题标题】:why doesn't everyone use RAD tools? [closed]为什么不是每个人都使用 RAD 工具? [关闭]
【发布时间】:2010-11-19 07:45:25
【问题描述】:

ClarionWinDev 等 RAD 工具声称开发速度提高了 10 到 20 倍,这些工具的用户也声称相同。如果是这样,为什么使用这些工具的人这么少?如果在 40 小时而不是 400 小时内完成申请,您会赚更多的钱,对吧?

【问题讨论】:

  • 因为这种数字几乎可以肯定是一个大大夸大的说法?因为人们不相信营销 BS?
  • 完全同意,我不相信这种营销方式,顺便说一句......我经常与那些声称这些事情的人讨论......我想证明他们是错的......我相信 java、c#、php 等语言比这两个例子更强大。
  • 如果您知道自己在做什么,也一样快...
  • 我没有意识到这些旧车还在。生命值。洛夫克拉夫特是对的。

标签: rad


【解决方案1】:

因为

  1. 如果你想要他们预测的东西,他们会很棒,但如果不是,他们会很糟糕
  2. 他们有时会隐藏太多对良好性能至关重要的技术信息
  3. 您无法轻松创建流畅、动态的界面或“开箱即用”的任何东西
  4. 你不能轻易扩展它们
  5. 您无法购买/获取可能适合您的第三方组件
  6. 它们让平庸的程序员产生可憎的东西
  7. 质量、价格、时间。选择两个。

【讨论】:

  • 第6项:VB6效果
  • 我所知道的最好的 RAD 工具实际上是 MS Access!
  • 很好的答案。我同意所有这些。我可能按以下顺序排列:1、6、3、2、4、5、7。我还可能添加一些与泄漏抽象相关的内容(2 和 6 间接暗示的那种)。
  • 爱最后一点,质量,价格,时间。选择两个。
【解决方案2】:

没有灵丹妙药,声称 20 倍等物有所值。

但是,其中很大一部分是该线程中其他答案中提到的看法。它们从简单的(“不可能是真的”)到通用的(“难以定制”)到一般的(“生成混乱的代码”)不等。为了真正进行比较,您需要将特定的 3GL 环境与特定的 4GL 环境进行比较。两者都会有长处和短处。两者都可能允许您创建好的或坏的程序。

最大的界限是技能因素。从任何工具中获得最佳效果都需要时间和精力。毫不奇怪,4GL 的用户通常是它的最大支持者,所以很明显,他们的某些东西适用于很多人。但它们通常成本更高(购买),有自己的特质和自己的优势和劣势。让程序员从一种环境转换到另一种环境是很困难的。

在大型组织中,还有很多现有代码需要处理。如果您有开发人员团队,则很难将整个程序员团队从一种工具更改为另一种工具。即使你这样做了,在团队中没有经验丰富的用户的情况下,学习过程也将是缓慢而艰难的。同样,无论语言或环境如何,这都是正确的。

经济也起着重要作用。公司喜欢成为主流的安全性。即使花费更多。他们喜欢这样的想法,即程序员中队可以用“当前”语言编写代码。程序员是预期来来去去的商品,需要时可以更换。世界上到处都是 C、Java、C# 程序员等。选择一种“小”语言虽然会导致无穷无尽的政治问题,但决策必须合理等等。这是古老的“没有人因为购买 IBM 而被解雇”综合症。归根结底,如果金钱不是问题,那么还有其他(政治上)更重要的考虑因素。

因此,Clarion 和 Windev 等产品的大多数用户要么是独立程序员,要么是非常小公司的成员,这一点也就不足为奇了。在这些情况下,日常经济比使用最新工具或填写简历更重要。想象一个只有在程序发布时才能获得报酬的世界。突然之间,原始生产力确实很重要,最重要的是完成工作,这样你就可以吃东西了。

由于作为员工工作的人比为自己工作的人多得多,因此大多数程序员不需要直接担心获得报酬也就不足为奇了。如果不管你用什么都能拿到工资,那你还不如顺其自然。如果这个工作失败,还有更多的工作。所以主流工具仍然是主流,其他的都被忽略了。

这里其他答案中提到的许多先入之见是错误的这一事实并不重要。感知就是一切,在对与错的二元世界中,您现在使用的任何语言都是“正确的”语言,其余的都是“错误的”。

【讨论】:

  • 您可以使用相同的论据来回答为什么人们使用 java 或 php 而不是 python。现实情况是,人工智能并不存在,这些工具很糟糕。这些“独立程序员”根本就不是程序员。当您必须交付优质产品时,您是否会依赖某些工具生成的代码?我已经使用 RAD 3 年了,让我告诉你:我什至更喜欢 C。
【解决方案3】:

没有Silver Bullet

根据我的经验,RAD 工具和 IDE 消除了一些编码工作的繁琐,但对加快项目速度几乎没有作用。生产力的主要收益出现在软件开发周期的早期,特别是在定义问题的性质、规模和范围、创建估计和管理风险方面。

没有 RAD 工具可以修复早期在 SDLC 中犯的错误。事实上,可能会发生相反的情况:使用这些工具的开发人员可以快速生成针对错误规范的代码。这给人一种他们正在生产的错觉,而实际上正在构建错误的产品。

【讨论】:

    【解决方案4】:

    RAD 工具无法让您自定义编写内容。客户通常会说“如果它完全像这样工作那就太好了”,如果您编写了代码,这将是一个非常快速的更改,但需要您研究该工具以查看此更改是否可能(并且令人沮丧客户,如果不是)。

    此外,您可以更好地控制所做的事情,并且不太可能出现由错误假设引起的奇怪行为。编写测试也更容易。

    最后,这是一门全新的学习,有可能花费的时间不值得(也许会,但我不愿意冒险学习一些我可能不会使用的过于具体的东西) .

    【讨论】:

      【解决方案5】:

      快速并不总是意味着准确。我可以举一个例子,如果有人在开发起搏器,我宁愿他们花 400 个小时把它弄好,而不是只用 40 个小时开发它,并冒着潜在的灾难性后果的风险。

      【讨论】:

      • 我怀疑你可以或者你应该使用 RAD 工具来开发起搏器。这反映了对 RAD 工具的众多误解之一。
      【解决方案6】:

      不完全正确。它们可以提高某些任务的生产力,但并非全部。而且大多数 IDE 已经包含许多提高生产力的工具。例如代码模板和代码完成。因此,与其他现代工具相比,我认为他们无法为整个项目管理 10 到 20 次。

      【讨论】:

        【解决方案7】:

        您不能相信 RAD 工具可以编写干净、可维护的代码。 自己看看,使用 Visual Studio 设计器,拖动数据网格和数据库连接,然后检查它将生成的混乱代码,如果您需要自定义向导开发人员未预见到的内容,您会发现自己处于很多麻烦。现在你将如何维护代码?一切都是如此混乱和紧密耦合。

        【讨论】:

        • 我不会将 Visual Studio Designer 视为 RAD 工具,即使他们将其推销为那样。
        【解决方案8】:

        当您决定使用 RAD 工具时,您会接受某些牺牲:

        • 当您生成大量代码或允许 RAD 工具提供帮助时,对代码/系统的深入了解是一件非常困难的事情。

        • 可能会失去灵活性;一些工具会否决任何人为更改并按照他们知道的方式重新生成代码。就我个人而言,我认为这些工具应该能够识别人何时进行了更改,并且至少拒绝运行——人为更改应始终优先。

        • 这些工具通常可以帮助进行全新开发,但会留下大量代码需要维护。声称 10 到 20 倍的生产力提升可能是通过代码行数而不是实际完成的功能来衡量的。

        【讨论】:

          【解决方案9】:

          如果已经有一个团队习惯了某些 IDE,那么改变它的成本是多少?我的意思是,如果我从 Visual Studio 2008 转到 Clarion 或 WinDev,我的雇主是否准备好承担我升级它的成本?还有一个问题是,这些工具的成本是多少,以及如果可以提供什么样的保证,它们会像声称的那样做。

          【讨论】:

            【解决方案10】:

            我相信 RAD 工具不会让您灵活处理代码。但是,如果任何特定的 RAD 工具可以节省 60-70% 的开发时间,那么值得在它上面投入时间。现在,熟练的开发人员正处于需求高峰期。这导致损耗率增加。可靠的开发人员辞职只是为了提高工资表的 5/10%。这对开发公司影响很大。那个完成大部分开发的人突然离开了。这严重影响了项目完成进度。 RAD 工具使组织减少对熟练开发人员的依赖。最重要的是,大多数客户最不关心您使用什么技术进行开发。如果他们的功能需求得到满足,他们会很高兴。

            总而言之,RAD 工具在当前情况下的需求将不断增加,在这种情况下,人员流失率很高。大多数项目只是因为这种依赖而被拖出日程。读者可能会有所不同。

            【讨论】:

            • 使用框架和 ORM。代码生成不灵活,导致软件质量差。如果您遵守标准(rails、django 甚至 spring),任何开发人员都可以理解和扩展您的代码
            猜你喜欢
            • 2010-12-17
            • 2013-01-14
            • 1970-01-01
            • 1970-01-01
            • 2023-03-20
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2010-10-05
            相关资源
            最近更新 更多