Quanta esperienza di programmazione funzionale ci si può aspettare dai programmatori? [chiuso]

2

Sto codificando in un linguaggio non funzionale con meccanismi funzionali (C # per essere specifico, ma potresti sostituire, dire C ++ e usare i puntatori di funzione, o cosa hai) in una piccola squadra. È mia abitudine usare le tecniche funzionali - passare i delegati (oggetti che rappresentano funzioni) come argomenti, usando chiusure, funzioni anonime occasionali, ecc. - e cerco di documentarlo meglio di quanto ritenga che un programmatore ragionevole ne abbia bisogno. Guardando il codice vedo online e sulle comunità di Stack Exchange, penso che il mio stile sia abbastanza normale tra gli sviluppatori di C #.

Il nostro team, tuttavia, non è sofisticato in queste tecniche e finisco per dover spiegare (e difendere) me stesso - il mio alto livello di documentazione è effettivamente usato come prova da loro che non dovrei codificare il modo in cui io fare per motivi di leggibilità.

Ora, dato il trucco della mia squadra, capisco che potrei semplicemente rinunciare alla buona battaglia qui e codificare secondo i loro standard, comprenderne il meglio per la squadra. Qualcuno ha esperienza di successo usando studi empirici, criteri di accreditamento o liste di buone pratiche pubblicate da fonti rispettabili che suggeriscono che i programmatori oggi hanno più esperienza in questi idiomi di programmazione funzionale, e che, quindi, non abbiamo bisogno di evitarlo per scopi di manutenibilità?

    
posta jwrush 21.08.2013 - 23:03
fonte

2 risposte

10

Mi aspetto che qualsiasi C # professionale o sviluppatore web nel 2013 abbia familiarità con le funzioni anonime, le basi di chiusura e il concetto di metodi di passaggio. .NET 3.5 è stato fuori per anni e dovrebbe essere pervasivo.

Mi aspetto che gli più sviluppatori professionisti (di qualsiasi tipo) comprendano altri concetti tangenziali alla programmazione funzionale come immutabilità e funzioni pure, e come questi si applichino alla progettazione del programma. Anche questi concetti sono presenti nella programmazione tradizionale da secoli (e più in particolare negli ultimi 5 anni).

Detto questo, non sarei sorpreso se più della metà degli sviluppatori professionisti applicabili fossero completamente ignari di questi concetti - e tu sei in gran parte corretto che dovresti conformarti a ciò che è meglio per la squadra, proprio come sono in gran parte corretti che alti livelli di documentazione sono un odore di codice illeggibile.

Quindi, per ora, conformati e lavora per addestrare le persone, probabilmente attraverso una combinazione di addestramento esplicito e uso graduale di strutture funzionali più complicate (ove appropriato).

    
risposta data 21.08.2013 - 23:13
fonte
2

In C #, la programmazione funzionale è uno strumento appropriato quando devi navigare tra le collezioni. In questi casi, la programmazione funzionale rende il codice molto più breve e aiuta a concentrarsi sul problema anziché sulla sua implementazione , riducendo il rischio di errori.

Difficilmente puoi essere responsabile della riduzione della base di codici e del margine per gli errori utilizzando uno strumento appropriato.

Il problema che hai con i tuoi colleghi, ce l'ho nella società in cui lavoro attualmente. La maggior parte dei programmatori non conosce molto bene né C #, né programmazione in generale, il che mi rende una persona non molto popolare, dato che i miei colleghi hanno difficoltà a comprendere il codice che utilizza la programmazione parallela, i paradigmi funzionali, i contratti di codice e altre funzionalità di .NET Framework.

Una delle regole che ogni sviluppatore dovrebbe seguire è che il loro codice dovrebbe essere comprensibile in un determinato contesto . Ciò è in conflitto con il fatto che non si dovrebbe essere costretti a ridurre la qualità del codice solo perché lavora con persone non qualificate.

Ci sono due soluzioni:

  1. Insegna ai tuoi colleghi la programmazione funzionale e altre cose che conosci e loro no, cercando di aumentare il loro livello al tuo. Questo è ciò che ho scelto nel mio caso e ciò che suggerirei a chiunque.

    Vantaggi: la qualità della base di codici aumenterà e potresti apprezzare meglio lavorare con colleghi più esperti.

    Contro: molti programmatori non vogliono imparare cose. Lavorano per soldi e non si preoccupano del loro lavoro. Cercare di insegnare loro qualsiasi cosa sarebbe un compito estremamente difficile e si dovrebbe essere pronti a ricevere una strong resistenza.

  2. Inizia a scrivere un codice schifoso scritto per principianti. Dato che questo può essere disastroso per la motivazione, questa soluzione dovrebbe essere presa solo quando si lavora con persone incapaci e / o non disposte a imparare e in circostanze in cui è possibile smettere presto.

    Professionisti: questo può migliorare le relazioni con i colleghi se non vogliono imparare cose e non vogliono sforzarsi di leggere il tuo codice.

    Contro: questo diminuirà la qualità del codice base. Lavorare su progetti mal fatti che inevitabilmente fallire non è molto motivante.

Infine, i programmatori dovrebbero conoscere la programmazione funzionale? Dipende. Sarebbe obbligatorio per qualsiasi persona che lavora quotidianamente con C # per sapere quali sono i tipi anonimi e le espressioni lambda e come usarli in C #; d'altro canto, non direi che la stessa persona che non sa cosa sia una monade dovrebbe essere trattata come incompetente.

La differenza è che i tipi anonimi e le espressioni lambda sono la parte inerente di C # oggigiorno, mentre il termine monad non esiste nel mondo C #.

D'altra parte, mi aspetto che uno sviluppatore sia familiare ai concetti di programmazione funzionale come le monadi, anche se questo sviluppatore non li ha mai usati. Questo perché gli sviluppatori non solo si aspettano di scrivere codice in una determinata lingua, ma hanno abbastanza cultura generale e curiosità oltre gli strumenti che usano quotidianamente.

    
risposta data 21.08.2013 - 23:21
fonte