Depois, há um sinal verde e, em um esforço para limpar as coisas, alguém escreve um GameManager. Provavelmente para armazenar um monte de GameStates, talvez para armazenar alguns GameObjects, nada grande, na verdade. Um gerente bonitinho e pequeno.
Sabe, enquanto eu lia isso, eu tinha pequenos alarmes na minha cabeça. Um objeto com o nome "GameManager" nunca será bonito ou pequeno. E alguém fez isso para limpar o código? Como era antes? OK, piadas à parte: o nome de uma classe deve ser uma indicação clara do que a classe faz, e isso deve ser uma coisa (aka: princípio de responsabilidade única ).
Além disso, você ainda pode acabar com um objeto como o GameManager, mas claramente ele existe em um nível muito alto e deve se preocupar com tarefas de alto nível. Mantendo um catálogo de objetos do jogo? Possivelmente. Facilitar a comunicação entre objetos do jogo? Certo. Calculando colisões entre objetos? Não! É também por isso que o nome Manager é desaprovado - é muito amplo e permite muitos abusos sob esse banner.
Uma regra prática rápida no tamanho das classes: se você estiver executando várias centenas de linhas de código por classe, algo está começando a dar errado. Sem ser excessivamente zeloso, qualquer coisa acima de, digamos, 300 LOC é um cheiro de código para mim, e se você estiver ultrapassando as 1000, os sinos de aviso devem disparar. Acreditando que, de alguma forma, que 1000 linhas de código são mais simples de entender do que 4 classes bem estruturadas de 250 cada, você está se iludindo.
Quando o tempo se torna um problema, não há como escrever uma classe separada ou dividir esse gerente gigante em sub-administradores.
Eu acho que é esse o caso apenas porque o problema pode se propagar até o ponto em que tudo está uma bagunça completa. A prática de refatoração é realmente o que você está procurando - você precisa melhorar continuamente o design do código em pequenos incrementos .
O que você sugeriria para impedir que isso acontecesse?
O problema não é tecnológico; portanto, você não deve procurar por soluções tecnológicas. O problema é o seguinte: há uma tendência em sua equipe de criar trechos de código monolíticos e a crença de que, de alguma forma, é benéfico a médio / longo prazo trabalhar dessa maneira. Parece também que a equipe não possui uma forte liderança arquitetônica, que guiaria a arquitetura do jogo (ou pelo menos, essa pessoa está ocupada demais para executar esta tarefa). Basicamente, a única saída é fazer com que os membros da equipe reconheçam que esse pensamento está errado. Ninguém favorece. A qualidade do produto piorará e a equipe passará apenas mais noites corrigindo as coisas.
A boa notícia é que os benefícios imediatos e tangíveis da escrita de código limpo são tão grandes que quase todos os desenvolvedores percebem seus benefícios rapidamente. Convença a equipe a trabalhar dessa maneira por um tempo, os resultados farão o resto.
A parte difícil é que desenvolver uma sensação do que constitui um código ruim (e um talento para criar rapidamente um design melhor) é uma das habilidades mais difíceis de aprender no desenvolvimento. Minha sugestão se baseia na esperança de que você tenha alguém sênior na equipe que possa fazer isso - é muito mais fácil convencer as pessoas dessa maneira.
Editar - Um pouco mais de informação:
Em geral, não acho que seu problema esteja limitado ao desenvolvimento de jogos. Na sua essência, é um problema de engenharia de software, portanto, meus comentários nessa direção. O que pode ser diferente é a natureza da indústria de desenvolvimento de jogos, se seus resultados são mais orientados a prazos do que outros tipos de desenvolvimento, não tenho certeza.
Especificamente para o desenvolvimento de jogos, a resposta aceita para esta pergunta no StackOverflow sobre dicas "especialmente de arquitetura de jogos", diz:
Siga os princípios sólidos de design orientado a objetos ....
Isto é essencialmente exatamente o que estou dizendo. Quando estou sob pressão, também me pego escrevendo grandes pedaços de código, mas ensinei que isso é dívida técnica. O que tende a funcionar bem para mim é passar a primeira metade (ou três quartos) do dia produzindo uma grande quantidade de código de qualidade média, e depois relaxar e pensar um pouco; faça um pouco de design na minha cabeça, ou no papel / quadro branco, sobre como melhorar um pouco o código. Freqüentemente, percebo código repetitivo e sou capaz de reduzir o total de linhas de código, interrompendo tudo, melhorando a legibilidade. Desta vez, o investimento se paga tão rapidamente, que chamá-lo de "investimento" parece bobagem - muitas vezes, apanhamos bugs que poderiam ter desperdiçado metade do meu dia (uma semana depois), caso eu permitisse continuar.
- Corrija as coisas no mesmo dia em que você as codifica.
- Você ficará feliz em fazer isso em poucas horas.
Vir a acreditar realmente no que foi dito acima é difícil; Consegui fazer isso para o meu próprio trabalho apenas porque experimentei repetidamente os efeitos. Mesmo assim, ainda é difícil para mim justificar a correção do código quando eu poderia estar produzindo mais ... Então, eu definitivamente entendo de onde você é. Infelizmente, esse conselho é talvez genérico demais e não é fácil de executar. Eu acredito fortemente nisso, no entanto! :)
Para responder seu exemplo específico:
O Código Limpo do tio Bob faz um trabalho incrível ao resumir como é um código de boa qualidade. Por acaso concordo com quase todo o seu conteúdo. Então, quando penso no seu exemplo de uma classe de gerente de 30.000 LOC, não posso realmente concordar com a parte "boa razão". Não quero parecer ofensivo, mas pensar dessa maneira levará ao problema. Não há uma boa razão para ter tanto código em um único arquivo - são quase 1000 páginas de texto! Qualquer benefício da localidade (velocidade de execução ou "simplicidade" do projeto) será imediatamente anulado pelos desenvolvedores que estão completamente atolados, tentando navegar nessa monstruosidade, e isso é antes mesmo de discutirmos a fusão etc.
Se você não estiver convencido, minha melhor sugestão seria pegar uma cópia do livro acima e dar uma olhada nele. A aplicação desse tipo de pensamento leva as pessoas a criar voluntariamente um código limpo e auto-explicativo, que é bem estruturado.