ビジネスソフトウェアでラムダ関数またはメソッドを使用することは許容されますか？

ここで、デリゲート\ラムダ関数を使用して、中間のアイデアの穴を多くの繰り返しなしで解決することを示す投稿に気付きました：http : //www.markhneedham.com/blog/2009/04/04/functional-c -中間の穴のパターン/

問題は、ジュニア開発者や他の人が必ずしも関数pointer \ delegate \ lambda関数の概念が何であるかを理解していないため、コードの読み取り（およびデバッグ）が難しくなるようです。

特に小さなチームや単独のデベロッパーショップで、ビジネスソフトウェアを作成する際にこのツールの使用を回避または厳しく制限する必要がありますか？

または、適切なコメントを付けて使用して、次の開発者がラムダ関数について理解または学習することをもはや期待していないことを期待できますか？

問題は、ジュニア開発者や他の人が関数pointer \ delegate \ lambda関数の概念が何であるかを必ずしも理解していないようです

率直に言って、それが彼らの問題です。それはあなたが彼らが訓練を受けていることを保証するものです。一部の人々はそれを理解していないかもしれないという理由だけで良いテクニックを使用することはできません。彼らはそれで助けが必要な場合は、著者に尋ねることができます。さらに重要なことは、ラムダ関数が非常に一般的な言語機能になりつつあることです。

一部の人々はそれを理解していないため、継承を使用すべきではありませんか？地獄、一部の人々は、科学や細菌、または何らかのばかげたことを信じることを拒否します。あなたは先に進むことができなければならず、他の人があなたに追いつくことができないという可能性を許して、あなたができる最高のコードを書くのを止めなければなりません。Lambda関数は優れた機能であり、コードの記述に大いに役立ちます。入手できるすべての支援を受ける必要があります。

開発者は、自分が未熟な言語の使用方法を知っている必要があります。そうでない場合は、彼らを解雇し、そのような人を見つけるか、彼らが訓練するように訓練します。

はい、それらを使用します。

私はジュニア開発者であり、ラムダ（およびあなたが言及した他の概念）を知っている/理解しています。ジュニア開発者が非常に短い時間でこれらすべての概念を学習するのを防ぐことはできないと思います。ジュニアは、ソフトウェア開発の多くの落とし穴に関して同じ量の経験/専門知識を持っていないかもしれませんが、ラムダのような概念は、プログラミングとインターネット接続の基本的な理解を持っている人なら誰でも簡単に理解できます。また、例としてラムダを選択したことは奇妙に思えますが、C＃を使用している場合、ジュニア開発者よりもラムダを学ぶことはあまりないでしょう（2008年に導入されたのは、私が正しく覚えてください）。

要するに、私たちの初心者のためにあなたのコードを馬鹿にする必要はありません。私たちは大丈夫ですし、実際にあなたが思い付くことができる最高の実装に取り​​組むことを好むでしょう。:)

それらがあなたの問題に対する賢明な解決策であるなら、あなたはそれらを使うべきです。

人工的に自分自身を制限しないでください-維持するのが難しい低品質のコードで終わる可能性が高くなります。

コードが適切なコメントを使用して適切に記述されている場合、後続のユーザーはあなたから学ぶことができるはずです。

msdnのドキュメントへのリンクを、それを使用するブロックの上部にあるコメントに入れてから先に進みます。開発者が知らないことを学ぶための仕事の一部である、新しい/複雑なテクノロジーを使うことを恐れる必要はありません。

問題は、ジュニア開発者や他の人が関数pointer \ delegate \ lambda関数の概念が何であるかを必ずしも理解していないようです

その後、彼らはそれらを学ぶ必要があります。期間。

1. これはC＃の難解なコーナーではありません。多くの.Netライブラリを使用するには、それらを理解する必要があります。
2. これは一般に難解な言語のトピックではありません。現在一般的に使用されているほぼすべての言語には、何らかの機能ポインターがあり、ほとんどの言語にはクロージャーがあります（JavaとC ++の場合、まもなく取得されます）。

数分かけて説明してください。それは厳しくない。

ジョブに適したツールを使用する必要があります。手元にある問題を解決するためのよりシンプルで明確な方法があれば、それを使用してください。将来のメンテナーにとって高度なトピックであると思われるものに取り組む必要がある場合は、それを明確にマークし、テクニックを説明するドキュメントへのポインターを含めてください。

関数pointer \ delegate \ lambda関数の概念

