È accettabile l'uso di funzioni \ metodi lambda nel software aziendale?

The problem seems to be that junior developers and others don't necessarily understand what the function pointer\delegate\lambda function concept is

Francamente, questo è il loro problema. Questo è quello per cui ti stai allenando. Non puoi non usare una buona tecnica solo perché alcune persone potrebbero non capirlo. Se hanno bisogno di aiuto, possono venire a chiedere all'autore. Ancora più importante, le funzioni lambda stanno diventando caratteristiche linguistiche estremamente comuni.

Non dovremmo usare l'ereditarietà perché alcune persone non lo capiscono? Diavolo, alcune persone si rifiutano di credere nella scienza o nei germi o in qualche modo di cose ridicole. Devi essere in grado di andare avanti e non lasciare che la possibilità che altri non siano in grado di tenere il passo con te ti impedisca di scrivere il miglior codice che puoi. Le funzioni Lambda sono una grande funzionalità e aiutano molto nella scrittura del codice, e dovresti prendere tutto l'aiuto che puoi ottenere.

Uno sviluppatore dovrebbe sapere come usare la lingua in cui è in corso o meno. Se non lo fanno, quindi licenziarli e trovare qualcuno che lo faccia, o addestrarli in modo che facciano.

Sì, usali.

Sono uno sviluppatore junior e conosco / capisco lambda (e gli altri concetti che hai menzionato). Non c'è nulla che io possa prevedere impedire a uno sviluppatore junior di imparare tutti questi concetti in pochissimo tempo. Juniors potrebbe non avere la stessa quantità di esperienza / esperienza quando si tratta di molti trucchi dello sviluppo software, tuttavia concetti come lambda possono essere compresi facilmente da chiunque abbia una conoscenza di base della programmazione e di una connessione internet. Inoltre, sembra strano che tu abbia scelto lambdas come esempio, considerando che se stai usando C # è probabile che tu non abbia nemmeno un grosso vantaggio sull'apprendimento dei lambda sugli sviluppatori junior (sono stati introdotti solo nel 2008, se io ricorda correttamente).

In breve, non c'è bisogno di mettere a tacere il codice per noi neofiti. Andrà tutto bene, e in effetti preferirebbe lavorare sulla migliore implementazione possibile che si possa ottenere. :)

Se sono una soluzione ragionevole al tuo problema, dovresti usarli.

Non limitarti artificialmente - è più probabile che tu finisca con un codice di scarsa qualità che è difficile da mantenere.

Se il codice è ben scritto con commenti appropriati, quelli che seguono dovrebbero poter imparare da te.

Inserisci un link alla documentazione di msdn nei commenti nella parte superiore di un blocco che lo utilizza, quindi procedi. Non dovresti avere paura di usare una tecnologia nuova / complessa, fa parte del lavoro degli sviluppatori per imparare cose che non sanno.

The problem seems to be that junior developers and others don't necessarily understand what the function pointer\delegate\lambda function concept is

Quindi hanno bisogno di impararli. Periodo.

1. Questo è non un angolo esoterico di C #. Devi comprenderli per utilizzare molte librerie .Net.
2. Questo non è un argomento di linguaggio esoterico, in generale. Praticamente ogni linguaggio nell'uso popolare oggi ha un certo sapore di puntatore a funzione, e la maggior parte ha (o sta per ricevere, nel caso di Java e C ++) chiusure.

Bastano pochi minuti per spiegarglielo. Non è difficile.

Dovresti usare lo strumento giusto per il lavoro. Se c'è un modo più semplice e più chiaro per risolvere il problema, usa quello. Se hai bisogno di entrare in qualcosa che ritieni possa essere un argomento avanzato per i futuri manutentori, contrassegnalo chiaramente e includi un puntatore alla documentazione che spiega la tecnica.

the function pointer\delegate\lambda function concept

Va notato che si tratta di tre cose diverse.

Due possibili scenari:

a) I tuoi colleghi (o la maggior parte di loro) sono abbastanza abili. Hanno bisogno di imparare i lambdas, sono parte della lingua e, a volte, sono esattamente lo strumento giusto per il lavoro. Quindi, quando sono davvero lo strumento migliore, con tutti i mezzi, usali. Evita di usarli solo perché li hai appena conosciuti e sei tutto eccitato e pensi di essere un proiettile d'argento.

