¿Cómo luchar contra la complejidad del diseño? [cerrado]

https://stackoverflow.com/questions/602990

03-07-2019
|

Pregunta

A menudo me encuentro luchando contra la ingeniería excesiva: la persona a cargo de diseñar el software viene con una arquitectura que está muy complicada.

Está todo bien y elegante tener todas las características esotéricas que los usuarios nunca conocerán y tendrán esa sensación de logro cuando estás haciendo algo que todos los artículos de revistas te dicen que es lo último, lo mejor, pero estamos gastaremos la mitad de nuestro tiempo de ingeniería en este monumento a nuestra inteligencia, y no, ya sabes, el producto real que nuestros usuarios necesitan y la alta gerencia espera que se complete dentro de un marco de tiempo razonable o al menos limitado.

Y, probablemente, solo tendrás que volver a la solución más sencilla cuando empieces a quedarte sin tiempo, es decir, si tienes esa oportunidad.

Todos hemos escuchado el refrán: Mantenlo simple, estúpido & # 8482 ;.

¿Cómo luchas con la complejidad excesiva de tu equipo?

Un ejemplo con el que he tenido que trabajar últimamente es cuando se tomó la decisión de ir a un diseño de base de datos completamente desnormalizado en lugar de a un RDBMS. " porque es más rápido! " Las bases de datos completamente desnormalizadas son muy difíciles de corregir, y solo son apropiadas para problemas de datos realmente especializados como Flickr o eBay, y pueden ser extremadamente costosas en términos de tiempo de desarrollador en relación con el resto de su desarrollo.

Solución

Diente y clavo, ya veces se pierde. El problema es que siempre es fácil sentirse tentado a construir algo cool .

¿Por qué construir algo simple y eficiente cuando puede ser complicado y maravilloso?

Intente recordar a la gente la regla de XP de construir la cosa más simple que posiblemente pueda funcionar.

Otros consejos

Asegúrate de rebotar cualquier idea que tengas de alguien más. A menudo, estamos tan envueltos en hacer las cosas de una manera determinada que hace falta otro par de ojos para ponerte bien. Muchas veces he descubierto problemas difíciles al tener a alguien más que me diga "¿realmente necesitamos lo que necesitamos? & Quot; Esto ayuda a simplificar mi código.

A la hora de tratar con personas con las que no está de acuerdo, Ward Cunningham tiene un buen punto:

Fue un punto de inflexión en mi carrera de programación cuando me di cuenta de que no tenía que ganar todos los argumentos. Hablaría de código con alguien y diría: "Creo que la mejor manera de hacerlo es A." Y decían: "Creo que la mejor manera de hacerlo es B. Yo diría," Bueno, no, es realmente A. " Y ellos decían, "bueno, queremos hacer B". Fue un punto de inflexión para mí cuando pude decir, "Bien. Do B. No nos va a doler mucho si me equivoco. No nos va a doler mucho si tengo razón y usted B, porque podemos corregir los errores. Así que averigüemos si es un error. ... Por lo general, resulta ser C. Es una experiencia de aprendizaje para los dos. Si decidimos sin la experiencia, ninguno de nosotros realmente aprende. Ward ganó, y alguien más no lo hizo. O viceversa. Es demasiado una batalla. ¿Por qué no decir "bien", vamos a codificarlo y ver qué pasa. Si no funciona, lo cambiaremos. & Quot; "

Mi consejo? Si quieres hacer algo mejor, crea un prototipo simple que demuestre que es mejor. Las opiniones son geniales, pero el código habla.

He visto esta fórmula en alguna parte:

habilidad = complejidad del problema / complejidad de la solución http://img39.imageshack.us /img39/1586/whatisskill.png

En otras palabras, se requiere habilidad para crear una solución simple para un problema complejo. Si alguien diseña y se enorgullece a propósito de soluciones complejas de ingeniería excesiva, es inconscientemente incompetente.

Personalmente, lo que me ayuda a mantener mis diseños simples es el ciclo TDD. Primero escribe una prueba que especifique a qué estás tratando de llegar y luego produce " lo más simple que podría funcionar " . Y de vez en cuando, reflexiona sobre lo que has producido y piensa cómo hacerlo más simple.

Nunca construya capas adicionales de flexibilidad y abstracción en el sistema, hasta que lo requiera algo que tenga ahora. Cambiar el código es fácil, cuando tiene un buen conjunto de pruebas de unidad, por lo que puede agregar esas capas de abstracción más tarde, cuando surja la necesidad, si surge alguna vez. De lo contrario, " no lo vas a necesitar " .

