Ho appena finito di unire sette script in uno, ma mi ha fatto pensare che in realtà non ho una logica formale per interrompere gli script nelle pagine, o perché li unirei.
Suggerimenti?
Sebbene questo sia davvero il principio dell'OOD, ritengo che il principio di singola responsabilità possa fornire una prova Qui.
Uno script dovrebbe fare bene una cosa e avere una ragione per cui cambierebbe.
Non riesco a pensare perché sette script si fonderebbero in uno solo, anche se posso immaginare di spezzare uno script enorme in parti più logiche, che hanno un livello coerente di astrazione.
Bene ... se stai mantenendo file che consistono in migliaia di righe di illeggibile spaghetti codice , reingegnerizza le cose in modo che siano suddivise in componenti e file logici più piccoli e organizzati di solito in ordine .
Al contrario, se hai frammenti dappertutto fino al punto in cui un nuovo arrivato che sta esplorando la sorgente del codice ha assolutamente no idea di dove cercare qualcosa, potrebbe essere il momento di riorganizzare le cose in un modo meno oscuro e possibilmente unire alcuni file.
Oltre a usare la tua impressione, suggerirei questa variazione del test della mamma.
Il test della mamma, nel caso tu non sia familiare, è un test di usabilità semplice ed estremamente pratico, che consiste nel far sì che tua madre usi la tua app per 5-15 minuti con poche o nessuna spiegazione. Se non riesce a completare una manciata di compiti predefiniti ed essenziali, dovresti tornare direttamente al tavolo da disegno.
Nella sua iterazione del coder, consiste nel fare in modo che un amico programmatore esegua la scansione del codice sorgente per 5-15 minuti con poche o nessuna spiegazione su come funziona, e che gli dia la sua migliore ipotesi su come funziona il codice base (anche un idea vaga va bene). Se dopo un minuto è nauseato, dopo 15 anni non riesce a capirlo, o se arriva a qualcosa di orribilmente sbagliato, dovresti prendere seriamente in considerazione la possibilità di riorganizzare il codice e aggiungere una quantità ragionevole di commenti nelle intestazioni dei tuoi file.
Separare le cose in diversi file potrebbe essere una buona idea dal punto di vista del controllo della sorgente. Più facile da gestire e tenere traccia delle modifiche se tutti non stanno lavorando sullo stesso file.
Cerca di spiegarlo a una persona non tecnica. Se non ne hai uno a portata di mano, un cane o un gatto o un ritaglio di cartone faranno altrettanto bene. Se riesci a spiegare che cosa fa un pezzo di codice, senza entrare in una frase run-on, è probabile che sia una buona unità stessa. Se la spiegazione è troppo tecnica e richiede una conoscenza dettagliata di un altro script, probabilmente deve essere unita. Se la spiegazione usa "e" molto, probabilmente ha bisogno di essere suddivisa.
La ragione logica per cui ho tenuto a distanza questi sette script era che avresti potuto passare quel tempo all'aria aperta. Aspettare! Non è troppo tardi per farlo comunque!
Come sette script individuali, il singolo scopo di ogni script diventa palesemente ovvio. Con un po 'di fortuna, ognuno di questi script è ora riutilizzabile ovunque si presenti la necessità di questo singolo scopo. Collegalo ogni volta che ne hai bisogno e vai in kayak con il tempo in più che hai.
D'altra parte, lo scopo del singolo script è sfocato perché ora svolge sette attività. Immagina se la prossima volta unisci 25 script o 100 script in un Mecha-Streisand di uno script? Ricorderai che il singolo scopo che richiedi ora risiede da qualche parte in quell'enorme sceneggiatura? Ovviamente no. Ti ritroverai a scrivere di nuovo quella funzionalità in un'altra sceneggiatura e perderai la possibilità di andare, oh non lo so ... diciamo speleologia. = P
Nel complesso, 1 classe per file è un'idea ragionevole, significa che se devi soffiarlo via per una migliore idea che avevi, puoi solo estrarre un file, se è mescolato con altro codice, è probabile che potresti perdere qualcosa.
La mia regola empirica è se è un trucco veloce per fare un breve lavoro sporco, andare con 1 grosso file di doom, se c'è anche la più remota possibilità che tu possa tornare ad esso, dividerlo, quindi puoi dimenticare tutto, ma poi trovare tutto più tardi.
Raccomando vivamente questo libro sul refactoring . Parla del tuo caso specifico e di molti altri "schemi" molto comuni di codice che devono essere modificati.
In generale si consiglia, e ho sempre seguito la stessa filosofia, che dovresti rompere metodi / classi / file in molti file se questo aumenta la chiarezza, la leggibilità e la manutenibilità del tuo codice. E dovresti combinare singoli metodi / classi / file in uno solo se questo aumenta la chiarezza, la leggibilità e la manutenibilità del tuo codice.
Leggi altre domande sui tag version-control