これらは3つの異なるものであることに注意してください。

2つの可能なシナリオ：

a）同僚（またはそのほとんど）が適度に熟練している。彼らはラムダを学ぶ必要があり、言語の一部であり、時には仕事にぴったりのツールです。したがって、それらが本当に最良のツールである場合は、必ず使用してください。あなたは自分でそれらについて学んだだけで、あなたはすべて興奮していて、それらが銀の弾丸だと思うので、それらの使用を避けてください。

b）あなたの同僚（またはその大部分）は無能です。ラムダ、クロージャー、関数ポインター、またはその他の同様のメタコーディングの概念を完全に理解する方法はありません。おそらく、ポインター、参照、再帰を理解するのに苦労しているでしょう。この状況でできることは、就職活動をする必要があるため、弾丸を噛み、不器用で冗長なラムダフリーのソリューションを使用し、履歴書をブラッシュアップすることです。

これは、一貫性が大いに役立つ場所です。同じスタイルなどで一貫して使用する場合、読者はそれを一度学ぶだけでよく、それからどこでもそれを認識します。

また、少なくとも最初は明示的にすることが役立つ場合があります。たとえば、これら2つは同等です。

doSomething(() => someMethod());

doSomething(someMethod);

private void doSomething(Action someAction) { ... }
private void someMethod() { ... }

...しかし、最初のケースでは、ラムダ構文を知っていれば、我々が何をしているかは明らかです。ラムダ構文がわからなくても、何か新しいものを見ているのは明らかであり、調べなければなりません。2番目の場合、変数を渡しているように見えます。

ReSharperを使用すると、2番目のケースに変更するように促されることは知っていますが、それは常に良い考えかと思います。2番目のケースでは、が必要であることを知っておくdoSomething必要がありActionます。

特定の概念は、実際の現実の状況で遭遇するのではなく、抽象でしか説明されていないため、理解しにくいことがよくあります。だから、私は個人的にそのような構造に遭遇することに賛成だろう。

これを避けるために考えられる主なシナリオは、プログラミングが他の人の主な仕事ではない場合です。たとえば、システム管理者、またはほとんどの時間を実際の実験に費やす生物情報学者（「実験用ラット」）。

itemsList.ForEach(item => DoAction(item));
...
public void DoAction(Item item) {
  //...do various things here...
}

さて、ボディが長すぎてラムダ自体に収まらないため、ここでDoActionを呼び出しています。その場合、ForEach（）拡張メソッドをListに使用しても、通常のforeachループを使用するよりも多くの利点は得られませんが、数行のコードを節約できます。しかし、この特定のケースでは、ForEach（）を使用すると、実際にはより多くのコードを必要とし、必要以上にスタック上で余分なスラッシングが発生することになります。渡される引数は、ラムダである必要はまったくありません

次のように単純にDoActionを呼び出す必要があります。

itemsList.ForEach(DoAction);

ラムダはまったくありません。重要なのは、ラムダ式を作成するときに実際に何を渡しているのかを覚えておくことです。デリゲートインスタンスを定義するためのショートカットです。はい、クロージャなどの利点もありますが、メソッド呼び出しが期待するもののサイトを失うべきではありません。この場合、Actionの署名に一致するメソッドへのアドレスが必要です。DoActionはすでにそのようなメソッドであるため、ラムダの作成はまったく不要なメソッド呼び出しを追加するだけです。

私見は、チームの技術レベルよりも高い技術レベルで書くことは間違っています。チームメンバーがラムダ式と関数にあまり慣れておらず、学習に時間を費やしていない場合（パフォーマンスチューニングデータベースに時間を費やし、UIの作業を増やし、コンポーネントを作成するなど）、私は強くそれらを使用しないことをお勧めします。しかし、もし彼らが学習して自由な時間を持っているなら、あるいはすでに知識を知っているなら、なぜそうではないのでしょうか？

これは相対的な問題であり、チームおよびチームの技術レベルごとに判断する必要があると思います。そして、これはラムダ関数の場合だけではありません。これは技術知識の場合です。そのため、たとえば、チームがリポジトリパターンについて知っている場合は常に、それを実装および保守する専門知識があり、それを実行しましょう。しかし、そうでない場合は、別の方法を見つけてください。OO JavaScriptについて知っている場合は、JavaScriptでよりスケーラブルなコードを作成しましょう。しかし、そうでない場合は、手続き型JavaScriptに戻ってください。