Algunos síntomas de un diseño demasiado complejo son cuando la escritura de pruebas es complicada. Si las pruebas requieren un código de configuración largo, quizás tenga demasiadas dependencias o, de alguna otra manera, demasiada complejidad. Si te encuentras con errores de concurrencia, entonces quizás deberías pensar en cómo diseñar el sistema para que la concurrencia se limite al número mínimo absoluto de clases. Tal vez utilice una arquitectura de paso de mensajes, como el modelo Actor, y haga que prácticamente todos los componentes sean de un solo subproceso, aunque el sistema en su conjunto sea de múltiples subprocesos.

Al menos para mí, el problema más grande es que a menudo es difícil decir qué característica está allí debido a su bondad de negocios y revistas, y está ahí porque agrega un nivel de flexibilidad que será útil en el futuro.

Se ha demostrado que las personas generalmente son terribles en anticipar la complejidad futura y los efectos secundarios de las decisiones actuales. Desafortunadamente, esto no siempre significa que lo más simple sea lo mejor; en mi caso, hubo un montón de cosas que pensé que eran demasiado complicadas al principio y que no vi el valor hasta mucho más tarde (er ... spring). También las cosas que pensé tenían sentido y que se volvieron extremadamente complicadas (EJB1). Entonces sé que mi intuición sobre estas cosas es defectuosa.

Mejor apuesta: cualquier tipo de capa de direccionamiento indirecto debe admitirse con un argumento que respalde el valor de la flexibilidad que agrega frente a su complejidad de desarrollo agregado.

Sin embargo, las personas que están manteniendo dogmáticamente una configuración particular de db sobre una base abstracta probablemente se encuentren en la "compilación" porque leí que es lo correcto " acampar. Puede que no sea realista, pero algunas personas podrían estar convencidas si construye una versión de prueba y un punto de referencia, especialmente si los resultados muestran un mayor esfuerzo que conduce a un aumento insignificante del rendimiento.

Está todo bien y elegante tener todo Las características esotéricas que tendrán los usuarios. nunca se sabe y ...

Esto sería fluencia de características , no es un diseño innecesariamente complicado. Es diferente de su ejemplo en las bases de datos.

Un ejemplo con el que he tenido que trabajar repetidamente últimamente es cuando la decisión Se ha hecho para ir a un completo diseño de base de datos desnormalizado en lugar que un RDBMS. " porque es más rápido! "

En este caso, pueden estar sucediendo varias cosas. Uno de ellos es que podría estar equivocado y estas personas realmente podrían saber lo que están diciendo porque han trabajado con ejemplos muy similares. Otra es que podrían estar equivocados, es decir, su diseño no ofrece las ventajas de velocidad que afirman. En este caso, podría haber dos situaciones diferentes: (1) Le están dando demasiado peso a la velocidad en su diseño, o (2) la velocidad es realmente crítica. Si la velocidad es tan relevante, el equipo no debe confiar solo en suposiciones, sino que debe probar diferentes prototipos y evaluar su velocidad en las rutas críticas. No construyes un coche de F1 de una manera solo "porque es más rápido", en lugar de eso, sigues probando varias soluciones de diseño alternativas y eliges la más rápida, lo que aún no aumenta demasiado los costos de mantenimiento.

A veces puedes discutirlo y llegar a un acuerdo, a veces no puedes. Es la vida.

Una palabra final, sin embargo. No luchas complejidad. Lo tratas. Identificas las cosas realmente importantes y actúas en consecuencia.

Supongo que te refieres a "diseño de base de datos completamente desnormalizado en lugar de un modelo normalizado (por ejemplo, tercera o cuarta forma normal), porque un RDBMS administra un modelo relacional independientemente de qué tan normalizado esté.

No puedo juzgar sin saber más sobre tus requisitos, tus habilidades y las de tus compañeros de equipo.

Me temo que su advertencia KISS podría no funcionar en este caso, porque una gran tabla desnormalizada podría defenderse como la cosa más simple posible.

¿Cómo alguien resuelve este tipo de problemas? Comunicación, persuasión, mejores datos, prototipos de tecnologías y técnicas alternativas. Esto es lo que hace que el desarrollo de software sea tan difícil. Si solo hubiera una forma de hacer estas cosas, y todos estuvieran de acuerdo con ellas, podríamos realmente escribirlas o hacer que cualquiera desarrolle sistemas y que se haga con ellos.

Consigue algunos datos. Tus palabras pueden no ser suficientes. Si un prototipo rápido puede demostrar su punto, créelo.

