Dovremmo refactoring la nostra base di codice esistente per utilizzare la programmazione funzionale, in particolare i flussi? [chiuso]

Question

Dovremmo refactoring la nostra base di codice esistente per utilizzare la programmazione funzionale, in particolare i flussi? [chiuso]

#1 da (8 voti)
#2 da (4 voti)

2

Abbiamo un grande progetto scritto in PHP. Esegue quasi esclusivamente operazioni imperative, come nell'esempio 1. Dovremmo refactoring il nostro codice esistente per utilizzare le operazioni funzionali? Pensi che il codice nell'esempio 2 sia più semplice da mantenere?

Esempio 1 - imperativo

 $cookieString = '';
 foreach($cookieArray as $cookieName => $cookieValue) {
   if($cookieString != '') {
     $cookieString .= '; ';
   }
   $cookieString .= $cookieName.'='.$cookieValue;
 }
 return $cookieString;

Esempio 2 - funzionale

 return KeyedStream::of($cookieArray)
                 ->mapEntriesToStream(function($cookieName, $cookieValue) {
                   return $cookieName.'='.$cookieValue;
                 })
                 ->joinToString('; ');
}

code-quality coding-style coding-standards php functional-programming

posta pako 28.12.2014 - 19:27

fonte

2 risposte

Leggi altre domande sui tag code-quality coding-style coding-standards php functional-programming

Il miglior approccio per un negozio online che modifica il prezzo del suo prodotto nel tempo? [Progettare la tabella DB] È mai giustificato scrivere codice senza test quando si fa TDD?

score 8 · Answer 1

Chiediti onestamente perché vuoi refactoring. Questo è veramente importante poi pensa a quello che stai facendo nella tua azienda - sei assunto per scrivere un bel codice, o per creare un buon prodotto.

Penso che troppi sviluppatori siano così presi dalle minuzie del codice base da dimenticare ciò che dovrebbero fare, il che sta facendo qualcosa di utile. È come un muratore che si preoccupa se dovrebbe cambiare la miscela di argilla nei mattoni quando costruisce un muro! (no brickie lo fa - costruiscono il muro, poi vanno a costruire più muri.I muri sono importanti, i mattoni solo in modo che facciano capitare i muri)

Quindi domanda quale sia il tuo vero motivo qui. Il tuo codice è così difficile da capire che cambiare le cose è troppo costoso? Il tuo codice è così schifoso da non poterlo capire per cambiare qualcosa? Se la risposta è no, spendi i tuoi sforzi facendo qualcosa di utile.

score 4 · Answer 2

Devo ammettere che amo il codice di refactoring, ma ho scelto saggiamente il refactoring e perché.

L'utente del tuo codice beneficerà chiaramente del codice riscritto? L'utente richiederà questo nuovo codice di stile funzionale, o è solo una cosa sviluppatore, per provare a programmare con uno stile diverso? Se non c'è alcun beneficio per l'utente, ad eccezione del fatto che il codice ora sembra "bello", chi ne avrà bisogno? Stai sostituendo una moda con un'altra. E questo è YAGNI - Non ne hai bisogno.

Se la base del codice è grande, significa anche che questo codice è già stato sviluppato negli anni, il che significa che la base del codice corrente è già piena di stili di codice diversi. E se stiamo parlando di una grande base di codice, mi sembra che potresti avere anche un sacco di codice PHP legacy. Dovresti essere consapevole del fatto che molto probabilmente il refactoring / riscrittura del codice introdurrà nuovi errori. Ogni utente odia nuovi errori quando il codice precedente funzionava.

Sei pronto a combattere l'introduzione di nuovi errori? Voglio dire, hai già dei test unitari per rilevare errori o regressioni? Se non hai test unitari, come ne sarai sicuro, che hai capito il codice che hai trasformato in un'espressione di stile funzionale? Scrivi test unitari! Se questo codice non è verificabile, rendilo testabile. Finché non ci sono test unitari per i frammenti che vuoi refactoring - non refactoring.

Il refactoring è molto meno soggetto a errori se il tuo IDE supporta il fattore. Anche allora i fattori non sono banali e spesso si tradurranno in nuovi comportamenti invisibili.

Rifacimento del codice Java: eccellente supporto IDE (Eclipse, IntelliJ, Netbeans, ...)): basta eseguire il commit spesso (ogni secondo o due minuti), mentre si esegue il refactoring. La maggior parte dei refactoring sta premendo alcune combinazioni di tasti.
Rifacimento del codice PHP: ho avuto un cattivo supporto IDE: questo significa un sacco di passaggi manuali, in cui ognuno potrebbe introdurre nuovi errori.

Apporto cambiamenti alle regole boy-scout, ogni volta che tocco un codice vicino, a volte estraggo un metodo, rinomina un metodo, introduco un parametro invece di usare un campo nella classe, cambio firma del metodo, rinomina un campo,. .. Ma non cerco mai di aggiustare qualcosa che mi viene in mente, cosa sembra solo sbagliato. Se è sbagliato, perché nessuno si è lamentato, e quando nessuno si è lamentato, cosa posso aver perso? Scrivi un test / test per codice errato.

Faccio refactoring, ad es. dalla GUI-codice della classe di Dio ai modelli, se e solo se, devo correggere un errore in questa classe e / o aggiungere una nuova funzionalità per quella classe. Questo di solito è per il codice che ho ereditato da altri sviluppatori.

Potresti forse usare il tempo che potresti spendere per il refactoring di questo codice meglio utilizzato per qualcosa di più vantaggioso per l'utente? Alcuni di questi benefici sono anche test unitari e integrazione continua.

Se ti piace questo stile funzionale usalo per il nuovo codice. Ma trovo l'esempio 2 non più leggibile del codice fornito nell'esempio 1.

hth