ClarionやWinDevなどの RAD ツールは、開発が 10 倍から 20 倍高速であると主張しており、これらのツールのユーザーも同じことを主張しています。もしそうなら、なぜこれらのツールを使っている人がこれほど少ないのでしょうか? 申請が 400 時間ではなく 40 時間で行われた場合、より多くのお金を稼ぐことができますよね?
3524 次
10 に答える
33
なぜなら
- 彼らが予測した何かが必要な場合は素晴らしいですが、そうでない場合はひどいです
- 優れたパフォーマンスに不可欠な技術情報を隠しすぎることがあります
- 流動的で動的なインターフェースや「箱の外」のものを簡単に作成することはできません
- それらを簡単に拡張することはできません
- 自分に合ったサードパーティのコンポーネントを購入/入手することはできません
- 彼らは平凡なプログラマーが忌まわしきものを生み出すことを可能にします
- 品質、価格、時間。2 つを選択します。
于 2009-08-13T14:22:51.403 に答える
8
特効薬はなく、20x などの主張は一粒の塩の価値があります。
ただし、その大部分は、このスレッドの他の回答で言及されている認識です。それらは、単純なもの (「真実ではない」) から一般的なもの (「カスタマイズが難しい」)、一般的なもの (「乱雑なコードを生成する」) までさまざまです。実際に比較するには、特定の 3GL 環境と特定の 4GL 環境を比較する必要があります。どちらにも長所と短所があります。どちらも、良いプログラムまたは悪いプログラムを作成できる可能性があります。
最大の境界はスキル要因です。ツールを最大限に活用するには、時間と労力がかかります。当然のことながら、4GL のユーザーは多くの場合、4GL の最大の支持者です。しかし、それらは通常、(購入するのに) より多くの費用がかかり、独自の特異性と独自の長所と短所があります。プログラマーをある環境から別の環境に移行させるのは困難です。
大規模な組織では、対応しなければならない既存のコードも多数あります。開発者のチームがいる場合、プログラマーのチーム全体をあるツールから別のツールに変更することを主張するのは困難です。たとえそれを行ったとしても、チームに経験豊富なユーザーがいない場合、学習プロセスは遅く、困難になります。繰り返しになりますが、これは言語や環境に関係なく当てはまります。
経済も大きな役割を果たします。企業は主流にいるという安心感を好みます。たとえそれ以上の費用がかかったとしても。彼らは、「現在の」言語でコードを書くためにプログラマーの部隊が利用できるという考えを気に入っています。プログラマーは出入りが予想される商品であり、必要に応じて置き換えることができます。世界は C、Java、C# プログラマーなどであふれています。「小さな」言語を選択すると、際限のない政治的問題が発生し、決定は正当化されなければなりません。これは、「IBM を購入したからといって誰もクビにならない」という古い症候群です。結局のところ、お金が目的ではない場合、(政治的に) もっと重要な考慮事項が他にあります。
したがって、Clarion や Windev などの製品のほとんどのユーザーが独立したプログラマーか、非常に小さな会社のメンバーであることは驚くことではありません。このような状況では、最新のツールを使用したり、CV をパディングしたりすることよりも、日々の経済状況が重要になります。プログラムが出荷されたときにのみ支払いを受ける世界を想像してみてください。突然、生の生産性が重要になり、最も重要なことは仕事を終わらせて食べられるようにすることです。
個人で働くよりも従業員として働く人の方がはるかに多いため、ほとんどのプログラマーが給与について直接心配する必要がないことは驚くべきことではありません。何を使っても給料がもらえるなら、流れに乗ったほうがいい。ここが潰れたら、もっとたくさんの仕事がある。したがって、主流のツールは主流のままであり、他のすべては無視されます。
ここでの他の回答で言及されている先入観の多くが間違っているという事実は、実際には問題ではありません。知覚がすべてであり、善悪の二元的な世界では、現在使用している言語が何であれ、それが「正しい」言語であり、残りは「間違っている」言語です。
于 2009-08-19T07:08:12.493 に答える
7
銀の弾丸はありません。
私の経験では、RAD ツールと IDE はコーディングの単調な作業の一部を取り除きますが、プロジェクトのスピードアップにはほとんど役立ちません。生産性の大幅な向上は、ソフトウェア開発サイクルのはるかに早い段階、特に問題の性質、サイズ、範囲の定義、見積もりの作成、およびリスクの管理においてもたらされます。
SDLCの早い段階で犯した間違いを修正できる RAD ツールはありません。実際には、逆のことが起こる可能性があります。これらのツールを使用する開発者は、不適切な仕様に対してコードを急速に大量生産する可能性があります。これは、実際には間違った製品が作られているにもかかわらず、彼らが生産的であるという錯覚を与えます.
于 2009-08-13T14:40:44.150 に答える
5
RAD ツールには、独自に記述できるカスタマイズ機能はありません。顧客は通常、「これがこのように機能するならいいだろう」のようなことを言います。これは、コーディングしていれば非常に迅速な変更ですが、この変更が可能かどうかを確認するためにツールを調べる必要があります (そしてイライラします)。そうでない場合は顧客）。
また、何が行われるかをより細かく制御でき、間違った仮定によって引き起こされる奇妙な動作が発生する可能性が低くなります。テストも書きやすいです。
最後に、学習するのはまったく新しいことであり、費やした時間が価値がないというリスクがあります (おそらくそうなるかもしれませんが、使用しない可能性のある具体的すぎることを学習するリスクを負うつもりはありません)。
于 2009-08-13T14:21:58.423 に答える
4
迅速であるということは、常に正確であることを意味するわけではありません。私が思いつく例として、誰かがペースメーカーを開発している場合、たった 40 時間で開発し、潜在的な悲惨な結果を招く危険を冒すよりも、400 時間かけて正しいものにした方がよいでしょう。
于 2009-08-13T14:16:42.933 に答える
2
完全に真実ではありません。すべてではなく一部のタスクの生産性を向上させることができます。また、ほとんどの IDE には、生産性を向上させるためのツールが多数含まれています。たとえば、コード テンプレートとコード補完です。そのため、他の最新のツールと比較して、プロジェクト全体で 10 ～ 20 回を管理できるとは思いません。
于 2009-08-13T14:18:45.383 に答える
2
クリーンで保守可能なコードを作成するために RAD ツールを信頼することはできません。Visual Studio デザイナを使用し、データグリッドとデータベース接続をドラッグして、生成される乱雑なコードを確認してください。ウィザードの開発者が予測していなかったものをカスタマイズする必要がある場合は、たくさんのトラブル。では、コードをどのように保守しますか? すべてが非常に乱雑で、密に結合されています。
于 2009-08-14T17:30:55.660 に答える
1
RADツールを使用する場合は、特定の犠牲を受け入れます。
コード/システムに関する深い知識は、コードの多くを生成したり、RADツールを使用したりするときに非常に難しいことの1つです。
柔軟性が失われる可能性があります。一部のツールは、人為的な変更を無効にし、方法を知っているとおりにコードを再生成します。個人的には、これらのツールは、人がいつ変更を加えたかを識別でき、少なくとも実行を拒否できるはずです。人間の変更は常に優先されるべきです。
多くの場合、これらのツールはグリーンフィールドの開発に役立ちますが、維持するために膨大な量のコードを残します。10倍から20倍の生産性向上の主張は、実際の完成した機能ではなく、コード行によって測定される可能性があります。
于 2009-08-13T14:48:48.387 に答える
1
特定の IDE に慣れているチームが既にある場合、それを変更するコストはいくらですか? つまり、私が Visual Studio 2008 から Clarion または WinDev に移行した場合、私の雇用主は、私がそれを強化するためのコストを処理する準備ができているでしょうか? また、これらのツールの価格と、主張されているだけでなく機能するという保証があれば、どのような種類の保証が与えられるのかという疑問も頭に浮かびます.
于 2009-08-14T17:21:30.843 に答える
0
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.
于 2009-11-02T08:34:13.840 に答える