Допустимо ли использовать лямбда-функции \ методы в деловом программном обеспечении?

Я заметил здесь посты, демонстрирующие использование функций делегатов \ лямбда для устранения дыры в средней идее без большого количества повторений: http://www.markhneedham.com/blog/2009/04/04/functional-c -The отверстия-в-среднего рисунка /

Кажется, проблема в том, что младшие разработчики и другие не обязательно понимают, что такое концепция функции указатель \ делегат \ лямбда-функция, что, кажется, затрудняет чтение (и, возможно, отладку) кода.

Должны ли мы избегать или строго ограничивать использование этого инструмента при написании программного обеспечения для бизнеса, особенно в небольших группах или в магазинах для индивидуальных разработчиков?

Или допустимо использовать его с соответствующими комментариями и ожидать, что, когда меня больше не будет, следующий разработчик поймет или узнает о лямбда-функциях?

Кажется, проблема в том, что младшие разработчики и другие не обязательно понимают, что такое концепция функции указатель \ делегат \ лямбда-функция

Откровенно говоря, это их проблема. Это то, что вы гарантируете им подготовку. Вы не можете не использовать хорошую технику только потому, что некоторые люди могут ее не понимать. Если им нужна помощь с этим, они могут прийти спросить автора. Что еще более важно лямбда-функции становятся чрезвычайно распространенными языковыми функциями.

Разве мы не должны использовать наследование, потому что некоторые люди не понимают его? Черт, некоторые люди отказываются верить в науку или микробы или любые другие нелепые вещи. Вы должны быть в состоянии двигаться дальше и не допускать, чтобы другие не могли идти в ногу с вами, чтобы вы не могли написать лучший код, какой только можете. Лямбда-функции - это отличная функция, которая очень помогает в написании кода, и вы должны использовать всю возможную помощь.

Разработчик должен знать, как использовать язык, на котором он младший или нет. Если они этого не делают, то уволите их и найдите кого-то, кто делает, или обучите их, чтобы они сделали.

Да, используйте их.

Я младший разработчик, и я знаю / понимаю лямбды (и другие концепции, которые вы упомянули). Я ничего не мог упустить, чтобы помешать начинающему разработчику изучить все эти концепции за очень короткое время. У юниоров может не быть такого количества опыта / опыта, когда дело доходит до многих задач разработки программного обеспечения, однако такие понятия, как лямбда-выражения, могут быть так же легко понятны любому, кто имеет базовое понимание программирования и интернет-соединения. Кроме того, кажется странным, что вы выбрали лямбду в качестве примера, учитывая, что если вы используете C #, то, скорее всего, у вас даже не будет большого успеха в изучении лямбд у младших разработчиков (они были введены только в 2008 году, если я помните правильно).

Короче говоря, нам, новичкам, не нужно заглядывать в ваш код. У нас все будет хорошо, и мы действительно предпочли бы работать над наилучшей из возможных реализаций, которую вы можете придумать. :)

Если они являются разумным решением вашей проблемы, то вы должны их использовать.

Не ограничивайте себя искусственно - у вас больше шансов получить некачественный код, который сложно поддерживать.

Если код хорошо написан с соответствующими комментариями, то последующие должны быть в состоянии учиться у вас.

Поместите ссылку на документацию msdn в комментариях вверху блока, который ее использует, и продолжайте. Вы не должны бояться использовать новые / сложные технологии, это часть работы разработчиков, чтобы изучать вещи, которые они не знают.

Кажется, проблема в том, что младшие разработчики и другие не обязательно понимают, что такое концепция функции указатель \ делегат \ лямбда-функция

Тогда они должны изучить их. Период.

1. Это не эзотерический уголок C #. Вы должны понимать их, чтобы использовать много библиотек .Net.
2. Это вообще не эзотерическая языковая тема. Практически каждый популярный сегодня язык имеет свой вид указателя на функцию, и большинство из них имеют (или скоро получат, в случае Java и C ++) замыкания.

Просто потратьте несколько минут, чтобы объяснить это им. Это не сложно.

Вы должны использовать правильный инструмент для работы. Если есть более простой и понятный способ решения проблемы, используйте его. Если вам нужно заняться чем-то, что, по вашему мнению, может быть сложной темой для будущих сопровождающих, отметьте это четко и включите указатель на документацию, объясняющую методику.

указатель на функцию \ делегат \ концепция лямбда-функции

Следует отметить, что это три разные вещи.

Два возможных сценария:

а) Ваши коллеги (или большинство из них) достаточно опытны. Им нужно учить лямбды, они являются частью языка, а иногда они являются именно тем инструментом, который подходит для работы. Поэтому, когда они действительно лучший инструмент, обязательно используйте их. Просто избегайте их использования, потому что вы только что узнали о них сами, и вы все взволнованы и думаете, что это серебряная пуля.

б) Вы коллеги (или большинство из них) некомпетентны. Они никогда не смогут полностью понять лямбды, замыкания, указатели функций или любую другую подобную концепцию мета-кодирования. Они, вероятно, изо всех сил пытаются понять указатели, ссылки и рекурсию уже. В этой ситуации лучшее, что вы можете сделать, - это прикусить пулю, использовать неуклюжее, многословное, не содержащее лямбду решение и почистить свое резюме, потому что вы должны искать работу.

Вот где последовательность может очень помочь. Если вы используете его в соответствии с тем же стилем и т. Д., То читатели должны выучить его только один раз, и тогда они узнают его повсюду.

Кроме того, это может помочь быть явным, по крайней мере, на первый взгляд. Например, эти два эквивалентны:

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 уже является таким методом, поэтому создание лямбды - это просто добавление совершенно ненужного вызова метода.

ИМХО, писать на любом техническом уровне выше, чем технический уровень команды, неправильно. Если членам вашей команды не очень-то нравятся лямбда-выражения и функции, и у них нет времени тратить на их изучение (им следует больше времени уделять настройке производительности, работе над пользовательским интерфейсом, созданию компонентов и т. Д.), Тогда я настоятельно рекомендую предлагаю не использовать их . Однако, если они хотят учиться и имеют свободное время, или они уже знают знания, то почему бы и нет?

Я думаю, что это относительный вопрос, который следует оценивать в зависимости от команды и технического уровня команды. И это не только случай лямбда-функций. Это дело технических знаний. Так, например, когда команда знает о шаблоне репозитория, у него есть опыт для его реализации и поддержки, тогда давайте сделаем это. Но если они этого не делают, просто найдите другой путь. Если они знают о OO JavaScript, давайте создадим более масштабируемый код на JavaScript. Но если они этого не делают, просто вернитесь к процедурному JavaScript.