¿Cuándo debería eliminarse la complejidad?

De alguna manera, creo que esto es en gran medida una decisión de negocios y no necesariamente basada en el código en sí. Algunas cosas a considerar:

• ¿Te pagan por hacer los cambios?
• ¿Funciona actualmente el código como se esperaba?
• ¿Hay algún problema de seguridad o rendimiento con el código como está?
• ¿El monto de la deuda técnica supera el costo de solucionarlo?
• ¿Qué es realista que suceda si deja el código como está?
• ¿Cuáles son los problemas futuros que podrían surgir con o sin una refactorización?
• ¿Cuál es el grado de responsabilidad del código para usted y su empresa?

Estás en la mejor posición para responder esas preguntas. Sin embargo, según su descripción, no sé si me molestaría en refactorizar y simplificar las cosas, ya que no parece que valga la pena su tiempo. Si actualmente funciona, el cliente está contento y no quiere que le paguen por actualizar todo, entonces déjelo y trabaje en una actividad que genere ingresos.

En resumen, realice un análisis de costo-beneficio y una evaluación de riesgos de ambas vías y tome el curso de acción más seguro, eficiente y rentable.

¿No está eliminando este código y reemplazándolo con algo simple para facilitar la codificación futura de una característica que el cliente debe considerar y pagar?

Es posible que tenga algo útil de lo que otro desarrollador pueda aprender, pero no es probable que encuentre la aplicación de otro cliente para conectarlo.

Cotillear sobre el código de la competencia no es algo que puedas evitar. Se verán tontos intentando reclutar clientes de forma negativa.

Un dicho común es: "Si no está roto, no lo arregles".

Hay varios racionales detrás de esta regla. Algunos de ellos podrían ser que la "simplificación" se arriesgará a introducir errores nuevos, diferentes y posiblemente más grandes, podría alejar el tiempo de desarrollo de otros esfuerzos más valiosos, y podría ser un cambio completamente erróneo para alguna oportunidad de negocio futura inesperada que surge.

Si hay suficiente valor comercial para que este código sea portátil y más fácil de mantener, entonces decida si ese valor es realmente suficiente para considerar el código actual como "roto". Bien podría ser, si hay una gran expansión de negocios planificada, o si sospecha que hay un error latente oculto en la complejidad que podría hacer que el negocio caiga.

En primer lugar, si la aplicación ya fue tomada por un nuevo propietario, puede volver a ocurrir. Y el siguiente propietario puede comenzar nuevamente a usar esa complejidad de la que no se beneficia en este momento.

Aparte de esto, los cambios no triviales en el código de trabajo siempre conllevan un riesgo, por lo tanto (como otros lo señalaron) el cliente debería estar de acuerdo con (y pagar por ellos). Si la complejidad "adicional" actual no causa ningún inconveniente apreciable y medible (como problemas de rendimiento), no hay ninguna razón para eliminarlo.

Los clientes (potenciales) que (no) lo contratan basándose únicamente en los rumores de los competidores no valen la pena de todos modos, a menos que tenga una necesidad desesperada de ingresos. Tiene buenas y lógicas razones por las que implementó la aplicación como lo hizo, y es probable que cualquier cliente serio lo entienda. Alguien que no lo haga, o que ni siquiera se moleste en preguntarte, probablemente te causará más problemas en el camino de lo que vale el trabajo de todos modos.

  

En general, la complejidad necesaria anteriormente debería eliminarse aunque   funciona y ha habido una necesidad históricamente demostrada por la   complejidad, pero no hay indicios de que sea necesario en el   futuro?

No.

  

Incluso si a la pregunta anterior se responde generalmente "no", es aconsejable   elimine esta complejidad "innecesaria" si entrega el proyecto a un   competidor (o extraño)

No. ¿Por qué perder tu tiempo para arreglar los trabajos de baja prioridad como este? No hay daño para el código que se queda allí.

En cuanto a su pregunta: ¿Cuándo debería eliminarse la complejidad?

Mi opinión es, si no está roto, no lo arregles .

