¿Cómo se evitan soluciones o diseños demasiado complicados?[cerrado]

Question

Muchas veces nos encontramos trabajando en un problema, sólo para descubrir que la solución que se está creando es mucho más compleja de lo que requiere el problema.¿Existen controles, mejores prácticas, técnicas, etc. que le ayuden a controlar las complicaciones en su lugar de trabajo?

Answer 1

Conseguir que alguien nuevo lo mire.

Answer 2

Si es demasiado difícil de probar, su diseño es demasiado complicado.Esa es la primera métrica que uso.

Answer 3

En mi experiencia, diseñar para un caso demasiado general tiende a generar demasiada complejidad.

La cultura de la ingeniería fomenta diseños que hacen menos suposiciones sobre el medio ambiente;Esto suele ser algo bueno, pero algunas personas lo llevan demasiado lejos.Por ejemplo, podría Sería bueno si el diseño de su automóvil no asume una atracción gravitacional específica, en realidad nadie conducirá su automóvil en la luna, y si lo hicieran, no funcionaría, porque no hay oxígeno para hacer quemar el combustible.

La parte difícil es que el tipo que desarrolla el diseño "funciona en cualquier planeta" a menudo se considera inteligente, por lo que es posible que tengas que esforzarte más para argumentar que su diseño es también inteligente.

Comprender las compensaciones, para poder tomar la decisión entre buenos y malos supuestos, contribuirá en gran medida a evitar un diseño innecesariamente complicado.

Answer 4

Aquí hay algunas ideas para simplificar el diseño:

• leer algunos libros y artículos de programación, y luego aplicar ellos en tu trabajo y escribe código
• lea muchos códigos (buenos y malos) escritos por otras personas (como proyectos de código abierto) y aprenda a ver qué funciona y qué no.
• Construya redes de seguridad (pruebas unitarias) para permitir experimentos con su código.
• use el control de versiones para habilitar la reversión, si esos experimentos toman el rumbo equivocado
• TDD (desarrollo impulsado por pruebas) y BDD (desarrollo impulsado por el comportamiento)
• cambia tu actitud, pregunta cómo puedes lograrlo, que "simplemente funciona" (La convención sobre la configuración podría ayudar allí;o preguntar cómo lo haría Apple)
• practicar (como los músicos de jazz: improvisar con código, probar Código Kata)
• escribir el mismo código varias veces, con diferentes idiomas y después de que haya pasado un tiempo
• aprende nuevos idiomas con nuevos conceptos (si usas un lenguaje estático, aprende uno dinámico;si usas lenguaje procedimental, aprende uno funcional;...) [un idioma por año es lo correcto]
• Pídale a alguien que revise su código y le pregunte activamente cómo puede hacer que su código sea más simple y elegante (y luego hacerlo)
• obtenga años en su haber haciendo cosas superiores (el tiempo ayuda a la mente activa)

Answer 5

Creo un diseño, etc., y luego lo miro e intento eliminar (agresivamente) todo lo que no parece ser necesario.Si resulta que lo necesito más tarde, cuando esté puliendo el diseño, lo vuelvo a agregar.Hago esto en varias iteraciones, perfeccionando a medida que avanzo.

Answer 6

Lea "Trabajar eficazmente con código heredado" de Michael C.Plumas.

El punto es que, si tiene un código que funciona y necesita cambiar el diseño, nada funciona mejor que hacer que su unidad de código sea comprobable y dividirlo en partes más pequeñas.

Answer 7

Usando Test Driven Development y siguiendo a Robert C.martin Tres reglas de TDD:

1. No se le permite escribir ningún código de producción a menos que sea para realizar una prueba unitaria fallida.
2. No se le permite escribir más pruebas unitarias de las que sean suficientes para fallar;y los fallos de compilación son fracasos.
3. No se le permite escribir más código de producción del suficiente para pasar la prueba unitaria fallida.

De esta manera, no es probable que obtenga mucho código que no necesita.Siempre estarás concentrado en hacer que algo importante funcione y nunca te adelantarás demasiado en términos de complejidad.

Answer 8

Prueba primero Puede ayudar aquí, pero no es adecuado para todas las situaciones.Y de todos modos no es una panacea.

Empieza pequeño es otra gran idea.¿Realmente necesitas incluir los 10 patrones de diseño en esto?Primero intenta hacerlo "de manera estúpida".¿No es suficiente?Bien, hazlo "de una manera un poco menos estúpida".Etc.