" Opiniones fuertes, ligeramente sostenidas " Debería ser tu lema.

A veces, un punto técnico no vale la pena alienar a todo tu equipo. A veces lo es. Su llamada.

Combatirás con alguien más el exceso de diseño / característica de varias formas:

Solicite prioridad de función, en función de los requisitos reales del usuario. Simule características para los analizadores alfa y beta, y pregunte si cambiarían N meses de retraso por ello.
Refactorar agresivamente para evitar carcasas especiales. Divida el código en capas o componentes modulares cuando sea apropiado. Encuentre un equilibrio entre " funciona bien ahora " y " fácil de extender más adelante " ;.
Notifique a su administración cuando no esté de acuerdo con las decisiones de diseño, prepárese para ser anulado y acepte la decisión. No pase por encima de la cabeza o el código de sabotaje.

La mejor manera que he encontrado es preguntar sin cesar, una y otra vez, "cuál es el problema comercial que intentamos resolver" y "cómo ayuda esta decisión a resolver ese problema".

Encuentro que con demasiada frecuencia la gente salta a las soluciones en lugar de tener muy claro cuál es el problema.

Entonces, en su ejemplo de cómo organizar una base de datos, mi pregunta sería "¿Cuáles creemos que son los requisitos de transacción para este proyecto hoy, el próximo mes, el próximo año, dentro de cinco años?". Puede ser que tenga sentido gastar mucho tiempo para obtener el modelo de datos correcto, podría ser una pérdida de tiempo. No sabe cuáles son los parámetros hasta que no se aclare la definición del problema.

Es posible que sufras "demasiados arquitectos en el equipo" síndrome. Una o dos personas como máximo deben diseñar / diseñar un sistema que será codificado por un equipo de 5 a 10 personas. Los comentarios son bienvenidos de todos, pero los tomadores de decisiones sobre arquitectura deben ser pocos y con experiencia.

(los números son semi-aleatorios y podrían ser diferentes dependiendo de otros factores también)

Trato de ser abierto al discutir asuntos. Pero cuando estoy discutiendo con alguien más entre algo que parece simple y otro complicado, me pongo tan terco como puede ser. Ayuda mucho, siempre y cuando seas muy coherente de una decisión a otra.

Su ejemplo no es realmente un diseño complicado, es una opción de diseño con la que no está de acuerdo. Ya que está trabajando en el código, podría estar en lo cierto porque muchas de estas decisiones las toman personas que leen un artículo en un artículo y piensan que suena como una buena meta, o que la decisión podría haber sido tomada por alguien que se topó con problemas antes e intentaba evitar que volviera a suceder.

Personalmente, he hecho muchas cosas de la manera más fácil y muchas de la manera más difícil, y nunca me siento feliz cuando elijo hacer algo de la manera más fácil. Ahora he aprendido trucos como "nunca pasar una colección desnuda, siempre envuélvalo en una clase de negocios".

Si tuviera que explicar el razonamiento detrás de alguien que no había pasado por las mismas experiencias, no lo entenderían hasta que intentaran comparar la "forma fácil". a la " manera dura " algunas veces.

La solución no debe ser más compleja que el problema.

La pregunta se entrelaza con el pensamiento de la complejidad esencial. Un género debe tocar cada elemento, por su esencia. ¿Cuánto más complejo debe ser para resolver el problema, dadas las limitaciones técnicas que existen?

¿Las personas involucradas tienen suficiente tiempo e incentivo para encontrar una solución simple? Sin cuidado, la complejidad aumentará. Si pasa la mayor parte de su tiempo tratando de hacer la corrección de errores o la adición de funciones lo más rápido posible, diga "mantenerlo simple" no será suficiente

Asegúrese de que haya algunas personas en el equipo con heridas de guerra por mantener programas grandes, y personas con experiencia en refactorización, y luego deles tiempo para ordenar el software. Si puede organizar que ciertas características y oportunidades estén fuera del alcance, eso ayudará a las personas a eliminar el código innecesario. Si desea una métrica, intente reducir las líneas de código; Pero trata de no obsesionarte por ello. Mejorar la cobertura de la prueba; Considere eliminar los bits de código que son difíciles de probar.

No trates de hacer todo de una vez. Rompe todos los problemas / tareas en trozos manejables. Luego prioriza, teniendo en cuenta a KISS y YAGNI. Esto te ayudará a concentrarte en construir lo que necesitas . Si lo has hecho bien, tendrás un buen núcleo al que puedes agregar más tarde, con tiempo, dinero, recursos e inspiración.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow