＆＃8220;マジック＆＃8221;の何が問題になっていますか？

Question

私は、Railsを使用するかDjangoの第一人者を使用してWebアプリを作成するかを決定しようとしています。 「マジック」の使用量が少ないため、Djangoを使用することをお勧めします。私の観点からは、しかし、「魔法」 Railsは、請負業者の開発をより簡潔にすることができ、その結果、費用の請求可能時間が短くなるため、良いことのように思えます。 Djangoの利点はよりきめ細かな制御である可能性があることを理解していますが、この制御が必要かどうかはどうすればわかりますか？ 「マジック」に固有の問題がありますか？

Answer 1

さて、Railsのいくつかの「マジック」について考えてみましょう。コントローラクラスを記述すると、そのメソッドは特定の変数と特定の他のクラスにアクセスできます。しかし、これらの変数とクラスは、あなたが見ているRubyコードのファイルの何によっても定義もインポートもされていません。 Railsは、舞台裏で多くの作業を行って、自動的に存在するようにしました。また、コントローラーメソッドから何かを返すとき、Railsは結果が適切なテンプレートに確実に渡されるようにします。どのテンプレートを使用するか、どこで見つけるかなどを指示するコードを記述する必要はありません。

言い換えれば、これらのことが「魔法」によって起こるかのようです。指を持ち上げる必要はありません、彼らはあなたのために起こります。

対照的に、Djangoビューを作成するときは、使用する予定のものをインポートまたは定義する必要があり、使用するテンプレートとテンプレートがアクセスできる値を明示的に指定する必要があります。

Railsの開発者は、この種の「マジック」は、何かをすぐに機能させるのが簡単になり、手を差し伸べてオーバーライドする場合を除き、多くの詳細に飽き飽きしないので、良いことです。

Djangoの開発者は、この種の「魔法」は、それほど多くの時間を実際に節約しないため（悪いことです）（いくつかの import ステートメントは、物事の壮大な計画では大したことではありません） 、ものをオーバーライドする方法を見つけにくくするか、何かがうまくいかない場合にデバッグするのを難しくします。

これらはどちらも、当然、有効なスタンスであり、一般的に、人々は自然にどちらかに引き寄せられるようです。 「魔法」が好きな人Railsやそれをエミュレートしようとするフレームワーク、Djangoやそれをエミュレートしようとするフレームワークの周りに集まらない人たち（そして広い意味では、これらのスタンスはRubyやPython開発者のステレオタイプです; Ruby開発者は好む傾向があります一方向に物事を行うと、Python開発者は別の方法で物事を行うのが好きです。

長い目で見れば、あなたが関心を持っていると言う要因-請求可能な時間-に大きな違いはおそらくないので、開発者に最も快適なものを選択させてください。 あなたにとって有用な結果が得られる可能性があります。

Answer 2

主な問題は、魔法を理解していないときに発生します。これは、ひどく去勢されたアプリケーションから、散発的で致命的なクラッシュまで、あらゆるものにつながる可能性があります。

Answer 3

マジックは、何かが壊れるまで素晴らしいです。次に、これらのトリックがどのように機能するかを理解する必要があります。

詳細については、Joel Spolskyの Lake of Leaky Abtractions

をご覧ください。

Answer 4

マジックは機能を難読化します。明示的にではなく暗黙的に振る舞いを作成するため、プログラマーは振る舞いがどのように機能するか、さらに重要なこととして、振る舞いを変更する方法を理解する必要がありません。

コーダーが使用しているコードベースを完全に把握している場合、「マジック」生産性を大幅に向上させることができます。しかし、高度な複雑さを持つWebフレームワークのようなサードパーティシステムを使用する場合、そのレベルの専門知識を得るのにさらに時間がかかる場合があります。

今、あなたが仕事をするために誰を雇うべきかという問題について：あなたの請負業者のコードを理解する他のプログラマーの長期的な能力を心配しているなら、Djangoと一緒に行くことは理にかなっているかもしれません好み）。ただし、Webサイトを将来にわたって維持できるRailsエキスパートは多数います。

選択するのは、評価している請負業者の中で、a）実績があり、b）信頼できる人です。優れた開発者はRailsまたはDjangoのどちらでもうまくいくでしょう。

Answer 5

マジックを使用する場合、システムの一部を確実に理解するために、全体を理解する必要があります。調べているピースに魔法が影響していないかどうかを判断するのは難しいので。

それは物語を読んで、著者に関連するプロットのねじれを省いてもらうようなものです。なぜなら、それらは反復的だからです。

Shazam

Answer 6

＆quot; magic＆quot;の問題それはあなたから多くのものを隠すことであり、IMOは問題を追跡したり、「箱の外」を考え始めたら何をすべきか/最適化するのを難しくします。そして、「デッドマジックゾーン」になってしまいます。 （つまり、魔法が役に立たない部分）。

これはRuby on Railsの主要な問題です（誤解しないでください、私はRuby on Railsが好きです本当に）。それを始めるのは非常に簡単です。そして、Railsがあなたのために仕事をしていないか、Railsの慣習が合わない暗礁に出くわすと...あなたがいない限り、あなたはかなりめちゃくちゃですあなたはもう魔法に頼ることができず、それがあなたからすべてを抽象化したので、あなたはそれを「難しい方法」

Answer 7

Magicは、しばしば「組み込みの仮定を使用してパフォーマンスまたは構文を最適化する」ことを意味します。もちろん、十分に文書化されたコードでは、これらの仮定は明示的な制約として言及されています。

魔法は素晴らしい場合があります。それは、書く必要があるものを本当に削減するか、速度を劇的に向上させるからです。しかし、これらの仮定に無数の方法で違反する可能性があり、予期しないエラーに遭遇したり、さらに悪いことに、目立たないバグが発生したりします。

Answer 8

魔法について言えば、Rails、Django、そしてすべてではないにしても、ほとんどのフレームワークが何らかの魔法を行っていると思います。それらが物事を抽象化する方法、APIで低レベルサービスをラップする方法、ルートとコントローラーを統合する方法などは、ほとんど知識のない人にとっては魔法のようなものです。 Railsにはもっと多くの魔法があり、人々が時々迷子になることもあると思います。ただし、そのためだけにRailsを却下するべきではありません。私が言ったように、魔法が非常に悪いということではなく、ほとんどの場合、Railsだけが魔法を行います。 Railsは非常に高速に進化し、コードの品質が向上し、ますますモジュール化されていることがわかります。 Rails周辺のリソースは膨大です。それらも考慮に入れる必要があります。

Answer 9

Guoliang Caoが指摘したように、ある種の「魔法」が常にあります。オペレーティングシステム「魔法のように」から始めて、あなたが依存していることキーボード入力を取得して、画面上の適切な場所にレンダリングします。すべてのWebフレームワークは、Webページに投稿されたパラメーターを解析し、簡単にアクセスできるようにデータ構造に配置します。 Railsの作成者（私は同意する傾向があります）は、Webアプリケーションの開発方法について非常に強い意見を持っているため、Railsは魔法のようにできることに積極的です。ですから、質問は本当に「どれだけの魔法」である必要があります。固有の問題がある場合ではなく、適切です。