È accettabile utilizzare funzioni / metodi lambda nei software aziendali?

Ho notato post qui che dimostrano l'uso di funzioni delegates \ lambda per risolvere il buco nell'idea centrale senza troppe ripetizioni: http://www.markhneedham.com/blog/2009/04/04/functional-c -il-hole-in-the-middle-pattern /

Il problema sembra essere che gli sviluppatori junior e altri non capiscono necessariamente qual è il concetto della funzione pointer pointer \ delegate \ lambda, il che sembra rendere più difficile la lettura (e possibilmente il debug) del codice.

Dovremmo evitare o limitare severamente l'uso di questo strumento nella stesura di software aziendali, in particolare nei negozi per piccoli team o per sviluppatori unici?

Oppure è accettabile usarlo con commenti appropriati e aspettarsi che quando non ci sarò più il prossimo sviluppatore capirà o imparerà le funzioni lambda?

Il problema sembra essere che gli sviluppatori junior e altri non capiscono necessariamente qual è il concetto di funzione pointer pointer \ delegate \ lambda

Francamente, questo è il loro problema. Questo è ciò per cui ti assicuri che abbiano una formazione. Non puoi non usare una buona tecnica solo perché alcune persone potrebbero non capirla. Se hanno bisogno di aiuto, possono venire a chiedere all'autore. Ancora più importante, le funzioni lambda stanno diventando caratteristiche del linguaggio estremamente comuni.

Non dovremmo usare l'eredità perché alcune persone non lo capiscono? Inferno, alcune persone si rifiutano di credere nella scienza o nei germi o in qualsiasi modo di cose ridicole. Devi essere in grado di andare avanti e non lasciare che la possibilità che gli altri non siano in grado di tenerti al passo con te ti impedisce di scrivere il miglior codice possibile. 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 che è minore o meno. Se non lo fanno, quindi licenziali e trova qualcuno che lo fa, oppure allenali in modo che lo facciano.

Sì, usali.

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

In breve, non è necessario smorzare il codice per noi neofiti. Staremo bene e in realtà preferiremmo lavorare sulla migliore implementazione possibile. :)

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

Non limitarti artificialmente: hai maggiori probabilità di finire con un codice di scarsa qualità che è difficile da mantenere.

Se il codice è ben scritto con commenti appropriati, quelli che seguono dovrebbero essere in grado di imparare da te.

Inserire un collegamento alla documentazione msdn nei commenti nella parte superiore di un blocco che lo utilizza, quindi andare avanti. Non dovresti aver paura di usare la tecnologia nuova / complessa, fa parte del lavoro di uno sviluppatore per imparare cose che non sanno.

Il problema sembra essere che gli sviluppatori junior e altri non capiscono necessariamente qual è il concetto di funzione pointer pointer \ delegate \ lambda

Quindi devono impararli. Periodo.

1. Questo non è un angolo esoterico di C #. È necessario capirli per utilizzare molte librerie .Net.
2. Questo non è un argomento di lingua esoterica, in generale. Praticamente ogni lingua di uso popolare oggi ha un po 'di sapore di puntatore a funzione e la maggior parte ha (o sta ottenendo presto, nel caso di Java e C ++).

Ti bastano pochi minuti per spiegarglielo. Non è difficile.

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

il puntatore alla funzione \ delegate \ lambda function concept

Va notato che queste sono tre cose diverse.

Due possibili scenari:

a) I tuoi colleghi (o la maggior parte di loro) sono abbastanza abili. Devono imparare le lambda, fanno parte della lingua e, a volte, sono esattamente lo strumento giusto per il lavoro. Quindi, quando sono davvero lo strumento migliore, sicuramente li usano. Evita semplicemente di usarli perché ne hai appena imparato tu stesso e sei tutto eccitato e pensi che siano un proiettile d'argento.

b) Voi colleghi (o la maggior parte di loro) siete incompetenti. Non potranno mai comprendere appieno lambda, chiusure, indicatori di funzione o altri simili concetti di meta-codifica. Probabilmente stanno già lottando per comprendere puntatori, riferimenti e ricorsioni. In questa situazione, il meglio che puoi fare è mordere il proiettile, usare una soluzione goffa, verbosa, senza lambda e spazzolare il tuo CV, perché dovresti cercare lavoro.

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

Inoltre, potrebbe essere utile 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 doSomethingrichiede un Action.

Trovo spesso alcuni concetti difficili da capire perché sono descritti solo in astratto, piuttosto che incontrarli in situazioni pratiche e di vita reale. Quindi sarei personalmente favorevole all'incontro con tali costrutti.

Lo scenario principale che mi viene in mente 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 "topo da laboratorio").

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 offre molti vantaggi rispetto all'utilizzo del normale ciclo foreach, anche se salva un paio di righe di codice, suppongo. Ma in questo caso particolare, l'uso di ForEach () potrebbe averci indotto a fare qualcosa che in realtà richiede più codice e che causa un ulteriore thrashing sullo stack del necessario; L'argomento superato non deve essere affatto un Lambda

Dovresti semplicemente chiamare DoAction in questo modo:

itemsList.ForEach(DoAction);

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

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

Penso che questo sia un problema relativo che dovrebbe essere valutato per squadra e livello tecnico della squadra. E questo non è solo il caso delle funzioni lambda. Questo è il caso delle conoscenze tecniche. Ad esempio, ogni volta che un team è a conoscenza del modello di repository ha le competenze per implementarlo e mantenerlo, quindi facciamolo. Ma se non lo fanno, trova semplicemente un altro modo. Se conoscono OO JavaScript, allora lascia che creino codice più scalabile in JavaScript. Ma se non lo fanno, torna semplicemente al JavaScript procedurale.