Poi c'è una luce verde e, nel tentativo di ripulire le cose, qualcuno scrive un GameManager. Probabilmente per contenere un sacco di GameState, forse per memorizzare alcuni GameObject, niente di grosso, davvero. Un manager carino, piccolo.
Sai, mentre stavo leggendo questo, ho avuto dei piccoli allarmi che mi suonavano in testa. Un oggetto con il nome "GameManager" non sarà mai carino o piccolo. E qualcuno ha fatto questo per ripulire il codice? Che aspetto aveva prima? OK, scherzi a parte: il nome di una classe dovrebbe essere una chiara indicazione di ciò che fa la classe, e questa dovrebbe essere una cosa (alias: principio di responsabilità singola ).
Inoltre, potresti ancora finire con un oggetto come GameManager, ma chiaramente esiste a un livello molto alto e dovrebbe occuparsi di compiti di alto livello. Mantenere un catalogo di oggetti di gioco? Forse. Facilitare la comunicazione tra oggetti di gioco? Sicuro. Calcolo delle collisioni tra oggetti? No! Questo è anche il motivo per cui il nome Manager è disapprovato: è troppo ampio e consente molti abusi sotto quel banner.
Una rapida regola empirica sulle dimensioni delle classi: se si verificano diverse centinaia di righe di codice per classe, qualcosa inizia a non funzionare. Senza essere troppo zelante, niente di più, diciamo, 300 LOC è un odore di codice per me, e se stai andando oltre 1000, le campane di avviso dovrebbero suonare. Credendo che in qualche modo 1000 righe di codice siano più semplici da comprendere rispetto a 4 classi ben strutturate da 250 ciascuna, ti stai illudendo.
Quando il tempo diventa un problema, non c'è modo di scrivere una classe separata o di dividere questo manager gigante in sub-gestori.
Penso che questo sia il caso solo perché il problema è autorizzato a propagarsi al punto in cui tutto è un casino completo. La pratica del refactoring è davvero ciò che stai cercando: è necessario migliorare continuamente il design del codice con piccoli incrementi .
Cosa suggeriresti per evitare che ciò accada?
Il problema non è tecnologico, quindi non dovresti cercare correzioni tecnologiche. Il problema è questo: c'è una tendenza nella tua squadra a creare pezzi monolitici di codice e la convinzione che sia in qualche modo utile a medio / lungo termine lavorare in questo modo. Sembra anche che al team manchi un forte vantaggio architettonico, che guiderebbe l'architettura del gioco (o almeno, questa persona è troppo impegnata per svolgere questo compito). Fondamentalmente, l'unica via d'uscita è far riconoscere ai membri del team che questo pensiero è sbagliato. Nessuno favorisce. La qualità del prodotto peggiorerà e il team passerà solo più notti a sistemare le cose.
La buona notizia è che i benefici immediati e tangibili della scrittura di codice pulito sono così grandi, che quasi tutti gli sviluppatori realizzano i loro benefici molto rapidamente. Convincere il team a lavorare in questo modo per un po ', i risultati faranno il resto.
La parte difficile è che sviluppare una sensazione per ciò che costituisce un codice errato (e un talento per trovare rapidamente un design migliore) è una delle abilità più difficili da imparare nello sviluppo. Il mio suggerimento si basa sulla speranza di avere qualcuno abbastanza anziano nella squadra che possa farlo - è molto più facile convincere le persone in quel modo.
Modifica - Altre informazioni:
In generale, non penso che il tuo problema sia limitato allo sviluppo del gioco. Alla base, è un problema di ingegneria del software, quindi i miei commenti in quella direzione. Ciò che potrebbe essere diverso è la natura del settore dello sviluppo del gioco, sia che si tratti di maggiori risultati e di scadenze rispetto ad altri tipi di sviluppo, non ne sono sicuro.
In particolare per lo sviluppo del gioco, tuttavia, la risposta accettata a questa domanda su StackOverflow in merito ai suggerimenti "soprattutto sull'architettura di gioco", afferma:
Segui i solidi principi del design orientato agli oggetti ....
Questo è essenzialmente esattamente quello che sto dicendo. Quando sono sotto pressione, mi ritrovo anche a scrivere grandi quantità di codice, ma mi sono messo in testa che si tratta di debito tecnico. Ciò che tende a funzionare bene per me, è trascorrere la prima metà (o tre quarti) della giornata producendo una grande quantità di codice di media qualità, e poi sedersi e pensarci un po '; faccio un po 'di progettazione nella mia testa, o su carta / lavagna, su come migliorare un po' il codice. Spesso noto codice ripetitivo e sono in grado di ridurre effettivamente le righe totali di codice suddividendo le cose, migliorando nel contempo la leggibilità. Questa volta investito si ripaga così in fretta, che chiamarlo "investimento" suona sciocco - abbastanza spesso raccoglierò bug che avrebbero potuto perdere metà della mia giornata (una settimana dopo), se gli avessi permesso di continuare.
- Risolvi le cose nello stesso giorno in cui li codifichi.
- Sarai felice di averlo fatto entro poche ore.
Arrivare a credere veramente quanto sopra è difficile; Sono riuscito a farlo per il mio lavoro solo perché ho sperimentato, ancora e ancora, gli effetti. Anche così, è ancora difficile per me giustificare la correzione del codice quando potrei sfornare di più ... Quindi capisco sicuramente da dove vieni. Sfortunatamente, questo consiglio è forse troppo generico e non facile da fare. Ci credo fermamente, comunque! :)
Per rispondere al tuo esempio specifico:
Il codice pulito di zio Bob fa un ottimo lavoro nel riassumere come sia un codice di buona qualità. Mi capita di essere d'accordo con quasi tutti i suoi contenuti. Quindi, quando penso al tuo esempio di una classe manager LOC di 30.000, non posso davvero essere d'accordo con la parte "buona ragione". Non voglio sembrare offensivo, ma pensare in questo modo porterà al problema. Non vi è alcuna buona ragione per avere così tanto codice in un singolo file: sono quasi 1000 pagine di testo! Qualsiasi vantaggio derivante dalla località (velocità di esecuzione o "semplicità" di progettazione) verrà immediatamente annullato dal fatto che gli sviluppatori siano completamente impantanati nel tentativo di attraversare quella mostruosità, e questo è ancora prima di discutere della fusione, ecc.
Se non sei convinto, il mio miglior suggerimento sarebbe quello di prendere una copia del libro sopra e dare un'occhiata attraverso di esso. Applicare quel tipo di pensiero a condurre le persone a creare volontariamente un codice pulito e autoesplicativo, che è ben strutturato.