Rails と Django のどちらを使用して Web アプリを作成するかを決めようとしています。「魔法」の使用が少ないため、Django を使用することをお勧めします。しかし、私の観点からは、Rails の「魔法」は良いことのように思えます。なぜなら、請負業者にとって開発がより簡潔になり、私の費用で請求可能な時間が減るからです。Django の利点はよりきめ細かな制御であることは理解していますが、この制御が必要かどうかはどうすればわかりますか? 「魔法」に固有の問題はありますか？
8550 次
9 に答える
81
さて、Railsの「魔法」を少し考えてみましょう。コントローラークラスを作成すると、そのメソッドは特定の変数や他の特定のクラスにアクセスできます。しかし、これらの変数とクラスは、あなたが見ているRubyコードのファイル内の何によっても定義もインポートもされていません。Railsは、自動的に存在するようにするために、舞台裏で多くの作業を行ってきました。そして、コントローラーメソッドから何かを返すとき、Railsは結果が適切なテンプレートに渡されることを確認します。使用するテンプレート、テンプレートの場所などを指定するコードを記述する必要はありません。
言い換えれば、これらのことが「魔法」によって起こるかのようです。あなたは指を持ち上げる必要はありません、彼らはあなたのために起こるだけです。
対照的に、Djangoビューを作成するときは、使用する予定のすべてのものをインポートまたは定義する必要があり、使用するテンプレートとテンプレートがアクセスできる値を明示的に指定する必要があります。
Railsの開発者は、この種の「魔法」は、何かをすばやく機能させるのが簡単になり、手を伸ばしてオーバーライドを開始したい場合を除いて、多くの詳細に飽きることがないため、良いことだと考えています。
Djangoの開発者は、この種の「魔法」はそれほど多くの時間を節約できないため（いくつかのimportステートメントは大したことではない）、悪いことだと考えています。実際に何が起こっているのかを隠したり、何かをオーバーライドする方法を理解したり、何か問題が発生した場合にデバッグしたりするのが難しくなります。
もちろん、これらはどちらも有効なスタンスであり、一般的に、人々はどちらか一方に自然に引き寄せられるようです。Railsやそれをエミュレートしようとするフレームワークの周りに集まる「魔法」が好きな人、Djangoやそれをエミュレートしようとするフレームワークの周りに集まらない人（そして、より広い意味で、これらのスタンスはRubyとPythonのステレオタイプです開発者;Ruby開発者はある方法で物事を行うことを好む傾向があり、Python開発者は別の方法で物事を行うことを好む傾向があります）。
長期的には、懸念している要素（請求可能な時間）には大きな違いはないでしょう。開発者に最も快適なものを選択させてください。あなたにとって有用な結果。
于 2009-01-14T06:22:08.317 に答える
36
主な問題は、魔法を理解していないときに発生します。これは、ひどく中性化されたアプリケーションから、散発的で致命的なクラッシュまで、あらゆるものにつながる可能性があります。
于 2009-01-14T02:33:05.737 に答える
23
何かが壊れるまで魔法は素晴らしいです。次に、これらすべてのトリックがどのように機能するかを理解する必要があります。
詳細については、ジョエル・スポルスキーの漏れのある誘引の法則を読んでください。
于 2009-01-14T06:27:25.200 に答える
13
マジックは機能を難読化します。明示的ではなく暗黙的に動作を作成するため、プログラマーは動作がどのように機能するか、さらに重要なことに、動作を変更する方法を理解する必要がありません。
コーダーが作業対象のコード ベースを完全に把握している場合、「魔法」によって生産性が大幅に向上します。しかし、高度に複雑な Web フレームワークのようなサードパーティ システムを使用する場合、そのレベルの専門知識を得るには、はるかに長い時間がかかる場合があります。
さて、その仕事をするために誰を雇うべきかという問題について: 他のプログラマーが請負業者のコードを長期的に理解する能力を心配しているなら、Django を使うのが理にかなっているかもしれません (それは確かに私の好みです)。しかし、Webサイトを将来にわたって維持できる非常に多くのRailsエキスパートが世の中にいます。
選択は、評価している請負業者の中で、a) 実績があり、b) 信頼できるかどうかにかかっている必要があります。優れた開発者は、Rails または Django のどちらでもうまく機能します。
于 2009-01-14T03:07:11.220 に答える
10
魔法を使用するとき... システムの一部を理解するには、全体を理解する必要があります。あなたが調べている作品に魔法がかかっていないかどうかを判断するのは難しいからです.
それは、物語を読んでいて、著者に関連するあらすじを省略してもらうようなものです。それらは繰り返されるからです。
シャザム
于 2009-01-14T02:39:13.710 に答える
9
「魔法」の問題は、それが多くのことをあなたから隠してしまうことであり、IMO は、問題を追跡したり、「既成概念にとらわれない」ことを考え始めると、何をすべきか/最適化するかを知ることを難しくします。魔法のゾーン」（つまり、魔法が役に立たない部分）。
IMO これは Ruby on Rails の主要な問題です (誤解しないでください。私は Ruby on Railsが本当に好きです)。それを使い始めるのは簡単すぎるし、Rails があなたのために仕事をしてくれなかったり、Rails の慣習が合わないところに行き詰まると...あなたはもう魔法に頼ることができず、あなたからすべてを抽象化したので、あなたはそれを「難しい方法」で行う方法がわからないので、Rubyの第一人者です。
于 2009-01-14T03:04:19.497 に答える
4
マジックとは、多くの場合、「組み込みの仮定を使用してパフォーマンスまたは構文を最適化する」ことを意味します。もちろん、十分に文書化されたコードでは、これらの仮定は明示的な制約として言及されています。
マジックは、書かなければならないものを大幅に削減したり、速度を劇的に向上させたりするため、素晴らしい場合があります。しかし、無数の方法でこれらの仮定に違反する可能性があり、予期しないエラーが発生したり、さらに悪いことに、気付かないバグが発生したりする可能性があります.
于 2009-01-14T02:58:16.763 に答える
3
Guoliang Cao が指摘したように、オペレーティング システムがキーボード入力を "魔法のように" 取得し、それを画面上の適切な場所にレンダリングすることから始めて、常に何らかの "魔法" に頼っています。すべての Web フレームワークは、Web ページに投稿されたパラメーターを解析し、簡単にアクセスできるようにデータ構造に配置します。Rails は、魔法のようにできることに対してより積極的です。なぜなら、その作成者 (私も同意見です) は、Web アプリケーションの開発方法について非常に強い意見を持っているからです。したがって、本質的な問題があるかどうかではなく、「どれだけの魔法」が適切であるかという問題が本当に適切であるべきです。
于 2012-11-29T21:53:00.820 に答える
3
魔法について言えば、Rails、Django、そしてすべてのフレームワークではないにしても、ほとんどのフレームワークが何らかの魔法を行っていると思います。物事を抽象化し、低レベルのサービスを API でラップし、ルートとコントローラーを統合するなどの方法は、背後をほとんど知らない人々にとって一種の魔法です。Rails にはより多くの魔法があり、人々が時々道に迷うことがあることは認めます。しかし、それだけでRailsを否定するべきではありません。私が言ったように、魔法が非常に悪いというわけではなく、Rails だけが魔法を使い、ほとんどの人が魔法を使います。Rails は非常に急速に進化しており、コードの品質が向上し、ますますモジュール化されていることがわかります。Rails に関するリソースは膨大です。それらも考慮に入れる必要があります。
于 2009-06-09T21:41:29.730 に答える