「設定より規約」プログラミング モデルを評価するにはどうすればよいですか?

返信内容:

これは、このような言語を見たことがないフレームワークの設計コンセプトです。 言語の文法は規約とみなすことができます
コンパイラーまたはインタープリターのパラメーターが文法の意味やサポートに影響を与える可能性がある場合、それは構成とみなされます。 精神的なスペースをタイピング速度と引き換えに 人間はとても怠け者です。時間とエネルギーを節約できるのに、なぜそのような面倒な作業を繰り返さなければならないのでしょうか。 lavavelについて考えたのですが、例を教えていただけますか~~ 哀れな Java 開発者として、感情的なことについて話させてください。
複数のコンポーネントを組み合わせる場合、これらの構成ポイントのデフォルト値が何であるか、またそれらが必要かどうかを知ることは不可能であるため、それを構成して 100 個の構成ポイントを 100 回書き込むことができます。
その後、合意は Java のゲッターとセッターのようなもので、name 属性、そのセッターは setName である必要があり、ゲッターは getName である必要があり、設定で指定する必要はなく、setName と getName を直接取得できます。反射を使って。
これは設計コンセプトです。チームは 1 2 3 の条件に同意します。たとえば、dao の基礎となる SQL クエリでは、追加を示すために add_ を使用し、削除を示すために del_ を使用します。その後、トランザクションを設定するときに、単に add_* を指定します。はい、これは合意です。間違いを犯す可能性を減らします。これはエンジニアリング レベルのことなので、Java のゲッターとセッターと同様に、それを言語に拡張することも規約と見なすことができますが、言語の柔軟性を高めるために、言語への拡張は少なくなります。このような慣例は、枠組みで合意されたものと同じくらいカジュアルなものではありません。 知らない人より知り合いと仕事したほうがいいみたいだけど現実は残酷だ 設定よりも慣習を重視すると、経験豊富な人はすぐに使い始めることができますが、慣れていない人の学習コストは増加します。
設定よりも規約を優先すると、スケーラビリティの低下につながり、設定の不足を補うために大量の実装が必要となり、最終的には学習コストの増加に反映されます。
設定よりも慣例により、経験豊富な人々が馴染みのある分野で迅速に開発できるようになりますが、これは長期的には必ずしも良いことではありません。 合意は構成より重要です。合意を覚えていれば、作成する構成ファイルは少なくなります。 見たことのない言語はどれですか? Go 言語の関数の最初の文字がパブリックを表すために大文字であり、プライベートを表すために小文字である場合はカウントされますか?