Punto de complejidad sin retorno. ¿Cómo llamas a eso?

13

Como desarrollador de software, una de mis tareas principales es mantener la complejidad bajo control.

Sin embargo, en algunos proyectos, hay un momento en que el nivel de complejidad crece tan alto que alcanza algún tipo de punto de "no retorno". Más allá de este momento, nunca podrá devolver el proyecto a un nivel aceptable de complejidad en menos tiempo del que necesitaría para volver a escribir todo desde cero.

¿Este momento en particular tiene un nombre en el dialecto de los programadores (algo similar a la ley de Godwin para los trolls)?

--edit--

Lo siento si no estoy claro. No creo que este "momento" tenga un nombre oficial, o es una métrica seria. Estaba pensando en algo en el espíritu de el "pico de Ballmer" en xkcd .

    
pregunta Thibault J 05.05.2011 - 10:55

8 respuestas

20

Es más un problema de mantenibilidad que de complejidad.

El fenómeno se denomina "deuda técnica" y, una vez que alcanza un nivel crítico, el proyecto está en camino a la bancarrota.

¿Eso es lo que quisiste decir?

    
respondido por el user8685 05.05.2011 - 11:12
16

El "punto de complejidad excesiva" se refiere en inglés como:

OH MI DIOS, QUÉ ES ESTE MIERCHO.

El problema es que esto puede aplicarse a algo que es realmente simple, pero se implementa de una manera tan horrible que tienes la misma reacción.

Así que separar algo muy complejo de algo muy horrible puede ser difícil.

SIN EMBARGO: lo que en realidad suele suceder con todo el software es un proceso como este:

Paso 1: Ten una buena especificación, haz un buen diseño, implementa cosas bonitas. Todos felices.

Al final del paso 1: los desarrolladores se felicitan por la maravillosa elegancia de su diseño y se van felices pensando "Tengo un maravilloso legado aquí para que otros puedan agregar cosas en el futuro, será maravilloso y el mundo" Será un lugar mejor ".

Paso 2: se hacen algunos cambios, se agregan cosas, se incluyen nuevas funciones. La arquitectura y la estructura del Paso 1 hicieron de este un proceso bastante indoloro. [Pero oops, el "factor cruft" aumentó un poco.]

Al final del paso 2: los desarrolladores se felicitan a sí mismos por la maravillosa elegancia de su diseño y se van felices pensando "Caramba, soy tan inteligente que hice todos esos subsidios en el Paso 1. Esto fue muy bueno. un maravilloso legado aquí para que otros agreguen cosas en el futuro, será maravilloso y el mundo será un lugar mejor ".

Paso 3: se realizan más cambios, se agregan más cosas, se incorporan más funciones, se cambian un montón de cosas, en realidad se está escuchando la opinión del usuario.

Al final del paso 3: los desarrolladores se felicitan a sí mismos por la maravillosa elegancia de su diseño, y se van bastante felices pensando "Vaya, esta arquitectura es bastante buena para permitir que tantos cambios se introduzcan fácilmente. Pero estoy un poco descontento con X e Y y Z. Se podrían limpiar un poco ahora. Pero ... ¡Ahhh! Soy tan inteligente que he hecho todos esos subsidios en el Paso 1. Esto fue muy bueno. Tengo una maravillosa legado aquí para que otros agreguen cosas en el futuro, será maravilloso y el mundo será un lugar mejor ".

Paso 4: como en el paso 3. Excepto:

Al final del paso 4: los desarrolladores piensan: "Este material que era tan bueno se está volviendo UGLY para mantener. Realmente necesita algunos cambios serios. Realmente no me gusta trabajar en esto. Necesita refactorización. Me pregunto lo que dirá el jefe cuando le diga que necesita 6 semanas y no habrá nada que los usuarios vean al final de este ... pero tendré otros 5 años de delicioso alcance de futuras modificaciones al hacer esto ... hmmm ... es hora de ir al pub a tomar algo de cerveza ".

Paso 5: Se deben hacer varios cambios.

Y DURANTE el paso 5, los desarrolladores se dicen unos a otros: "Este código apesta. ¿Quién escribió esto? Deberían ser fusilados. Es horrible. TENEMOS QUE ESCRIBIRLO".

El paso 5 es fatal. Aquí es donde el factor cruft se ha vuelto tan malo que el código no puede tener solo algunos cambios más, necesita tener algunos cambios GRANDES.

El problema en el Paso 5 es el deseo de tirarlo y comenzar de nuevo. La razón por la que esto es fatal es "El factor Netscape". Ve a google. Las empresas mueren en este momento, porque comenzar de nuevo significa que comienzas con aproximadamente un 50% de suposiciones en lugar de hechos, 150% de entusiasmo en lugar de conocimiento, 200% de arrogancia en lugar de humildad ("¡Esos tipos eran tan estupidos!"). Y presentas un montón de nuevos errores.

