design - online - tag template
¿Cómo previene soluciones o diseños complicados? (14)
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?
Aquí hay algunas ideas para simplificar el diseño:
- lea algunos libros de programación y artículos, y luego aplíquelos en su trabajo y escriba el código
- lee muchos códigos (buenos y malos) escritos por otras personas (como proyectos de código abierto) y aprende a ver qué funciona y qué no funciona
- construir redes de seguridad (pruebas unitarias) para permitir la experimentación con su código
- use control de versiones para permitir la reversión, si esas experimentaciones toman el giro equivocado
- TDD (desarrollo impulsado por prueba) y BDD (desarrollo impulsado por comportamiento)
- cambie su actitud, pregunte cómo puede hacerlo, que "simplemente funciona" (la convención sobre la configuración podría ayudar allí, o pregunte cómo lo haría Apple)
- práctica (como los jugadores de jazz - jam con código, prueba Code Kata )
- escribe el mismo código varias veces, con diferentes idiomas y después de un tiempo ha pasado
- aprende nuevos idiomas con nuevos conceptos (si usas lenguaje estático, aprende uno dinámico, si usas lenguaje de procedimiento, aprende uno funcional ...) [un idioma por año es más o menos]
- pídale a alguien que revise su código y pregunte activamente cómo puede hacer que su código sea más simple y más elegante ( y luego hacerlo )
- ten años bajo tu cinturón haciendo las cosas anteriores (el tiempo ayuda a la mente activa)
Conseguir que alguien nuevo lo mire.
Creo un diseño, etc., y luego lo miro y trato de eliminar (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.
En mi experiencia, diseñar para un caso demasiado 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 bueno si el diseño de su automóvil no supone una atracción gravitacional específica, nadie realmente va a conducir su automóvil a la luna, y si lo hicieran, no funcionaría, porque no hay oxígeno para hacer el combustible quemado
La parte difícil es que el tipo que se desarrolla el diseño de "trabajos en cualquier planeta" a menudo se considera inteligente, por lo que es posible que tenga que trabajar más duro para argumentar que su diseño es demasiado inteligente.
Comprender las compensaciones, 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.
Este es un acto de equilibrio delicado: por un lado, no quieres algo que tarde demasiado en diseñarlo e implementarlo; por otro lado, no quieres un truco que no sea lo suficientemente complicado como para lidiar con el problema de la próxima semana, o incluso peor, requiere reescribir para adaptarse.
Un par de técnicas que encuentro útiles:
Si algo parece más complejo de lo que le gustaría, entonces nunca se siente a implementarlo tan pronto como haya terminado de pensar en ello. 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 con quien puede intercambiar ideas. ¡Asegúrate de explicarles por qué la complejidad está justificada!
Si agrega complejidad porque cree que se justificará en el futuro, intente establecer cuándo lo usará en el futuro. Si no puede (realistamente) imaginar que necesita la complejidad durante un año o tres, entonces probablemente no sea justificable pagar ahora.
Lea "Trabajar eficazmente con código heredado" de Michael C. Feathers.
El punto es que si tienes un código que funciona y necesitas cambiar el diseño, nada funciona mejor que hacer que tu unidad de código sea comprobable y dividir tu código en pedazos más pequeños.
Pregunto a mis clientes por qué 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.
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: simplifica hasta que sea fácil.
Si es demasiado difícil de probar, su diseño es demasiado complicado. Esa es la primera métrica que uso.
Tómese el tiempo para nombrar bien los conceptos del sistema y encuentre los 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).
Una vez que has sido programador, es inevitable que 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.
Usando Test Driven Development y siguiendo las Tres Reglas de TDD de Robert C. Martin:
- No está permitido escribir ningún código de producción a menos que sea para aprobar un pase de prueba de la unidad.
- No se le permite escribir más de una prueba unitaria que sea suficiente para fallar; y las fallas de compilación son fallas.
- No está permitido escribir ningún código de producción más de lo que es suficiente para pasar la prueba de falla de la unidad.
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.
La prueba primero puede ayudar aquí, pero no es adecuada para todas las situaciones. Y no es una panacea de todos modos.
Empezar 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.
Obtenlo revisado . 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.
Use lenguaje magra Los lenguajes como Java o, a 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 modo de pensar para favorecer la simplicidad, y para estar seguro de que la simplicidad es posible.
- Habla con otros programadores en cada paso del camino. Cuantos más ojos haya en el diseño, más probable es que un aspecto sobrecomplicado se revele antes de que se vuelva demasiado osificado en la base del código.
- Constantemente pregúntese cómo usará lo que sea que esté trabajando actualmente. Si la respuesta es que no está seguro, deténgase a repensar lo que está haciendo.
- Me ha resultado útil anotar pensamientos sobre cómo simplificar potencialmente algo en lo que estoy trabajando actualmente. De esa manera, una vez que realmente lo tengo funcionando, es más fácil regresar y refactorizar o rehacer según sea necesario en lugar de jugar con algo que aún no es funcional.