Utilizzo di pratiche di codifica "off-paradigm" in una base di codice esistente

La mia domanda sarebbe, chi sosterrà questa applicazione quando la signora F # partirà per pascoli più verdi. È abbastanza difficile assumere dei buoni programmatori C # in questa città; dove trovo i programmatori F #? Cosa succede se F # cade di moda (è di moda?) E devo assumere un bambino che conosce Erlang e sta facendo del suo meglio per capire F #?

Non è che la lingua sia funzionale, sono i rischi coinvolti nella manutenzione successiva che è la considerazione principale. Se non esiste un sistema di supporto locale prontamente disponibile per la lingua proposta, dovrei dire di no. Altrimenti, chiederei un POC e vedere dove va.

Dipende da come è la squadra e come è il progetto. Se stiamo parlando di un grande sistema che viene sviluppato e gestito da un team di sviluppatori, la risposta è "probabilmente no". In tal caso, indipendentemente da chi ha scritto la feature originale, la squadra nel suo insieme deve mantenerla. Ciò significa che, per quanto possibile, ciascuna caratteristica dovrebbe essere sviluppata in modo che ogni altro membro della squadra possa saltare nel codice in qualsiasi momento. Se sei l'unico ragazzo che conosce F #, non funzionerà.

Un manager deve anche preoccuparsi di assumere nuovi sviluppatori. Possono trovare nuovi ragazzi di F # dalla strada? So che questo atteggiamento rende difficile l'apprendimento delle lingue più recenti (e forse migliori), ma alla fine il nostro compito è fornire software funzionante, non promuovere buone lingue.

D'altra parte, se tutta la squadra conosce F #, o vuole imparare F #, allora forse è ok. Indipendentemente da ciò, deve essere una decisione di squadra, così come tutto il resto del progetto.

D'altra parte, se questo qualcosa è completamente separato dall'attività principale, allora forse è ok. Qualche anno fa, avevamo il compito di scrivere un programma per eseguire alcune manipolazioni del database di back-end per creare dati per la nostra applicazione client. Lo sviluppatore voleva usare Perl, e dal momento che era completamente disaccoppiato dal nostro client (che usava C ++) e dal momento che non è difficile trovare persone Perl nel gruppo, questo non era un problema.

Chiediti cosa succederebbe se il tuo dev fosse investito da un autobus a metà dello sviluppo? Sarà un problema che il suo codice è tutto F #? Questo dovrebbe rispondere alla tua domanda per te.

Se fossi un manager, direi di si. Ecco perché.

Sviluppare una soluzione in un linguaggio adatto al problema è a mio avviso un gioco da ragazzi. Purché sia quantificabile più adatto di (e si integri bene con) il set di strumenti prevalente, uno sviluppatore può essere un ordine di grandezza più produttivo quando si utilizza lo strumento giusto rispetto a quando si cerca l'uniformità. Il prezzo che paghi per tale produttività è un aumento dei costi di manutenzione nel caso in cui la partenza dello sviluppatore originale o la scomparsa correlata al bus .

Il vantaggio tecnico tende a valerne il costo.

Per riff sul tuo esempio: F # non è una lingua molto popolare, ma è ben supportata. Come linguaggio .NET, è eminentemente compatibile con il predominante C # nel tuo (ipotetico) posto di lavoro. Microsoft intende mantenerlo per un po 'di tempo e ci sono risorse là fuori per l'apprendimento e il mantenimento dei sistemi scritti in esso. In quanto tale, sarai sempre in grado di trovare sviluppatori F #. Inoltre, lo status quo (corrente) del linguaggio di programmazione assicura che gli sviluppatori di F # non siano solo ben equipaggiati per gestire F #, ma probabilmente anche buoni sviluppatori in generale. Lo stesso vale per Haskell, o lingue Lisp che le persone sanno quando sanno davvero cosa stanno facendo.

I motivi principali per non interrompere l'uniformità e la manutenibilità. Se si tratta semplicemente di una funzione, non sarei incline a lasciare che il programmatore si interrompa dallo standard attuale (a meno che tutto non si stia muovendo su quello standard) da allora in poi avresti essenzialmente due codebase tra cui passare. Se si tratta di un modulo autonomo che occasionalmente interagisce con la base di codice esistente, sarei propenso a utilizzare lo strumento migliore per il lavoro (tenendo conto della manutenibilità).

Ma dipende anche da aspetti politici / sociali. Non vuoi isolare politicamente il programmatore facendo sembrare che possa fare tutto ciò che gli piace; ma anche tu vuoi lasciarlo essere creativo e avere input nel processo di ingegneria. Sei il capo, quindi dovrai determinare quanto è grande un accordo per la tua situazione.

Questa domanda è facile da rispondere. È un grande no-no. Il motivo è il seguente:

1. Rispondere a YES consentirà ai programmatori di utilizzare nuove funzionalità con il risultato finale di un programmatore felice. Tutti gli altri programmatori avranno bisogno di imparare qualche strano ambiente. Ma causa una grande quantità di wrapping tra lingue e strumenti, che è solo una perdita di tempo. Due ambienti avranno difficoltà a comunicare. È come se il tuo codebase fosse diviso in due parti separate.
2. Rispondere NO manterrà lo status quo. Un programmatore sarà infelice, ma il sistema che stai sviluppando avrà meno limitazioni e restrizioni.

È solo una valutazione dei rischi. Ci sono altri ingegneri dello staff che conoscono f #? È facile trovare programmatori f # relativamente a c #? Hanno bisogno di una paga più alta? Qual è il vantaggio di scrivere in f # rispetto a c #? Tempo di commercializzazione più rapido? Più facile da mantenere o da capire? Più affidabile? Personalmente, a meno che non conosca f # E ci siano almeno 2-3 ingegneri f # nello staff, penso che sia un po 'rischioso.