Lo mejor que puedes hacer es refactorizar. Cambia un poco a la vez. Si la arquitectura se está cansando un poco, arréglala. Añadir, ampliar, mejorar. Gradualmente. En cada paso a lo largo del camino, pruebe, pruebe y pruebe un poco más. Cambios incrementales como este significan que 10 años después, el código actual y el código original son como el hacha del abuelo ("tenía 10 cabezas nuevas y 3 manijas nuevas, pero aún es el hacha del abuelo"). En otras palabras, no queda mucho en común. Pero te mudaste de lo viejo a lo nuevo gradualmente y con cuidado. Esto reduce el riesgo, y para los clientes, reduce el factor de enojo.

    
respondido por el quickly_now 05.05.2011 - 12:17
2

Estoy de acuerdo en que el momento es difícil de reconocer y se puede evitar mediante procesos adecuados. Sin embargo, la pregunta era sobre cómo llamarlo. En economía real, existe el concepto de "rendimientos decrecientes": el punto en el cual el aumento de la entrada de un recurso en un proceso disminuye su beneficio general por unidad. Esto ciertamente se aplica a la codificación, e incluso las cosas buenas como la abstracción, la reutilización, etc. tienen un punto de rendimientos decrecientes. El término general específico de la programación es "sobreingeniería". Para alguien que es propenso a hacer esto, me gusta el término de Joel " astronauta de arquitectura ".

    
respondido por el Kilian Foth 05.05.2011 - 17:32
1

Muy a menudo, el buen código se descarta bajo la falsa impresión de que el nuevo equipo con nuevas herramientas puede hacerlo más barato, más rápido y más confiable, solo para encontrarlo

  • La complejidad está en el documento no documentado. requisitos
  • Las nuevas herramientas son más difíciles de usar que el sitio web flash prometido
  • El nuevo equipo no es tan 'caliente' como pensaban que eran

Posiblemente el tiempo que has descrito llega con algunas bases de código (solía pensar que sí). Nunca he experimentado personalmente un caso de código antiguo que haga que un proyecto se arruine, o he reescrito el código guardando un proyecto.

No incluyo en estos casos donde se han utilizado métricas para identificar módulos o diseños problemáticos específicos, que luego se eliminaron y reemplazaron.

    
respondido por el mattnz 05.05.2011 - 11:34
1

El problema real con este "momento" teórico es que solo se reconoce después del hecho. A menos que sus colegas sean psicópatas, cada compromiso individual en la base de código se realiza con la creencia de que es una mejora en esa base de código. Solo mirando hacia atrás al lío que sigue, puedes ver que has pasado ese "momento".

Pero me gusta que podamos darle un nombre. "Caballeros", podría decir, atrayendo a sus colegas desarrolladores a su alrededor, "Hemos cruzado el Panel de Mantenimiento. Envíele un mensaje de texto a su esposa y hágale saber que no la verá por un tiempo".

    
respondido por el Dan Ray 05.05.2011 - 14:57
-1

No sé si hay un nombre pero si no hay ninguno que propondría llamarlo "punto de fusión"

    
respondido por el DPD 05.05.2011 - 12:31
-2

Esta no es una pregunta muy interesante.

De hecho es trivial.

Es tan trivial que hemos evolucionado de muchas maneras para enfrentarlo.

  1. Metodologías de cascada. Mucha gente pasa mucho tiempo revisando los requisitos y diseñando documentos para asegurarse de que se maneja la complejidad.

  2. Metodologías ágiles. Cada vez menos personas pasan menos tiempo discutiendo qué se aplica de inmediato para resolver el problema de alguien y lanzarles un software. La complejidad se administra porque todos están enfocados en obtener algo publicado.

La única vez que alguien lucha con la "complejidad" es porque no se sigue la metodología y no se administra el tiempo adecuadamente.

  • No hay supervisión detallada en una metodología de cascada. No están obligados a revisar los productos de trabajo intermedios según los requisitos, la arquitectura, el diseño de alto nivel o las revisiones de diseño detalladas.

  • No hay una fecha límite de sprint o prioridades de caso de uso adecuadas en una metodología Agile. No están enfocados en hacer que el usuario publique algo tan rápido como sea posible.

La complejidad debe limitarse mediante el establecimiento de objetivos.

Luchar con complejidad significa que los objetivos no se establecen o no se recompensan correctamente.

No hay "punto de inflexión". Si la gestión de la complejidad es de alguna manera un problema, algo ya está mal organizativamente.

    
respondido por el S.Lott 05.05.2011 - 11:57
-2

Existen métodos para visualizar y monitorear el riesgo de aumentar la complejidad de los proyectos (grandes) y el código. Cuando se aplican razonablemente, se espera que no sea necesario un nuevo nombre para el punto de no devolución. (Hay un MOOC relacionado en openHPI: enlace )

La complejidad estructural es un problema general de diseño, no solo para el diseño de software en grandes equipos. La visualización es el primer paso en la gestión de la complejidad estructural. Las matrices y los gráficos dirigidos también se pueden utilizar para este propósito.

Los métodos para reducir la complejidad estructural son enlace :

  • modularización
  • evitar los bucles de retroalimentación
  • triangulación

Además, existe el concepto de diseño axiomático: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Con este concepto se pueden evitar problemas de fiabilidad debido a una complejidad innecesaria.

Por lo tanto, hay un montón de métodos disponibles. Al final, siempre se trata de la decisión de pensar en ellos porque un proyecto es lo suficientemente grande.

    
respondido por el Eddi 28.06.2016 - 19:03

Lea otras preguntas en las etiquetas