비즈니스 소프트웨어에서 람다 함수 / 방법을 사용할 수 있습니까?

나는 여기에 많은 반복없이 중간 아이디어의 구멍을 해결하기 위해 delegates \ lambda 함수를 사용하는 것을 보여주는 게시물을 발견했습니다 .http : //www.markhneedham.com/blog/2009/04/04/functional-c -홀-인-더-미들-패턴 /

문제는 주니어 개발자와 다른 사람들이 함수 포인터 \ 위임 \ 람다 함수 개념이 무엇인지 반드시 이해하지 못하는 것 같습니다. 코드를 읽기 (및 디버깅)하기가 더 어려워 보입니다.

특히 소규모 팀이나 단독 개발자 상점에서 비즈니스 소프트웨어를 작성할 때이 도구의 사용을 피하거나 심각하게 제한해야합니까?

또는 적절한 의견과 함께 사용하고 더 이상 주변에 없을 때 다음 개발자가 람다 함수를 이해하거나 배울 것이라고 기대할 수 있습니까?

문제는 주니어 개발자와 다른 사람들이 함수 포인터 \ 위임 \ 람다 함수 개념이 무엇인지 반드시 이해하지 못하는 것 같습니다

솔직히 말해서, 그것은 그들의 문제입니다. 그것이 그들이 훈련을받는 것입니다. 어떤 사람들은 그것을 이해하지 못할 수 있기 때문에 좋은 기술을 사용할 수 없습니다. 도움이 필요하면 저자에게 물어볼 수 있습니다. 더 중요한 것은 람다 함수가 매우 일반적인 언어 기능이되고 있다는 것입니다.

어떤 사람들은 그것을 이해하지 못하기 때문에 상속을 사용해서는 안됩니까? 지옥, 어떤 사람들은 과학이나 세균, 말도 안되는 일을 믿기를 거부합니다. 계속해서 다른 사람들이 당신을 따라 잡을 수 없을 가능성이 없어야 최선의 코드 작성을 막을 수 있습니다. Lambda 함수는 훌륭한 기능이며 코드 작성에 크게 도움이되므로 얻을 수있는 모든 도움을 받아야합니다.

개발자는 하급 언어를 사용하는 방법을 알아야합니다. 그렇지 않은 경우 해고하고 행동하는 사람을 찾거나 훈련 시키십시오.

예, 사용하십시오.

나는 주니어 개발자이며 람다 (및 언급 한 다른 개념)를 알고 이해합니다. 주니어 개발자가 짧은 시간 안에 모든 개념을 배우지 못하게 막을 수있는 것은 없습니다. 주니어는 소프트웨어 개발에있어 많은 경험과 경험을 가지고 있지 않을 수도 있지만 프로그래밍과 인터넷 연결에 대한 기본 지식을 가진 사람이라면 누구나 람다와 같은 개념을 쉽게 이해할 수 있습니다. 또한 C #을 사용하고 있다고 생각할 때 람다를 예로 선택하는 것이 이상하게 보입니다. 하급 개발자보다 람다를 배우는 데 많은 머리를 기울이지 않아도 될 것입니다 (2008 년에 도입 된 경우) 올바르게 기억하십시오).

요컨대, 우리를 위해 당신의 코드를 바보로 만들 필요가 없습니다. 우리는 괜찮을 것이며 실제로 구현할 수있는 최상의 구현을 선호합니다. :)

그들이 당신의 문제에 대한 합리적인 해결책이라면 그것들을 사용해야합니다.

인위적으로 자신을 제한하지 마십시오. 유지하기 어려운 품질이 낮은 코드로 끝날 가능성이 큽니다.

적절한 주석으로 코드를 잘 작성하면 다음 코드를 통해 배울 수 있습니다.

msdn 문서에 대한 링크를 사용하는 블록 맨 위에 주석을 달고 계속 ​​진행하십시오. 모르는 것을 배우기 위해 개발자의 일원 인 새로운 / 복잡한 기술을 사용하는 것이 무서워해서는 안됩니다.

문제는 주니어 개발자와 다른 사람들이 함수 포인터 \ 위임 \ 람다 함수 개념이 무엇인지 반드시 이해하지 못하는 것 같습니다

그런 다음 그들은 배워야합니다. 기간.