Para poder eliminar la complejidad, se debe cumplir lo siguiente:

1. La pieza eliminada debe ser independiente del programa. Si hay alguna dependencia entre el programa circundante y el código en cuestión, solo eliminar la complejidad no funcionará
2. Desafortunadamente, si parece complejidad, es muy probable que las piezas no sean independientes y que las dependencias vayan a interrumpir su programa cuando elimine la pieza.
3. Eliminar todas las dependencias llevará tiempo, por lo que se debe considerar el tiempo cuando se estima si la operación vale la pena.
4. La mayoría de las veces no vale la pena el esfuerzo, pero simplemente decidirás no hacer que ningún código nuevo use el anterior

Creo que hay algo más grande en el trabajo aquí ... Escalabilidad

De lo que estás hablando se llama Escalabilidad . No importa si el código es complejo, si la aplicación puede evolucionar según las nuevas reglas de negocios o las reglas de negocios modificadas. ¿Qué sucede si el siguiente propietario quiere algo totalmente diferente?

Por lo tanto, digo que guarde el código y documéntelo. Es una característica de cómo se puede utilizar la aplicación.

  

En general, la complejidad necesaria anteriormente debe eliminarse aunque funcione y haya habido una necesidad histórica demostrada de complejidad, pero ¿no tiene ninguna indicación de que sea necesaria en el futuro?

Hay un esfuerzo y un riesgo para eliminar la complejidad. Si eso es más alto que el esfuerzo y el riesgo adicionales de mantener el código demasiado complejo, entonces lo conservas. De lo contrario, lo eliminas. Sin embargo, es difícil estimar esos riesgos.

Añadiría que puede mitigar el riesgo de un mantenimiento más difícil documentando por qué , en primer lugar, utilizó la estrategia de patrón de diseño, en el código. Personalmente, creo que cualquier patrón de diseño debe ser rastreable a un requisito explícito (funcional o no funcional).

  

Incluso si a la pregunta anterior generalmente se responde "no", ¿es prudente eliminar esta complejidad "innecesaria" si se entrega el proyecto a un competidor (o desconocido)?

Su escenario de ser disuadido por la competencia por las horas de relleno es precisamente la razón por la que debe documentar la complejidad. Si documenta y justifica (con un requisito específico del cliente) el uso de cualquier patrón, entonces está cubierto. Si no puede justificar un patrón con los requisitos de un cliente, entonces parece un diseño excesivo o una patronitis.

Si los requisitos cambian, entonces puede justificar dejarlo debido al riesgo de que pueda romper el código (o la cantidad de trabajo para eliminar el patrón quirúrgicamente).

Creo que es bueno distinguir entre complejidad accidental y complejidad esencial , ya que los patrones a menudo involucran a ambos.

Es decir, su requisito de admitir diferentes algoritmos para decidir incrementos es una complejidad esencial (parte del problema a resolver). El mantenimiento de su código se hace más fácil con el patrón de la Estrategia, pero la alternativa de si / entonces con código rígido aún funcionará. He hecho ejercicios en mis cursos de maestría donde los estudiantes encuentran oportunidades para aplicar la Estrategia en proyectos de código abierto. La complejidad no es necesariamente mejor o peor cuando se aplica la Estrategia (porque es una complejidad esencial ). A veces puede ser incluso más difícil entender la Estrategia, porque el código se divide en varias clases con polimorfismo, en lugar de un bloque grande de if / then / else.

Idealmente, un patrón funciona cuando los beneficios que proporciona superan el costo de sus inconvenientes. De nuevo, cuantificar estas cosas es difícil. A menudo, un patrón hace feliz al desarrollador (no solo porque hace que sea más fácil agregar una nueva estrategia de subida, sino que también le da al desarrollador una idea de que se aplicó un patrón). Es difícil mostrar a los clientes cómo los beneficia.

El cliente no le importa o incluso no entiende los detalles. En el caso de que el nuevo propietario aplique KISS en sus procesos, es la reducción de la complejidad esencial , lo que también debería tener un impacto en la solución de software.