Troppi file CS in un singolo progetto [duplicato]

Nella mia esperienza, l'argomento contro "troppi file di classe" è sempre perpetuato da persone che semplicemente non sono sufficientemente disciplinate per separare le responsabilità bene. La tua esperienza nella ricerca di file di codice di linea 4500 + è esattamente la stessa esperienza che ho con questi team. I file tenderanno a crescere, quindi è una buona pratica iniziarli comunque in piccolo.

Una contro-argomentazione comune che sento è che si tratta di un codice di "confusione per il debug" che viene trasmesso da una classe all'altra, ecc., ma in realtà non dovresti preoccuparti di tutti i dettagli di implementazione di tutte le classi coinvolto in un flusso, quindi non dovrebbe essere necessario passare attraverso tutti loro in primo luogo. Inoltre, se hai impostato correttamente i test di unità, non dovresti aver bisogno di esaminare il codice molto spesso.

Parlando di test unitari, avere molte classi separate rende il tuo codice molto più verificabile, e questa è una buona cosa. Sono disposto a scommettere che la copertura del test su questo progetto corrente è quasi inesistente, dal momento che i test unitari rivelerebbero immediatamente i problemi con l'architettura di questo codice base.

Sembra che tu sia nella sfortunata situazione di essere in un ambiente alquanto tossico in cui l'opinione popolare supera la ragione, e può essere frustrante essere l'unica voce ragionevole in un gruppo, ma non smettere di combattere il bene combattimento. Indicali alle risorse da professionisti, come Robert Martin o Martin Fowler. È probabile che la tua squadra sia così radicata nei loro modi e legata al loro ego che non si muoveranno, ma non smetteranno di spingerli nella giusta direzione.

Se per miracolo si dispone di una soluzione di test unitaria esistente per il tuo progetto, potresti provare l'introduzione passiva-aggressiva di unit-test-as-guard contro il codice errato che il tuo team potrebbe scrivere. Su una squadra tossica su cui ho lavorato, ho trovato utile il refactoring del codice in blocchi testabili e l'esecuzione di test unitari attorno ad esso, garantendo che i miei colleghi avrebbero affrontato il dolore se avessero mai provato a cambiare le cose in peggio. (Naturalmente, questo potrebbe solo portarli alla conclusione che "il test unitario è cattivo!" Quindi prova a tuo rischio.;))

È difficile dire se sei andato troppo lontano senza vedere esempi più concreti, ma tieni presente che in uno di Trattamenti di Bob Martin dell'SRP , afferma:

If [...] the application is not changing in ways that cause the two responsibilities to change at different times, then there is no need to separate them. Indeed, separating them would smell of Needless Complexity.

Ci sono naturalmente molte ragioni per creare classi separate oltre a seguire l'SRP, ad es. ridurre l'accoppiamento, aumentare la coesione, separare le preoccupazioni, ecc .; tuttavia è utile chiedersi se stai effettivamente realizzando dei vantaggi a causa di una determinata decisione di progettazione.