RADツールは問題を起こす価値がありますか？
私は何年もの間、ウィンドウとWeb開発（主にインフラジスティックス）にRADツールを使用してきました。これらのコントロールには間接化と抽象化のレイヤーが重ねられているため、何が起こっているのかを理解するのが非常に難しい状況に常に陥ります。
これは、RADツールなど、AJAX更新パネル、AJAXグリッドなど、あらゆる種類のツールに当てはまります。トラブル？」
すべてのトラブルと時間について、これらのコントロールのバグまたは奇妙な問題をデバッグするのに、自分のAJAXをコーディングするだけの方が良いでしょうか？これらのRADツールを使用する代わりに、独自の追加機能をコーディングしますか？
彼らのもう1つの問題は、彼らが使用しているテクノロジーに慣れていないことです。たとえば、私は常に更新パネルなどを持っていたので、自分でAJAXを行ったことがありません。しかし、これは知っておくと便利だと思います。 。
これについてどう思いますか？
注：「インフラジスティックスの代わりにXYZ RADツールを試してみるべきです...それらの方が優れています」とだけ言ってはいけません。これは、RADツール自体に関する議論ではありません。この質問は、一般的なRADツールに関するものであり、私の質問で述べたもののメリットではありません。
沖江、そういうわけで、このような状況で非常に重要なことがここにあります。 RADツールの使用は悪くありませんが、ツールの動作の基本に関する知識の欠如は確かに悪いことであり、これは間違いなく取り組むべき領域です。
自分のユースケースの例を引用すると、ツール/プラグインをAJAXリクエストに使用しているときに、同じまたは類似のユースケースを自分の手で実験する簡単なスニペットを試すことができなくなります-書かれたAJAX Java-scripts。これは、あなたが行っている作業を理解し、評価するのに役立つ、ものがどのように機能するかについてのこの絶え間ない実験と資料を読むことです。
幸せな読書、コーディング、実験、そして学習!!!
私の経験では、それはコントロールに依存しますが、ほとんどの場合、それらが有用であることがわかりました。特にリッチテキストエディタといくつかのカレンダーコントロール。それが本当に理にかなっているのは、コントロールのコストが、あなたや開発者が自分で構築するのにかかるコストよりも少ない場合だけです。一般に、コントロールは非常によくテストされており、四半期ごとに更新されます。これは、ほとんどの場合かなり費用対効果が高くなりますが、キッカーは、コントロールが見た目や見栄えが良いからではなく、思い通りのコントロールを選択できるようにします。何か（OTS RADコントロールは、ほとんどの開発者が想像できるよりもずっときれいに見えます）。
RADツールはときどき苦痛になる可能性があり、ビルドを数日間中断するバグのある更新を1つか2つ見たことは間違いありません。同時に、これらのツールを使用すると、妥当な時間内に自分で複製する可能性が非常に低いことを実行できることがよくあります。あなたは自分のプロジェクトに取り組む必要があるので、InfragisticsやTelerikのような企業がそれだけのリソースを大量に注ぐときに、独自のリッチテキストボックスやフィルタリングされたデータグリッドを構築する必要はありません。 RADツールをいじるのに費やす時間は長いように思えるかもしれませんが、同じ品質のコンポーネントを自分で構築するのにかかる時間と比べると、おそらく時間はまったくありません。あなたが構築するコントロールが同じように機能する限り、見た目は重要ではないと考える...あなたの顧客は同意しないかもしれません。
抽象化自体が問題になることはめったにないと言って記録に残しておきます。
問題のほとんどは、提供された抽象化が不完全であるか、一貫性がないか、または解決しようとしているタスクにあまり適していない場合に発生します。多くのRAD=ツールの場合、抽象化それ自体とは何の関係もない問題も発生しますが、これは主に設計や実行の問題です-バグの多いツール、管理が不十分開発サイクルなど。
Web開発は、実行環境を設計するという（ほぼ）独自の要素を追加します。これは、非常に大まかに定義されているため、ユーザーが実際にマシンで実際に見たり体験したりすることの一般的な知識以上のものを実際に提供できるテストはほとんどありません。これは、低品質のWeb指向RADツールです。これは、この場合、ベンダー/ツールを選択する際の細心の注意が通常よりもさらに重要であることを意味します。
私の意見では、RADツールは、迅速な開発や、何をしているのかを知っている専用のWeb開発者が不足している開発チームに適しています。
RADツールを使用して行うことはすべて、jQueryと独自のajaxコントロールを使用して社内で実行できます。箱から出してすぐに実行できるものを実行している場合はRADツールは多くの時間を節約できます。
しかし、より高度な作業を開始するとすぐに、それらのツールと戦うことになります。これらのツールのAPIを学習して、必要な処理を実行するには、多くの時間を費やす必要があります。
私が見つけたいくつかの欠点は次のとおりです。
- 彼らが作成するマークアップは、常に最良であるとは限りません。
- バグが発生した場合は、修正のために新しいリリースを待つことに制限されます。
- あなたは彼らがサポートするものに制限されています。たとえば、インフラジスティックスはIEのみをサポートします。
- ルックアンドフィールをある程度制御できなくなります。彼らがCSSまたはそれを変更する方法を提供していない場合、あなたにとってはあまりにも悪いです。
- 開発チームの規模によっては、かなり高額になる可能性があります。
現在、私は実際にWebアプリからInfragiscticsコントロールを削除する作業を行っています。私の会社にこれを行うよう説得するのに2年近くかかりました。現在、社内にWeb開発者の専任チームがあり、チームの全員が手動またはjQueryプラグインを使用することを好むため、インフラジスティクスにお金を費やす理由はもうありません。ライセンスのみで年間約2万件以上の節約になります。それはかなりのペニーです。
RADスイートに投資する場合は、それが希望どおりに機能することを確認してください。デモオブジェクトを使用してページを作成します。使いやすさを確認します。生成されたマークアップを確認します。作成サポートされているすべてのブラウザでデモサイトにアクセスし、すべてが機能することを確認します。レビューを読み、最も重要なのはサポートフォーラムを確認することです。開発者は実際に質問に答えますか、それともそれですか。解決策がほとんどないか、まったくない質問がたくさんありますか？
RADツールvs RADツールは非常に単純な問題です。
それは3つの基準に分類されます
- 締め切りはどれくらい厳しいですか？
- 抽象化レベルのチェーンを下って自分でやる経験はありますか？.
- RADツールが提供する抽象化はどれほど漏れやすいか。
時間と経験があれば、RAD使用するツールは自分で書いたものだけです。他のすべてのRADツールはリークが多すぎます。
時間や経験がなく、実際の期限がある場合は、プロジェクトを期限までに要件を満たすために、できる限りのことを行ってください。 RADツールを使用して要件を満たすことができる場合は、それを実行してください。要件を満たす必要があるのは最小限です。