¿Qué preguntas debo hacer al tratar de determinar si un sistema debe ser reconstruido?

Question

He estado involucrado en la evaluación de si varios de nuestros sistemas necesitan ser reescritos desde cero o si deberían ser reescritos parcialmente, o si simplemente deberían continuar como están con parches en la parte superior.

Para evaluar mejor la situación, me preguntaba qué preguntas debería hacerme a mí mismo y a los demás para ayudar a determinar la acción adecuada a tomar.

Answer 1

En general, he encontrado que reescribir el código tiende a ser un problema (es costoso, consume mucho tiempo e involucra una fase de descubrimiento que hace que el primer sistema se vea mejor).

Dicho esto, aquí hay algunas preguntas que debe hacer: basta

1. Would núcleo refactorización? Sabrá al evaluar el sistema si los problemas centrales son más profundos que el código o no. Si los problemas están en la base del código (en lugar de la tecnología en sí), prefiero refactorizar.

2. ¿En qué medida se puede comprobar el sistema actual?La capacidad de prueba contribuye en gran medida a prolongar la vida útil de cualquier módulo del sistema porque, en general, el código comprobable se presta más fácilmente a la extensión y el mantenimiento. Esto se relaciona con el # 1 también.

3. Por último, el valor proporcionado por una reescritura justifica el esfuerzo. Esta es una pregunta comercial, sin duda, pero que el desarrollador puede y debe ayudar a hacer.

En la mayoría de los casos que he encontrado, la respuesta fue no.

Answer 2

Te recomiendo que leas Things You Should Never Do, Part I. Él hace un caso fuerte para no volver a desarrollar.

dinero cita:

Es importante recordar que cuando se empieza desde cero no hay absolutamente ninguna razón para creer que se va a hacer un mejor trabajo de lo que hizo la primera vez. En primer lugar, es probable que ni siquiera tenga el mismo equipo de programación que trabajó en la versión uno, por lo que en realidad no tiene "más experiencia". Simplemente volverá a cometer la mayoría de los viejos errores e introducirá algunos problemas nuevos que no estaban en la versión original.

Quizás deba preguntarse si conoce el sistema lo suficientemente bien como para solucionar los problemas sin volver a escribirlo. Si no lo hace, podría ser seguro decir que no conoce el sistema lo suficientemente bien como para volver a desarrollarlo desde cero.

Answer 3

en el siguiente orden:

• es lo que hace el trabajo correctamente?
• ¿es rápido?
• ¿es fácil de mantener?
• ¿es fácil de extender?

Answer 4

Por último, desea lograr algo siempre que reescriba un sistema desde el principio. Deberías preguntarte qué es lo que quieres lograr? ¿Quieres:

• reducir el riesgo de un sistema construido con viejas tecnologías
• Reducir los costes: demasiado caros para mantener
• ?

Podría hacer un análisis de punto de equilibrio para ver cuándo su nuevo sistema comienza a pagar. En mi opinión, debería poder reducir la reescritura del sistema a los costos y poder ver que uno nuevo cuesta menos que el anterior.

Answer 5

1. ¿Cuánto tiempo va a poder entregar? ¿Cuánto tiempo? ¿Con qué factor ha subestimado los proyectos anteriores? ¿Cuánto tiempo puede permitirse en el peor de los casos?

2. ¿Cuánta mano de obra actualmente va en manteniendo el sistema (s) existente (s)? ¿Tiene esta mano de obra disponible además para las personas que están desarrollando el nuevo sistema?

3. ¿Cómo puede asegurarse de no volver a crear el mismo sistema con los mismos problemas? Evitar las fallas de arquitectura obvias generalmente no es suficiente.

4. ¿Podrá competir/sobrevivir si no tiene recursos para mejorar el sistema actual?

---

Incluso si "Refactor y reparación" significa, en el largo plazo, en sustitución de la mayor parte del sistema existente, que significa poner todos los Recursos en un solo sistema, en lugar de dos.

Answer 6

Sugiero que necesite un contexto para la discusión, y el mejor con el que estoy familiarizado se encuentra en el libro "Refactorización" de Martin Fowler. Para mí, la pregunta realmente es "¿Es esta aplicación refactorizable?"

La primera directriz específica sería "¿Está escrita usando buenos principios de diseño OO?" Si no es así, generalmente debe ponerlo en soporte vital y/o comenzar de nuevo. Si es así, entonces el libro proporcionará mucha ayuda; y en mi experiencia hay buenas razones para la esperanza.