Luego hay una luz verde, y en un esfuerzo por limpiar las cosas, alguien escribe un GameManager. Probablemente para guardar un montón de GameStates, tal vez para almacenar algunos GameObjects, nada grande, de verdad. Un lindo y pequeño gerente.
Sabes, mientras leía esto, tenía pequeñas alarmas sonando en mi cabeza. Un objeto con el nombre "GameManager" nunca será lindo o pequeño. ¿Y alguien hizo esto para limpiar el código? ¿Cómo se veía antes? Bien, bromas aparte: el nombre de una clase debería ser una indicación clara de lo que hace la clase, y esto debería ser una cosa (también conocido como principio de responsabilidad única ).
Además, aún puede terminar con un objeto como GameManager, pero claramente, existe en un nivel muy alto, y debería ocuparse de tareas de alto nivel. ¿Mantener un catálogo de objetos del juego? Quizás. ¿Facilita la comunicación entre los objetos del juego? Seguro. Cálculo de colisiones entre objetos? ¡No! Esta es también la razón por la que el nombre Manager está mal visto: es demasiado amplio y permite muchos abusos bajo ese banner.
Una regla general rápida sobre el tamaño de las clases: si se encuentra con varios cientos de líneas de código por clase, algo comienza a salir mal. Sin ser demasiado celoso, algo más, digamos, 300 LOC es un olor a código para mí, y si vas a más de 1000, las campanas de advertencia deberían sonar. Al creer que de alguna manera que 1000 líneas de código es más fácil de entender que 4 clases bien estructuradas de 250 cada una, te estás engañando a ti mismo.
Cuando el tiempo se convierte en un problema, no hay forma de escribir una clase separada o dividir a este gerente gigante en subgerentes.
Creo que este es el caso solo porque el problema puede propagarse hasta el punto en que todo es un completo desastre. La práctica de refactorización es realmente lo que está buscando: necesita mejorar continuamente el diseño del código en pequeños incrementos .
¿Qué sugeriría para evitar que esto suceda?
El problema no es tecnológico, por lo que no debe buscar soluciones tecnológicas. El problema es este: hay una tendencia en su equipo a crear piezas de código monolíticas, y la creencia de que de alguna manera es beneficioso a mediano / largo plazo trabajar de esta manera. También parece que el equipo carece de un liderazgo arquitectónico fuerte, que dirigiría la arquitectura del juego (o al menos, esta persona está demasiado ocupada para realizar esta tarea). Básicamente, la única salida es hacer que los miembros del equipo reconozcan que este pensamiento es incorrecto. A nadie le favorece. La calidad del producto empeorará, y el equipo solo pasará aún más noches arreglando cosas.
La buena noticia es que los beneficios inmediatos y tangibles de escribir código limpio son tan grandes que casi todos los desarrolladores se dan cuenta de sus beneficios muy rápidamente. Convencer al equipo de trabajar de esta manera por un tiempo, los resultados harán el resto.
La parte difícil es que desarrollar una idea de lo que constituye un mal código (y un talento para encontrar rápidamente un mejor diseño) es una de las habilidades más difíciles de aprender en el desarrollo. Mi sugerencia gira en torno a la esperanza de que tengas a alguien lo suficientemente alto en el equipo que pueda hacer esto: es mucho más fácil convencer a la gente de esa manera.
Editar - Un poco más de información:
En general, no creo que tu problema se limite al desarrollo del juego. En esencia, es un problema de ingeniería de software, de ahí mis comentarios en esa dirección. Lo que puede ser diferente es la naturaleza de la industria de desarrollo de juegos, ya sea que esté más orientada a resultados y plazos que otros tipos de desarrollo, no estoy seguro.
Sin embargo, específicamente para el desarrollo de juegos, la respuesta aceptada a esta pregunta en StackOverflow con respecto a los consejos de "especialmente arquitectura de juegos" dice:
Siga los principios sólidos del diseño orientado a objetos ...
Esto es esencialmente exactamente lo que estoy diciendo. Cuando estoy bajo presión, también me encuentro escribiendo grandes piezas de código, pero me he metido en la cabeza que eso es una deuda técnica. Lo que suele funcionar bien para mí es pasar la primera mitad (o tres cuartos) del día produciendo una gran cantidad de código de calidad media, y luego tomar un descanso y pensarlo un momento; hacer un poco de diseño en mi cabeza, o en papel / pizarra, sobre cómo mejorar un poco el código. A menudo, noto código repetitivo, y puedo reducir las líneas de código totales al dividir las cosas, al tiempo que mejora la legibilidad. Esta vez invertido se amortiza tan rápido que llamarlo una "inversión" suena tonto; con frecuencia, recojo errores que podrían haber desperdiciado la mitad de mi día (una semana después) si hubiera permitido que continuara.
- Arregle las cosas el mismo día que las codifique.
- Se alegrará de haberlo hecho en cuestión de horas.
Llegar a creer realmente lo anterior es difícil; Logré hacerlo por mi propio trabajo solo porque he experimentado, una y otra vez, los efectos. Aun así, todavía es difícil para mí justificar la reparación del código cuando podría estar produciendo más ... Así que definitivamente entiendo de dónde vienes. Desafortunadamente, este consejo es quizás demasiado genérico y no es fácil de hacer. ¡Creo firmemente en ello, sin embargo! :)
Para responder a su ejemplo específico:
El código limpio del tío Bob hace un trabajo increíble al resumir cómo es el código de buena calidad. Estoy de acuerdo con casi todos sus contenidos. Entonces, cuando pienso en su ejemplo de una clase de gerente de 30 000 LOC, realmente no puedo estar de acuerdo con la parte de "buena razón". No quiero parecer ofensivo, pero pensar de esa manera conducirá al problema. No hay una buena razón para tener tanto código en un solo archivo: ¡son casi 1000 páginas de texto! Cualquier beneficio de la localidad (velocidad de ejecución o "simplicidad" del diseño) será anulado de inmediato por los desarrolladores que están completamente empantanados tratando de navegar esa monstruosidad, y eso es incluso antes de discutir la fusión, etc.
Si no está convencido, mi mejor sugerencia sería tomar una copia del libro anterior y echarle un vistazo. La aplicación de ese tipo de pensamiento lleva a las personas a crear voluntariamente un código limpio y autoexplicativo, que está bien estructurado.