为什么不是每个人都使用 RAD 工具？
RAD 工具，例如 Clarion 和 WinDev 声称开发速度提高了 10 倍到 20 倍，这些工具的用户也这么认为。 如果是这样，为什么使用这些工具的人这么少？ 如果在 40 小时而不是 400 小时内提出申请，您会赚更多的钱，对吧？
RAD tools like Clarion and WinDev claim to be 10x to 20x times faster in development and users of these tools claim the same. If that is thru, why are there so few people using these tools? if an application is made in 40 hours instead of 400 you would make a lot more money, right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
因为
Because
没有什么灵丹妙药，20 倍之类的说法是值得怀疑的。
然而，其中很大一部分是本线程其他答案中提到的看法。 它们的范围从简单（“不可能是真的”）到通用（“难以定制”）再到通用（“生成混乱的代码”）。 为了真正进行比较，您需要将特定的 3GL 环境与特定的 4GL 环境进行比较。 两者都有优点和缺点。 两者都可能让您创建好的或坏的程序。
最大的界限是技能因素。 要充分利用任何工具都需要时间和精力。 毫不奇怪，4GL 的用户往往是它的最大支持者，因此显然它们的某些内容对很多人都有效。 但它们通常花费更多（购买），有自己的特质和自己的优点和缺点。 让程序员从一种环境转换到另一种环境是很困难的。
在大型组织中，还有大量现有代码需要满足。 如果您有开发团队，则很难将整个程序员团队从一种工具更改为另一种工具。 即使您这样做了，由于团队中没有现有的有经验的用户，学习过程也会缓慢而困难。 无论语言或环境如何，这都是事实。
经济也发挥着重要作用。 公司喜欢成为主流的安全感。 即使花费更多。 他们喜欢这样的想法：程序员中队可以用“当前”语言编写代码。 程序员是一种商品，会来来去去，并且可以在需要时更换。 世界上充满了 C、Java、C# 程序员等。选择“小”语言虽然会导致无尽的政治问题，决策必须合理等等。 这是古老的“没有人因为购买 IBM 而被解雇”综合症。 归根结底，如果金钱不是问题，那么还有其他（政治上）更重要的考虑因素。
因此，像 Clarion 和 Windev 这样的产品的大多数用户要么是独立程序员，要么是非常小公司的成员，这也就不足为奇了。 在这些情况下，日常经济比使用最新工具或填充简历更重要。 想象一下这样一个世界：您只有在程序发布时才能获得报酬。 突然之间，原始生产力变得很重要，最重要的是完成工作，这样你就有饭吃了。
由于作为雇员工作的人比为自己工作的人多得多，因此大多数程序员不需要直接担心获得报酬也就不足为奇了。 如果无论用什么都能拿到工资，那你还不如顺其自然。 如果这个职位倒闭，还有很多工作机会。 所以主流工具仍然是主流，其他一切都被忽略。
事实上，其他答案中提到的许多先入之见都是错误的，这一事实并不重要。 感知就是一切，在正确与错误的二元世界中，无论你现在使用的语言是什么，都是“正确”的，其余的都是“错误”的。
There is no silver bullet, and claims of 20x etc are worth a grain of salt.
However a big part of it is the perceptions mentioned in the other answers in this thread. They vary from the simple ("can't be true") to the generic ("hard to customize") to the general ("generates messy code"). In order to really compare you need to compare a specific 3GL environment with a specific 4GL environment. Both will have strengths, and weaknesses. Both will likely allow you to create good or bad programs.
The biggest boundary is the skill factor. To get the best from any tool takes time and effort. Not surprisingly users of 4GL's are often the biggest proponents of it, so clearly something about them works for a lot of people. But they usually cost more (to buy), have their own idiosyncrasies and their own strengths and weaknesses. Getting programmers to convert from one environment to another is hard.
In large organizations there's also a lot of existing code to cater for. If you have teams of developers it's hard to make a case for changing a whole team of programmers from one tool to another. Even if you did that, with no existing experienced user in the team, the learning process will be slow and hard. Again this is true regardless of language or environment.
Economics also plays a big part. Companies like the security of being in the main-stream. Even if it costs more. They like the idea that squadrons of programmers are available to write code in the "current" language. Programmers are a commodity that are expected to come and go, and can be replaced when needed. The world is full of C, Java, C# programmers etc. Choosing a "small" language though results in endless political problems, decisions have to be justified and so on. It's the old "no one got fired for buying IBM" syndrome. At the end of the day if money is no object, then there are other considerations that (politically) matter more.
It's no surprise then that most users of products like Clarion and Windev are either independent programmers, or members of very small companies. In these situations daily economics matters more than using the latest tool or padding a CV. Imagine a world where you only get paid when the program ships. Suddenly raw productivity does matter and the most important thing is getting the job done so you can eat.
Since there are a lot more people working as an employee than working for themselves, it's not surprising that most programmers don't need to worry directly about getting paid. If you get your salary no matter what you use, then you might as well go with the flow. There are plenty more jobs out there if this one goes under. So the mainstream tools remain mainstream, and everything else is ignored.
The fact that many of the preconceptions mentioned in other answers here are false doesn't really matter. Perception is everything and in a binary world of right and wrong whatever language you are using now is the "right" one, and the rest are "wrong".
没有银弹。
根据我的经验，RAD 工具和 IDE 消除了一些编码的苦差事，但对加快项目速度几乎没有作用。 生产力的主要提升出现在软件开发周期的早期，特别是在定义问题的性质、规模和范围、创建估计和管理风险方面。
没有 RAD 工具可以修复 SDLC 中早期出现的错误。 事实上，可能会发生相反的情况：使用这些工具的开发人员可以根据不良规范快速编写代码。 这给人一种他们正在高效生产的错觉，而实际上正在制造错误的产品。
There is no Silver Bullet.
In my experience, RAD tools and IDEs remove some of the drudgery of coding, but do little to speed a project up. The major gains in productivity come far earlier in the software development cycle, specifically in defining the nature, size and scope of the problem, creating estimates, and managing risks.
No RAD tool can fix mistakes made early on in the SDLC. In fact, the opposite may occur: developers using those tools can rapidly churn out code against a bad spec. This gives the illusion they are being productive, when in reality the wrong product is being built.
RAD 工具不提供您自己编写内容的可定制性。 客户通常会说“如果它完全像这样工作，那就太好了”，如果您已经对其进行了编码，这将是一个非常快的更改，但需要您研究该工具以查看此更改是否可能（并且会令人沮丧）客户，如果不是）。
此外，您可以更好地控制所做的事情，并且不太可能出现“由于错误假设而导致的奇怪行为”。 编写测试也更容易。
最后，这是一个全新的学习事物，存在花费时间不值得的风险（也许值得，但我不愿意冒险学习一些我可能不会使用的过于具体的东西）。
RAD tools doesn't give you the customizability of writing things on your own. The customer usually says something like "This would be nice if it worked exactly like this", which would be a really fast change if you had coded it, but will require you to study the tool to see if this change is possible (and frustrate the customer, if it isn't).
Also, you have more control on what is done, and is less likely to have weird behavior 'caused by wrong assumptions. It's easier to write tests too.
Finally, it's a whole new thing to learn, with a risk that the time spent is not worthwhile (maybe it would be, but I'm not willing to take a risk of learning something too specific which I might not use).
快速并不总是意味着准确。 我能想到的一个例子是，如果有人正在开发起搏器，我宁愿他们花 400 个小时来使其正确，而不是只花 40 个小时来开发它，并冒着潜在灾难性结果的风险。
Rapid doesn't always mean accurate. An example I can think of, if someone were developing a pacemaker, I'd rather they spend 400 hours getting it correct instead of developing it in only 40 and risk a potential disasterous result.
不完全正确。 它们可以提高某些任务的生产力，但不是全部。 大多数 IDE 已经包含许多可以提高生产力的工具。 例如代码模板和代码完成。 因此，与其他现代工具相比，我认为他们无法管理整个项目的 10 到 20 倍。
Not entirely true. They can enhance the productivity for some tasks bit not all. And most IDE's already contain lots of tools to enhance productivity. For example code templates and code completion. So I don't think they can manage a 10 to 20 times for an entire project, compared to other modern tools.
您不能相信 RAD 工具能够编写干净、可维护的代码。
亲自看看，使用 Visual Studio 设计器，拖动数据网格和数据库连接，然后检查它将生成的混乱代码，如果您需要自定义向导开发人员未预见到的内容，您会发现自己处于很麻烦。 现在您将如何维护代码？ 一切都是如此混乱且紧密耦合。
You can't trust a RAD tool to write clean, maintainable code.
Just see for yourself, use the Visual Studio Designer, drag a datagrid and a database connection and then check the messy code it will generate, if you need to customize something that was not foreseen by the developers of the wizard you will find yourself at a lot of trouble. Now how will you maintain the code? Everything is so messy and tightly coupled.
当您决定使用 RAD 工具时，您需要做出一定的牺牲：
当您生成了大量代码或允许 RAD 工具提供帮助时，很难掌握代码/系统的深入知识。
灵活性可能会丧失； 有些工具会否决任何人为更改，并按照它们知道的方式重新生成代码。 我个人认为，这些工具应该能够识别人员何时进行了更改，并且至少拒绝运行 - 人为更改应该始终优先。
通常这些工具可以帮助进行全新开发，但会留下大量代码需要维护。 声称的 10 倍到 20 倍的生产力提升可能是通过代码行数而不是实际完成的功能来衡量的。
When you decide to use a RAD tool you accept certain sacrifices:
Intimate knowledge of the code/system is one thing that is very difficult to have when you have generated much of your code or allowed a RAD tool to help.
Flexibility can be lost; some tools will overrule any man-made changes and regenerate the code as they know how. Personally I believe that these tools should be able to identify when changes have been made by a person and at the very least refuse to run--human changes should always take precedent.
Often times these tools can help with greenfield development but leave a monstrous amount of code behind to maintain. The claims of 10x to 20x productivity gains are probably measured by lines of code rather than actual finished functionality.
如果一个团队已经习惯了某些 IDE，那么改变它的成本是多少？ 我的意思是，如果我从 Visual Studio 2008 转向 Clarion 或 WinDev，我的雇主是否准备好承担我升级使用它所带来的成本？ 我心中还有一个问题，这些工具的成本是多少，以及可以提供什么样的保证（如果有的话）它们的功能和声称的一样。
If one already has a team used to certain IDEs, what is the cost of changing that? I mean if I go from Visual Studio 2008 to Clarion or WinDev, is my employer prepared to handle the cost that my ramping up on it will be? There is also the question to my mind of how much do those tools cost and what kinds of guarantees if any can be given that they will do as well as claimed.
我确实相信 RAD 工具无法让您灵活地处理代码。 然而，如果任何特定的 RAD 工具能够节省 60-70% 的开发时间，那么就值得在其中投入时间。 如今，熟练的开发人员正处于需求高峰。 这导致损耗率增加。 可靠的开发人员辞职只是为了加薪 5/10%。 这对开发公司影响很大。 那个为开发做出最大努力的人突然离开了。 这严重影响了项目的完成进度。 RAD 工具使组织减少对熟练开发人员的依赖。 最重要的是，大多数客户最不关心您使用什么技术进行开发。 如果他们的功能需求得到满足，他们会很高兴。
总而言之，在目前磨损率很高的情况下，RAD 工具的需求将会不断增加。 大多数项目都因为这种依赖性而被推迟。 读者可能会有所不同。
I do belive that the RAD Tools doesnt give u a flexible hand on the code. However if any specific RAD tool is saving 60-70 percent of the development time, worth investing time in it. Now-a-days Skilled developers are at the peak demand. This leads to increase in the attrition ratios. Dependable developers are resigning just for 5/10 % of raise in payscales. This impacts the Development Companies a lot. The one, who has done the most of the development, suddenly leaves. This hits the project completion schedule severely. RAD Tools makes the organization less dependent on the Skilled Developers. Most importantly, most of the Customers are least bothered about WHAT technology you are using for development. They are happy if their Functional Requirements are met.
All said and done, RAD tools will have an increasing demand in the present scenario, where attrition is high. Most of the projects get dragged out of the schedule just because of this dependence. The readers might differ.