Muchas veces nos encontramos trabajando en un problema, solo para descubrir que la solución que se está creando es mucho más compleja de lo que el problema requiere. ¿Existen controles, mejores prácticas, técnicas, etc. que lo ayuden a controlar las complicaciones en su lugar de trabajo?¿Cómo previene soluciones o diseños complicados?
Conseguir que alguien nuevo lo mire.
Si es demasiado difícil de probar, su diseño es demasiado complicado. Esa es la primera métrica que uso.
Es inevitable que una vez que haya sido programador esto suceda. Si realmente ha subestimado el esfuerzo o ha llegado a un problema en el que su solución simplemente no funciona, entonces detenga la codificación y hable con su gerente de proyecto. Siempre me gusta llevar las soluciones conmigo a la reunión, el problema es A, puede hacer x, lo que tomará 3 días o podemos intentarlo, lo que demorará 6 días. No hagas la elección tú mismo.
Creo un diseño, etc., y luego lo miro y trato de quitar (agresivamente) todo lo que no parece ser necesario. Si resulta que lo necesito más tarde cuando estoy puliendo el diseño, lo vuelvo a agregar. Lo hago en varias iteraciones, refinando a medida que avanzo.
Este es un delicado acto de equilibrio: por un lado, no desea algo que tarde demasiado en diseñarse e implementarse, por otro lado, no desea un truco que no sea lo suficientemente complicado para lidiar con el problema de la próxima semana o, incluso peor, requiere una nueva redacción para adaptarse.
Un par de técnicas que encuentro útil:
Si algo parece más compleja de lo que le gustaría a continuación, nunca se sientan a poner en práctica tan pronto como haya terminado de pensarlo. Encuentre algo más para hacer por el resto del día. Numerosas veces termino pensando en una solución diferente a una parte temprana del problema que elimina gran parte de la complejidad más adelante.
En una línea similar, tiene a alguien más a quien le puede sacar ideas. ¡Asegúrate de explicarles por qué la complejidad está justificada!
Si está agregando complejidad porque cree que se justificará en el futuro, intente establecer cuando en el futuro lo utilizará. Si no puede (realistamente) imaginar que necesita la complejidad durante un año o tres, entonces probablemente no sea justificable pagar ahora.
La prueba primero puede ayudar aquí, pero no es adecuado para todas las situaciones. Y no es una panacea de todos modos.
Comience pequeño es otra gran idea. ¿De verdad necesitas rellenar los 10 patrones de diseño en esta cosa? Intenta primero hacerlo "de manera estúpida". No acaba de cortarlo?De acuerdo, hazlo "de una manera un poco menos estúpida". Etc.
Haz que tu reseña. Como alguien más escribió, dos pares de ojos son mejores. Aún mejor son dos cerebros. Es posible que tu pareja solo vea un espacio para la simplificación, o un área problemática que pensabas que estaba bien simplemente porque pasas muchas horas pirateándola.
Utilice lenguaje simplificado. Los lenguajes como Java, o algunas veces C++ a veces parecen alentar soluciones desagradables y complicadas. Las cosas simples tienden a abarcar múltiples líneas de código, y solo necesita usar 3 bibliotecas externas y un gran marco para administrarlo todo. Considere usar Python, Ruby, etc., si no fuera por su proyecto, entonces para un uso privado. Puede cambiar su forma de pensar para favorecer la simplicidad, y para estar seguro de que la simplicidad es posible.
Lea "Trabajando eficazmente con código heredado" por Michael C. Feathers.
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 se pueda probar y dividir el código en partes más pequeñas.
En mi experiencia, el diseño para un caso excesivamente general tiende a generar demasiada complejidad.
La cultura de ingeniería alienta diseños que hacen menos suposiciones sobre el medio ambiente; esto generalmente es algo bueno, pero algunas personas lo llevan demasiado lejos. Por ejemplo, podría ser agradable si el diseño de su automóvil no supone una atracción gravitacional específica, nadie va a conducir su automóvil en la luna, y si lo hicieran, no funcionaría, porque no hay oxígeno para hacer que el combustible arda
La parte difícil es que el tipo que se desarrolla la "trabaja-en-cualquier-planeta" El diseño es a menudo considerado como inteligente, por lo que es posible que tenga que trabajar más para argumentar que su diseño es demasiado inteligente.
Comprender las ventajas y desventajas, para que pueda tomar la decisión entre suposiciones buenas y suposiciones erróneas, contribuirá en gran medida a evitar un diseño innecesariamente complicado.
Reduzca la cantidad de datos con los que está trabajando serializando la tarea en una serie de tareas más pequeñas. La mayoría de las personas solo puede tener media docena (más o menos) condiciones en la cabeza mientras codifica, por lo tanto, conviértelos en la unidad de implementación. Diseñe para todas las tareas que necesita realizar, pero luego corte 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: simplifíquelo hasta que sea fácil.
Aquí están algunas ideas para un diseño más simple:
pido a mis clientes qué que necesitan alguna característica. Intento llegar al final de su solicitud e identificar 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ían.
Por supuesto, si conoce los hábitos de trabajo de sus clientes y los problemas que tienen que enfrentar, puede comprender sus problemas mucho mejor desde el primer momento. Y si los "conoces", los conoces, entonces entiendes mejor su discurso. Por lo tanto, desarrolle una relación de trabajo cercana con sus usuarios. Es el paso cero de la ingeniería.
Tómese el tiempo para nombrar los conceptos del sistema y encontrar nombres que estén relacionados, esto hace que el sistema sea más familiar. No dude en renombrar conceptos, cuanto mejor sea la conexión con el mundo que conoce, mejor podrá trabajar con su cerebro.
Pida las opiniones de las personas que reciben sus impulsos de soluciones simples y limpias.
Solo implemente los conceptos necesarios para el proyecto actual (un deseo de pruebas futuras o sistemas genéricos hace que su diseño se hinche).
El uso de Test Driven Development y después de Three Rules of TDD Robert C. Martin:
De esta forma, no es probable que obtenga muchos códigos que no necesita. Siempre te concentrarás en hacer que una cosa importante funcione y nunca te adelantarás en términos de complejidad.
Mirando la primera respuesta, no creo que esta deba ser una wiki de la comunidad. Gran Q, excelente A. –