| dbo:abstract
|
- En Computación, el antipatrón de diseño Accidental complexity o Complejidad no indispensable describe la situación a la que se llega cuando en el desarrollo de una aplicación se selecciona un camino de complejidad mayor que la indispensable. En algunos casos, la complejidad es inherente al problema, pero también ocurre que esta se introduce por desconocimiento o por problemas de planificación. Una situación como esta, si no es reconocida, puede motivar la cancelación del proyecto. Muchas veces la complejidad innecesaria viene de despreciar las soluciones más directas por considerarlas demasiado obvias. En otras ocasiones viene de la creación de bibliotecas por grupos que no las utilizan, de manera que no perciben los costos innecesariamente introducidos en ellas. Otro ejemplo de complejidad accidental durante el proceso de desarrollo, ocurre cuando se decide programar a nivel de código de máquina una parte de un proyecto cuya velocidad (mayor ganancia al hacer esto), no afecta sensiblemente la velocidad del proyecto en su conjunto. En este caso se introduce en el proyecto la complejidad innecesaria de deber mantener código en varios lenguajes, y sobre todo una parte del código en lenguaje de bajo nivel. Para evitar este patrón, se puede incluir en el diseño, consideraciones razonadas de costo (tiempo/espacio) esperado, de manera que si estos costos son superados, se entienda si es en el diseño o en la realización donde está el problema. (es)
- En Computación, el antipatrón de diseño Accidental complexity o Complejidad no indispensable describe la situación a la que se llega cuando en el desarrollo de una aplicación se selecciona un camino de complejidad mayor que la indispensable. En algunos casos, la complejidad es inherente al problema, pero también ocurre que esta se introduce por desconocimiento o por problemas de planificación. Una situación como esta, si no es reconocida, puede motivar la cancelación del proyecto. Muchas veces la complejidad innecesaria viene de despreciar las soluciones más directas por considerarlas demasiado obvias. En otras ocasiones viene de la creación de bibliotecas por grupos que no las utilizan, de manera que no perciben los costos innecesariamente introducidos en ellas. Otro ejemplo de complejidad accidental durante el proceso de desarrollo, ocurre cuando se decide programar a nivel de código de máquina una parte de un proyecto cuya velocidad (mayor ganancia al hacer esto), no afecta sensiblemente la velocidad del proyecto en su conjunto. En este caso se introduce en el proyecto la complejidad innecesaria de deber mantener código en varios lenguajes, y sobre todo una parte del código en lenguaje de bajo nivel. Para evitar este patrón, se puede incluir en el diseño, consideraciones razonadas de costo (tiempo/espacio) esperado, de manera que si estos costos son superados, se entienda si es en el diseño o en la realización donde está el problema. (es)
|
| rdfs:comment
|
- En Computación, el antipatrón de diseño Accidental complexity o Complejidad no indispensable describe la situación a la que se llega cuando en el desarrollo de una aplicación se selecciona un camino de complejidad mayor que la indispensable. En algunos casos, la complejidad es inherente al problema, pero también ocurre que esta se introduce por desconocimiento o por problemas de planificación. Una situación como esta, si no es reconocida, puede motivar la cancelación del proyecto. (es)
- En Computación, el antipatrón de diseño Accidental complexity o Complejidad no indispensable describe la situación a la que se llega cuando en el desarrollo de una aplicación se selecciona un camino de complejidad mayor que la indispensable. En algunos casos, la complejidad es inherente al problema, pero también ocurre que esta se introduce por desconocimiento o por problemas de planificación. Una situación como esta, si no es reconocida, puede motivar la cancelación del proyecto. (es)
|
