¿Cómo se determina si reescribir o no un código mal diseñado? [duplicar]

12

Estoy en un equipo pequeño que ha recibido un juego Java en 2D a medio terminar y mal escrito. Nuestro objetivo es hacer todo lo posible para mejorarlo en aproximadamente 11 semanas. Estoy bastante seguro de que el código no se puede mantener y tengo que decidir si debo lanzar la idea de una reescritura (casi de todas formas).

Por ejemplo, la clase Main, que es un applet, tiene la mayor parte de la lógica del juego simplemente introducida en ella. Los eventos de teclado y mouse se manejan con grandes bloques si / else, ninguno de ellos está comentado (los únicos comentarios son las secciones de código que se han comentado), y todo el código de dibujo y animación está en una gran parte. Las imágenes se cargan en una clase separada que solo pasa por cada archivo, cada una en una línea separada, y lee la imagen en una variable de imagen estática. Todo esto parece un mal diseño.

Tenemos hasta el final del semestre, aproximadamente 11 semanas, para hacer que el juego sea mejor de lo que es ahora. Es jugable pero severamente roto en puntos. Actualmente me han asignado una pequeña función para implementar: un menú principal en el que se puede hacer clic en lugar de uno que se puede controlar solo con el teclado. Por un lado, sé que soy capaz de implementar esto, pero por el otro tengo miedo de intentar agregar nuevas características porque a) cuanto más cosas agregamos, más probabilidades hay de que el programa se rompa debido a las malas opciones de diseño. yb) cuanto más voy a agregar al lío que ya está allí.

Aproveché el fin de semana para intentar duplicar la funcionalidad básica del juego con un diseño diferente (para ver si se podía hacer lo suficientemente rápido). Soy capaz de cargar y almacenar en caché sprites, crear entidades del juego y moverlas, y hacer un seguimiento del estado del juego para determinar qué entrada del teclado manejar y qué dibujar en la pantalla. El siguiente fue un cargador de hojas de cálculo en mi lista (descubrí que la ilustración del juego no está en hojas de sprites, sino que cada una está en un archivo separado). Un amigo de confianza dijo que podría ser mejor tener que mantener el código anterior, pero mirarlo es demasiado frágil. Podríamos refactorizar a medida que avanzamos, pero creo que eso también sería difícil.

Nuestro grupo se reunirá este viernes. Planeé discutir la idea de una revisión y presentar en qué he estado trabajando, pero ahora no estoy tan seguro. Siento que es un juego de Java 2D bastante simple que, una vez que armamos una base sólida, sería mucho más fácil agregar funciones, pero tendríamos que rediseñar el código base con bastante rapidez, probablemente en dos o cuatro semanas o más. . Me gustaría pensar que podemos hacerlo tan rápido pero no estoy completamente seguro.

Supongo que podría reducir mi pregunta a esto: ¿cuál es la mejor manera de determinar cuándo mantener un código mal diseñado y cuándo pasar algo de tiempo comenzando casi completamente desde cero?

    
pregunta offbyone 02.02.2012 - 07:35

5 respuestas

27

Refactoriza el código fuente existente. Lo sé sucks pero si aprendí algo sobre desarrollo, es que no solo tiras un proyecto que funciona porque el código es terrible.

Tu juego está funcionando. Manténgalo así.

  • Los eventos del teclado se manejan de forma gigantesca si los bloques? Escurra eso en una clase y segregue la funcionalidad en métodos. Podrá reutilizar la mayoría del código que ya se ha escrito .

  • ¿No hay comentarios? Agréguelos a medida que refactorice áreas específicas de la base de código.

  • ¿El juego no está utilizando hojas de cálculo? ¿No tiene gerente? Concatene los sprites existentes en una hoja y escriba al administrador para que encaje en la solución de carga de sprite existente.

  • ¿Se están mezclando el dibujo y la animación con la lógica del juego? Nuevamente, comience a mover estos fragmentos a sus respectivas clases.

Tienes mi punto. No hay nada peor y más deprimente que tener que desenredar una base de código enredada, pero la victoria es mucho más dulce al final. En lugar de pasar 5 semanas reescribiendo lo que ya se hizo, tendrás 5 semanas adicionales para escupir, pulir y agregar nuevas funciones.

Siéntese con su equipo y planifique lo que aún debe lograrse con este proyecto en términos de características. Una vez que tenga una lista completa, puede comenzar a realizar refactorizaciones deliberadas que beneficiarán directamente el éxito de su proyecto.

    
respondido por el Jarrod Nettles 02.02.2012 - 08:00
7

La situación que está describiendo es la misma que encontrará en todo el sector en relación con el llamado legacy-code . Para tener una idea de por qué probablemente no deberías empezar desde cero, te sugiero que leas este buen artículo de Joel.

enlace

Además, sugiero obtener una copia del libro de Feathers "Trabajando efectivamente con el código heredado" , describe muchas prácticas útiles sobre cómo manejar su situación.

    
respondido por el Doc Brown 02.02.2012 - 08:03
4

No lo escribas desde cero. Inevitablemente, habrá una lógica que fallas en la reescritura, y el ejercicio de profundizar y ensuciar el código valdrá la pena. Encuentra herramientas de refactorización que puedan ayudarte. Sé que está en Java, pero, por ejemplo, Visual Studio tiene herramientas de refactorización que le permiten extraer funciones con mucha facilidad. Tal vez puedas probar Eclipse y sus herramientas, o encontrar un complemento.

Comience con la extracción de bloques grandes que parezcan funcionalmente relacionados. Puedes identificar la lógica que se puede separar en clases. Encuentre las dependencias y parametrícelas (por ejemplo, desglobalizar variables). En última instancia, intente establecer una mejor estructura alrededor del código existente primero.

Puede que no termines con un brillante ejemplo de perfección de OO, pero ese no es el objetivo. El objetivo es agregar capacidad de mantenimiento al proyecto para que pueda agregar funcionalidad sin quemar un fusible.

    
respondido por el Kevin Hsu 02.02.2012 - 07:48
1
  

¿Cuál es la mejor forma de determinar cuándo mantener un código mal diseñado y cuándo pasar algo de tiempo comenzando casi completamente desde cero?

Cuando un cambio más simple se convierta en una tarea colosal * , entonces es mejor comenzar a refactorizarlo. Pero nunca deseche su código anterior (léalo al respecto en 10 cosas de Joel que nunca debe hacer .

* Asumí que el código está probado y sin errores. Si introduces nuevos errores, entonces tu tarea no está terminada.

    
respondido por el BЈовић 02.02.2012 - 10:15
0

Le sugerimos que ejecute un detector de clones sobre el código. Esto le permitirá encontrar dónde se encuentra el código duplicado que se puede abstraer, y podrá realizar extracciones útiles (por ejemplo, manejo de eventos del mouse, etc.).

Nuestra herramienta CloneDR encontrará bloques de código que coincidan con los parámetros de módulo; Básicamente, propone subrutinas (OK, esto es Java, se llaman métodos) que muestran el código duplicado y cómo se puede parametrizar.

    
respondido por el Ira Baxter 02.02.2012 - 12:04

Lea otras preguntas en las etiquetas