Hazlo revisar.Como alguien más escribió, dos pares de ojos son mejores.Aún mejores son dos cerebros.Es posible que tu pareja simplemente vea un margen de simplificación o un área problemática que pensaste que estaba bien solo porque pasaste muchas horas hackeándola.

Utilice un lenguaje sencillo. Lenguajes como Java o, a veces, C++ parecen fomentar soluciones desagradables y complicadas.Las cosas simples tienden a abarcar varias líneas de código y solo necesitas usar 3 bibliotecas externas y un marco grande para administrarlo todo.Considere usar Python, Ruby, etc.- si no es para su proyecto, entonces para algún uso privado.Puede cambia tu forma de pensar favorecer la simplicidad y tener la seguridad de que la simplicidad es posible.

Answer 9

Es inevitable que esto suceda una vez que hayas sido programador.Si realmente ha subestimado el esfuerzo o se ha encontrado con un problema donde su solución simplemente no funciona, deje de codificar y hable con su gerente de proyecto.Siempre me gusta llevar las soluciones a la reunión, el problema es A, puedes hacer x que tomará 3 días o podemos probar y que tomará 6 días.No tomes la decisión tú mismo.

Answer 10

• Habla con otros programadores en cada paso del camino.Cuantos más ojos hay en el diseño, es más probable que se revele pronto un aspecto demasiado complicado, antes de que se osifique demasiado en el código base.
• Pregúntese constantemente cómo utilizará lo que sea en lo que esté trabajando actualmente.Si la respuesta es que no estás seguro, detente a repensar lo que estás haciendo.
• Me ha resultado útil anotar ideas sobre cómo simplificar potencialmente algo en lo que estoy trabajando actualmente.De esa manera, una vez que lo tenga funcionando, será más fácil regresar y refactorizar o rehacer según sea necesario en lugar de alterar algo que ni siquiera funciona todavía.

Answer 11

Este es un delicado acto de equilibrio:por un lado, no desea algo que requiera demasiado tiempo para diseñarse e implementarse; por otro lado, no desea un truco que no sea lo suficientemente complicado como para abordar el problema de la próxima semana o, peor aún, que requiera reescribir para adaptarse. .

Un par de técnicas que encuentro útiles:

Si algo parece más complejo de lo que le gustaría, nunca se siente a implementarlo tan pronto como haya terminado de pensar en ello.Encuentra algo más que hacer durante el resto del día.Muchas veces termino pensando en una solución diferente para una parte inicial del problema que elimine gran parte de la complejidad más adelante.

De manera similar, tenga a alguien más con quien pueda intercambiar ideas.¡Asegúrate de poder explicarles por qué se justifica la complejidad!

Si agrega complejidad porque cree que estará justificado en el futuro, intente establecer cuando en el futuro lo usarás.Si no puede (de manera realista) imaginarse necesitando la complejidad durante uno o tres años, entonces probablemente no sea justificable pagar por ello ahora.

Answer 12

Reduzca la cantidad de datos con los que trabaja serializando la tarea en una serie de tareas más pequeñas.La mayoría de las personas sólo pueden mantener media docena de condiciones (más o menos) en su cabeza mientras codifican, así que conviértala en la unidad de implementación.Diseñe para todas las tareas que necesita realizar, pero luego piratee sin piedad el diseño para que nunca tenga que jugar con más de media docena de rutas a través del módulo.

Esto se desprende de la publicación de Bendazo: simplifica hasta que sea fácil.

Answer 13

les pregunto a mis clientes por qué necesitan alguna característica.Intento llegar al fondo de su solicitud e identifico el problema que están experimentando.Esto a menudo se presta a una solución más simple de lo que yo (o ellos) pensaríamos.

Por supuesto, si conoce los hábitos de trabajo de sus clientes y los problemas que tienen que abordar, podrá comprender sus problemas mucho mejor desde el principio.Y si los "conoces", entonces entenderás mejor su discurso.Por lo tanto, desarrolle una estrecha relación de trabajo con sus usuarios.Es el paso cero de la ingeniería.

Answer 14

Tómate el tiempo para nombrar bien los conceptos del sistema, y ​​busca nombres que estén relacionados, esto hace que el sistema sea más familiar.No dudes en cambiar el nombre de los conceptos: cuanto mejor sea la conexión con el mundo que conoces, mejor podrá trabajar tu cerebro con él.

Pida opiniones de personas a las que les gusten las soluciones limpias y sencillas.

Implemente solo los conceptos necesarios para el proyecto actual (el deseo de pruebas futuras o sistemas genéricos hacen que su diseño sea inflado).