1. 이것은 C #의 난해한 코너 가 아닙니다 . 많은 .Net 라이브러리를 사용하려면이를 이해해야합니다.
2. 이것은 일반적으로 난해한 주제가 아닙니다. 오늘날 널리 사용되는 거의 모든 언어에는 약간의 기능 포인터가 있으며 대부분은 Java 및 C ++의 경우 곧 닫히고 있습니다.

그것들을 설명하기 위해 몇 분이 걸립니다. 어렵지 않습니다.

작업에 적합한 도구를 사용해야합니다. 당면한 문제를 해결하는 더 간단하고 명확한 방법이 있다면 그것을 사용하십시오. 미래의 관리자를위한 고급 주제라고 생각되는 부분에 들어가야 할 경우 명확하게 표시하고 기술을 설명하는 문서에 대한 포인터를 포함하십시오.

함수 포인터 \ 델리게이트 \ lambda 함수 개념

그것들은 세 가지 다른 것입니다.

두 가지 가능한 시나리오 :

a) 동료 (또는 대부분)는 합리적으로 숙련되어 있습니다. 그들은 람다를 배워야하고, 언어의 일부이며, 때로는 업무에 가장 적합한 도구입니다. 따라서 그들이 실제로 가장 좋은 도구 일 때는 사용하십시오. 당신은 단지 그들 자신에 대해 배우고 당신은 모두 흥분하고 그들이 총알이라고 생각하기 때문에 그들을 사용하지 마십시오.

b) 귀하의 동료 (또는 대부분)는 무능합니다. 람다, 클로저, 함수 포인터 또는 기타 유사한 메타 코딩 개념을 완전히 이해하는 방법은 없습니다. 그들은 포인터, 참조 및 재귀를 이미 이해하기 위해 고심하고 있습니다. 이 상황에서 당신이 할 수있는 최선의 방법은 총알을 물고, 서투른, 장황한, 람다가없는 솔루션을 사용하고 이력서를 닦는 것입니다. 직업 사냥이어야하기 때문입니다.

일관성이 많은 도움이 될 수있는 곳입니다. 동일한 스타일 등으로 일관되게 사용하면 독자는 한 번만 배우면 어디서나 인식 할 수 있습니다.

또한 적어도 처음에는 명시 적으로하는 것이 도움이 될 수 있습니다. 예를 들어,이 두 가지는 동일합니다.

doSomething(() => someMethod());

doSomething(someMethod);

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

...하지만 첫 번째 경우, 람다 구문을 알고 있다면 우리가하는 일이 분명합니다. 람다 구문을 모르더라도 새로운 것을보고 있다는 것을 분명히 알 수 있습니다. 두 번째 경우에는 변수를 전달하는 것처럼 보입니다.

나는 ReSharper가 당신을 두 번째 경우로 바꾸도록 강요한다는 것을 알고 있지만 그것이 항상 좋은 아이디어인지 궁금합니다. 두 번째 경우 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은 이미 그러한 메소드이므로 람다를 작성하는 것은 전혀 불필요한 메소드 호출을 추가하는 것입니다.

팀의 기술 수준보다 높은 기술 수준에서 쓰는 IMHO는 잘못되었습니다. 팀 구성원이 람다 식과 기능에 익숙하지 않고 학습 시간을 갖지 못하면 (성능 튜닝 데이터베이스에 시간을 소비하고, UI 작업, 구성 요소 작성 등) 강력하게 학습합니다. 사용하지 않는 것이 좋습니다 . 그러나 그들이 기꺼이 배우고 자유 시간을 가지거나 이미 지식을 알고 있다면 왜 그렇지 않습니까?

나는 이것이 팀과 팀의 기술 수준에 따라 판단되어야하는 상대적인 문제라고 생각합니다. 그리고 이것은 람다 함수의 경우만이 아닙니다. 기술 지식의 경우입니다. 예를 들어 팀이 리포지토리 패턴에 대해 알고있을 때마다이를 구현하고 유지 관리 할 수있는 전문 지식을 보유하고 있습니다. 그러나 그렇지 않은 경우 다른 방법을 찾으십시오. OO JavaScript에 대해 알고 있다면 JavaScript로 더 확장 가능한 코드를 만들어 봅시다. 그러나 그렇지 않은 경우 절차 적 JavaScript로 돌아가십시오.