refactoring - xiaoping - revolucion cultural china resumen corto
¿Cuándo llamar a la pandilla de los cuatro? (7)
En The Guerilla Guide to Interviewing, Joel dice que los tipos que quieren hacer las cosas, pero que no son inteligentes, harán cosas estúpidas, como usar un patrón de diseño de visitante en el que una matriz simple sea suficiente.
Me resulta difícil de detectar si se debe aplicar el patrón de diseño sugerido por Gang of Four .
Por lo tanto, quisiera algunos ejemplos de su experiencia laboral
- ¿Cuándo es suficiente un enfoque simple (matriz de tamaño fijo)?
- ¿Cuál es el tamaño mínimo de una pieza de software que justifica el uso de los patrones de GoF?
- ¿Cuándo refactorizar de simple a GoF? ¿Se puede hacer esto de una manera sensata?
Esto es similar a cualquier otra decisión de diseño. En última instancia, depende. Debes aprender los patrones que son útiles en tu lenguaje (muchos patrones GoF no son necesarios en Lisp o Smalltalk, por ejemplo), conocer sus ventajas y desventajas, comprender las limitaciones de tu sistema y elegir la que mejor se adapte a tus necesidades. .
El mejor consejo que puedo dar es aprender, aprender, aprender.
A menudo encuentro que usar el desarrollo impulsado por pruebas me ayuda a orientarme cuando me enfrento a estas preguntas.
- ¿Cuándo es suficiente un enfoque simple? Siempre es suficiente usar el enfoque más simple para pasar la próxima prueba. Pero saber cuándo / cómo refactorizar es la verdadera forma de arte.
- ¿Cuál es el tamaño mínimo de una pieza de software que justifica el uso de los patrones de GoF? Una regla general que una vez leí es que cuando codificas algo una vez, está bien, cuando duplicas ese código en alguna parte por segunda vez, tomas nota y sigas adelante. Cuando encuentra la necesidad del mismo código por tercera vez, es hora de refactorizar para eliminar la duplicación y simplificar, y a menudo eso implica pasar a un patrón de diseño.
- ¿Cuándo refactorizar de simple a GoF? Me gusta lo que dice @anopres: es hora de sentir el dolor de no tener el patrón de diseño en su lugar. El dolor (o el código "olor") puede manifestarse de varias maneras. La duplicación de código es la más obvia. Refacturando libros como Refactoring de Fowler o Refactoring to Patterns de Kerievsky enumeran muchos de esos puntos de dolor / hedores de código.
- ¿Puede esta [refactorización] hacerse de una manera sensata? El truco para la refactorización es contar con un conjunto de pruebas unitarias en las que tenga confianza y luego refactorizar sin que falle ninguna de esas pruebas. Refactorizar, por definición, no cambia la funcionalidad de su código. Por lo tanto, si sus pruebas continúan pasando, puede tener una muy buena sensación de que no rompió nada. Aunque puede ser difícil, realmente disfruto esta parte de TDD, es casi como un juego para hacer cambios sin romper ninguna prueba.
En resumen, diría que TDD me ayuda a escribir el código que es suficiente en ese momento, y quizás lo más importante es que me ayuda a hacer los cambios más tarde cuando inevitablemente cambian los requisitos, se requiere más funcionalidad, etc.
Cuando tienes un problema que resuelve uno de los patrones. El libro de GoF tiene una sección en cada capítulo que explica para qué tipos de escenarios es apropiado cada patrón. No debe analizar cada problema que tenga, luego busque qué patrón usar. Debe familiarizarse con los patrones para que aprenda a reconocer qué situaciones los necesitan.
El cambio de un enfoque simple a un patrón de diseño formal suele ser algo que ocurre con bastante naturalidad a medida que aumenta el problema en complejidad. La clave es familiarizarse lo suficiente con los patrones para que pueda reconocer el punto de inflexión y cambiar del enfoque simple al patrón de diseño cuando le brinde el mayor beneficio para el desarrollo actual y futuro.
Para un proyecto más grande y complejo, el punto de inflexión debería ser bastante temprano; en muchos casos, incluso antes de comenzar a codificar. Para proyectos más pequeños, puede permitirse esperar antes de decidir implementar un patrón.
Una de las mejores cosas que puede hacer para aumentar su capacidad de reconocer cuándo se debe utilizar un patrón es tomarse un tiempo después de completar un proyecto para examinar cuán complejo se ha vuelto su enfoque "simple". Si le hubiera tomado menos tiempo y esfuerzo implementar un patrón, o si el patrón aclararía lo que estaba tratando de hacer, puede archivar ese conocimiento para la próxima vez que encuentre un problema similar.
Los patrones son solo herramientas y vocabulario. Usted escribe el código para que sea tan simple, comprensible y fácil de mantener como usted sabe cómo hacerlo. Al conocer patrones, tiene más alternativas a su disposición, y tiene un lenguaje para analizar los pros y los contras del enfoque antes de implementarlo.
En cualquier caso, no solo "cambia" a "usando un patrón". Simplemente sigue haciendo lo que siempre haces, escribe el código de la mejor manera que sabes cómo hacerlo.
Una de las cosas buenas sobre el libro de GoF original es que hay una discusión de los escenarios donde el patrón resolvería mejor el problema. Revisar estas discusiones puede ayudarlo a determinar si "es el momento".
Otro buen lugar para comenzar es con Head First Design Patterns. Los ejercicios que ilustran el uso de diferentes patrones de diseño son lo suficientemente elaborados como para ofrecer una buena experiencia de aprendizaje. Además, los ejercicios también se basan en escenarios del mundo real, por lo que nunca es difícil ver cuándo es el momento adecuado para aplicar los patrones de diseño.
Los patrones de diseño son una consecuencia, no un objetivo. No crees que hoy usaré Patrones de estrategia , solo hazlo. A mitad de camino de hacer la tercera clase casi idéntica, deténgase y use una libreta de papel para descubrir el caso general y golpear una clase base que describa el contexto compartido. Usted refactoriza las dos primeras clases para que sean descendientes, y esto le da un control de la realidad y bastantes cambios en su clase base. Luego, los próximos treinta son un paseo por el parque.
Es solo al día siguiente en la reunión del equipo que salvas a todos treinta minutos de aburrimiento diciendo "Usé el patrón de estrategia. Todos funcionan igual, solo hay un programa de prueba, se necesitan parámetros para cambiar el caso de prueba".
La familiaridad íntima con los patrones hace que los uses reflexivamente, siempre que la situación lo exija. Cuando las personas tratan el uso de patrones como un objetivo en sí mismo, obtienes un código desagradable y feo que habla de mecanismo en lugar de propósito; el cómo y no el por qué
La mayoría de los patrones abordan problemas fundamentales recurrentes como la mitigación de la complejidad y la necesidad de proporcionar puntos de extensibilidad. Proporcionar puntos de extensibilidad cuando es evidente que no se necesitarán sin sentido complica su código y crea más puntos de falla y casos de prueba. A menos que esté construyendo un marco para la liberación en la naturaleza, resuelva solo los problemas que enfrenta.