Utilizzo di funzioni per codice mai ripetuto [duplicato]

1

Quali sono le migliori pratiche per utilizzare le funzioni per suddividere grandi blocchi di codice in blocchi discreti di logica quando tali funzioni verranno utilizzate solo una volta nel corso della durata di una funzione?

L'esempio canonico per lo sviluppo web è l'inizializzazione di una home page. Quando la pagina viene caricata, puoi fare qualcosa come controllare alcune credenziali e autenticazione, effettuare una chiamata API per ottenere alcuni dati e analizzare tali dati. Naturalmente, tutto ciò potrebbe essere scritto in un formato procedurale all'interno di una grande funzione chiamata initialize (). Nessuna logica verrà riutilizzata in nessun'altra parte all'interno del programma.

Quando mi trovo di fronte a questi scenari, il mio istinto iniziale è quello di dividere ogni parte di logica in una funzione discreta e semplicemente chiamare le funzioni da una funzione initialize (), con alcune righe di codice all'interno di initialize () che eseguono alcuni ripulire e abbattere i doveri. Quindi avrei qualcosa di simile a una funzione authenticate (), get_data () e parse_data (), così come forse alcune funzioni di supporto per le funzioni principali.

Secondo me, questo rende il codice più facile da capire da un livello elevato, rende i test unitari più significativi e aiuta a organizzare il tuo modo di pensare mentre scrivi il tuo codice.

Tuttavia, di recente mi sono scontrato con un ragazzo che essenzialmente pensa al contrario. Ritiene che troppe funzioni portino a "fastidiosi salti mortali", che le funzioni non dovrebbero mai essere utilizzate se il codice non verrà riutilizzato e che l'uso eccessivo di funzioni / classi / moduli / qualsiasi tipo di modularità equivale a ingegneria. Sono stato scoraggiato dalla sua argomentazione e ho sentito che questo porta al merdoso PHP procedurale che spesso rende lo sviluppo del web un incubo, ma forse c'è una certa validità in ciò che sta dicendo?

    
posta Lee Hampton 13.10.2013 - 20:31
fonte

2 risposte

6

Sommario esecutivo: è un idiota. Non c'è validità per quello che sta dicendo.

Il codice viene SEMPRE modificato alla fine, è SEMPRE "mantenuto" alla fine, è SEMPRE riutilizzato alla fine.

È sempre testato e ritestato.

Desiderate sempre progettare il vostro codice per verificabilità e riusabilità, perché, prima o poi, qualcuno dovrà testarlo e riutilizzarlo, anche dopo le vostre obiezioni più rumorose.

Sì, puoi fare un argomento di over-engineering. Il problema è che nessuno dei due ingegneri sarà mai d'accordo su ciò che costituisce un eccesso di ingegnerizzazione, e la sovraingegnerizzazione di qualcosa in genere dà risultati migliori di quanto non lo sottovaluti.

    
risposta data 13.10.2013 - 20:47
fonte
1

È meglio decomporsi in funzioni più piccole. Se queste funzioni hanno un nome chiaro, renderà il codice molto più leggibile e renderà il debug molto più semplice. Pensa a come sarebbe la traccia dello stack usando questo approccio più modulare rispetto all'approccio all in one. Il fatto che queste funzioni vengano chiamate in un solo posto non riduce nessuno di questi vantaggi.

Ogni funzione dovrebbe fare una cosa e fare bene quella cosa. Quella cosa può includere la combinazione dei risultati di alcune delle funzioni in un'interfaccia semplice per il consumatore della funzionalità. In definitiva, questo approccio porterà a funzioni più compatte che renderanno il tuo codice molto più facile da capire. Molto peggio che dover passare da una definizione di funzione a un'altra (che il tuo IDE dovrebbe facilitare) è dover scorrere lo schermo dopo lo schermo del codice all'interno di un metodo e cercare di tenere traccia di cosa esattamente sta succedendo nella tua testa. p>

Bob Martin ha un ottimo post al riguardo con una dettagliata esempio.

    
risposta data 13.10.2013 - 20:53
fonte

Leggi altre domande sui tag