b) I tuoi colleghi (o la maggior parte di loro) sono incompetenti. Non c'è modo che capiscano mai lambda, chiusure, puntatori di funzioni o altri simili concetti di meta-codifica. Probabilmente stanno già lottando per capire puntatori, riferimenti e ricorsioni. In questa situazione, il meglio che puoi fare è mordere il proiettile, usare una soluzione goffa, prolissa, priva di lambda e rispolverare il tuo cv, perché dovresti essere alla ricerca di un lavoro.

È qui che la coerenza può aiutare molto. Se la usi in modo coerente con lo stesso stile, ecc., I lettori devono solo impararlo una volta e poi riconoscerlo ovunque.

Inoltre, potrebbe essere d'aiuto essere espliciti, almeno all'inizio. Ad esempio, questi due sono equivalenti:

doSomething(() => someMethod());

doSomething(someMethod);

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

... ma nel primo caso è ovvio, se conosci la sintassi lambda, cosa stiamo facendo. Anche se non conosci la sintassi lambda, è ovvio che stai vedendo qualcosa di nuovo e devi cercarlo. Nel secondo caso, sembra che tu stia passando una variabile.

So che ReSharper ti spinge a cambiarlo nel secondo caso, ma mi chiedo se sia sempre una buona idea. Nel secondo caso, devi sapere che doSomething richiede un Action .

Spesso trovo che alcuni concetti siano difficili da capire perché vengono descritti solo in astratto, piuttosto che incontrarli in situazioni pratiche e reali. Quindi personalmente sarei favorevole all'incontro con tali costrutti.

Lo scenario principale che posso immaginare per evitare di farlo è se la programmazione non è il compito principale dell'altra persona. Ad esempio, un amministratore di sistema o un bioinformatico che trascorre la maggior parte del tempo a fare esperimenti reali (un "lab rat").

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

Ora, forse qui stiamo chiamando DoAction perché il suo corpo è troppo lungo per adattarsi alla stessa lambda. In tal caso, l'utilizzo del metodo di estensione ForEach () su List non ci dà un grande vantaggio sull'utilizzo del ciclo foreach regolare, anche se salva un paio di righe di codice, suppongo. Ma in questo caso particolare, l'uso di ForEach () potrebbe aver indotto noi a fare qualcosa che in realtà sta prendendo più codice, e causando alcuni extra thrash in pila del necessario; La discussione non ha bisogno di essere una Lambda per niente

Devi semplicemente chiamare DoAction in questo modo:

itemsList.ForEach(DoAction);

Niente Lambda. La chiave è ricordare che cosa stai passando veramente quando crei un'espressione lambda: qualcosa di una scorciatoia per definire un'istanza delegata. Sì, ha anche vantaggi come la chiusura, ma non si dovrebbe perdere il sito di ciò che si aspetta la chiamata al metodo. In questo caso, è in attesa di un indirizzo per un metodo che corrisponde alla firma di Azione. DoAction è già un tale metodo, quindi la creazione di lambda è solo l'aggiunta di una chiamata al metodo totalmente non necessaria.

IMHO, scrivendo a qualsiasi livello tecnico superiore al livello tecnico della squadra, è sbagliato. Se i membri del tuo team non si sentono a proprio agio con le espressioni e le funzioni lambda e non hanno tempo da dedicare all'apprendimento (dovrebbero passare il loro tempo sul database di ottimizzazione delle prestazioni, lavorare sull'interfaccia utente di più, creare componenti, ecc.) consiglia di non usarli . Tuttavia, se sono disposti a imparare e ad avere tempo libero, o se già conoscono la conoscenza, allora perché no?

Penso che questo sia un problema relativo che dovrebbe essere giudicato in base al livello tecnico della squadra e del team. E questo non è solo il caso delle funzioni lambda. Questo è il caso della conoscenza tecnica. Quindi, ad esempio, ogni volta che un team conosce il modello di repository ha le competenze per implementarlo e mantenerlo, quindi provalo. Ma se non lo fanno, semplicemente trovare un altro modo. Se sono a conoscenza di OO JavaScript, allora crea un codice più scalabile in JavaScript. Ma se non lo fanno, torna semplicemente a JavaScript procedurale.