Martillo dorado

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 4 de abril de 2022; las comprobaciones requieren 4 ediciones .

Golden hammer ( eng.  Golden hammer ) es un anti- patrón de diseño, que consiste en usar la misma solución en todas partes, incluso ajustando artificialmente las condiciones, requisitos, restricciones del problema a una solución dada [1] .

También conocido como: La ley  del instrumento , Martillo de Maslow , Martillo .  Puede aparecer tanto a nivel gerencial [2] como a nivel de desarrolladores [3] , la esencia de esto no cambia.  

La esencia del antipatrón

Martillo dorado: confianza en la universalidad completa de cualquier solución y la aplicación de esta solución (por ejemplo, uno de los patrones de diseño en programación) a cualquier tarea. La propensión a utilizar el "martillo de oro" no depende de la experiencia del especialista.

Factores que contribuyen a la aparición del "martillo de oro" [4] :

• el equipo de desarrollo tiende a usar tecnología familiar;
• el equipo de desarrollo no está familiarizado con otras tecnologías de desarrollo;
• cambiar a otra tecnología está asociado con cierto riesgo;
• la tecnología familiar simplifica la planificación y evaluación del desarrollo;
• razones políticas, en particular, grandes inversiones ya destinadas a promover un producto o tecnología [3] ;
• confianza en las características de su propio producto, que no están disponibles en otros productos de la industria [3] .

Las consecuencias son:

• solución subóptima (incluso si se ve "agradable" desde el exterior);
• complicación innecesaria o simplificación inaceptable del sistema.

Señales y consecuencias de la aparición del martillo de oro [3] :

• se utilizan herramientas y tecnologías idénticas para una gran cantidad de productos conceptualmente diversos;
• las soluciones tienen un bajo rendimiento, escalabilidad , etc. en comparación con otras soluciones en la industria;
• la arquitectura del sistema se describe mejor mediante un producto específico, un paquete de aplicaciones o un conjunto de herramientas del proveedor;
• Los desarrolladores, al analizar los requisitos con analistas y usuarios finales, abogan por requisitos que se puedan adaptar con ciertas herramientas o eliminar de áreas donde no se aplican.
• los desarrolladores se aíslan de la industria. Demuestran una falta de conocimiento y experiencia con enfoques alternativos;
• los productos existentes dictan el diseño y la arquitectura del sistema;
• todos los nuevos desarrollos se basan en gran medida en el producto o la tecnología de un proveedor en particular.

Ejemplo: algunas empresas web continúan utilizando y manteniendo sistemas de almacenamiento en caché de desarrollo propio a pesar de la disponibilidad de alternativas de código abierto [4] .

Maneras de lidiar con el martillo dorado

Maneras de prevenir:

• Análisis de la disponibilidad de alternativas de solución, búsqueda y comparación de otras formas de solucionar el problema. Por ejemplo, los desarrolladores de software deben mantenerse al día con las tendencias tecnológicas actuales. Esto se aplica tanto directamente a los desarrolladores de software como a la administración. Una buena manera de mantener el intercambio de conocimientos sobre innovaciones técnicas es la práctica de organizar reuniones de discusión donde se discutirán nuevas tecnologías (patrones, estándares emergentes, nuevos productos) [3] .
• Creación de prototipos , comparando diferentes formas de resolver un problema dado, mediante la creación de prototipos.

Métodos de identificación: la falta de una colección de soluciones para diversas tareas por parte del gerente y la aparición de dificultades cuando surgen nuevas situaciones problemáticas, indica el surgimiento de un "martillo de oro" en el nivel gerencial [5] . Para identificar un martillo a nivel de desarrollador, debe usar la revisión de código ( revisión de código ing.  ): monitorear el código en el curso de la realización de la tarea e identificar soluciones no óptimas o que se repiten con frecuencia, analizando y comparando sus alternativas.

Remedios: la refactorización le permitirá optimizar el código eligiendo soluciones más adecuadas y arreglando las existentes.

Historia del término

La primera mención data de 1964 y pertenece a Abraham Kaplan.[6] :

Yo lo llamo La ley del instrumento): Dale un martillo a un niño pequeño y descubrirá que todo lo que lo rodea solo necesita ser golpeado.

Texto original  (inglés)[ mostrarocultar] Yo la llamo la ley del instrumento, y puede formularse de la siguiente manera: dale un martillo a un niño pequeño y descubrirá que todo lo que encuentra necesita ser golpeado. —Abraham Kaplan

Un concepto similar se llamó "Martillo de Maslow" en honor a Abraham Harold Maslow , quien escribió en 1966:

Creo que si tu única herramienta es un martillo, querrás ver algo como un clavo [7] .

Texto original  (inglés)[ mostrarocultar] Supongo que es tentador, si la única herramienta que tienes es un martillo, tratar todo como si fuera un clavo.

La expresión inglesa "un destornillador Birmingham" se refiere al hábito de usar una herramienta para todos los propósitos y es anterior a Kaplan y Maslow [8] . El concepto también se atribuye a Mark Twain , aunque no hay confirmación en el trabajo publicado de Twain [9] .

Excepciones notables

A veces, el antipatrón del martillo dorado funciona:

• si el producto que define las restricciones arquitectónicas es una decisión estratégica intencionada a largo plazo;
• si el producto es parte del paquete de un proveedor, para la mayoría de las necesidades de software .

Relación con otros patrones y antipatrones

• Silver Bullet ( en inglés  SilverBullet ) es un método universal hipotético en tecnología o técnica de gestión que aumenta el rendimiento, la confiabilidad y la simplicidad de un proyecto de software en un orden de magnitud [10] . Frederick Brooks demostró que no existe una bala de plata : ninguna innovación tecnológica u organizativa puede reducir fundamentalmente la complejidad inherente de un proyecto (es decir, la complejidad debida a la complejidad de la tarea en sí y otros factores inevitables). La "bala de plata" y el "martillo de oro" causan daño de diferentes maneras: si el "martillo" conduce directamente a consecuencias negativas, debido al desplazamiento de soluciones más exitosas, entonces la "bala" generalmente no dirige, pero daño indirecto por el hecho de que busca e intenta aplicar como resultado, se gastan más recursos de los que permite ahorrar.
• Dependencia de bloqueo del proveedor .  Los desarrolladores buscan activamente el apoyo de los proveedores para aplicar el martillo dorado. Todo el proyecto se basa en un único enfoque de herramienta/proveedor de tecnología en el desarrollo e implementación de productos [11] .

Véase también

• Panacea

Notas

1. ↑ Bulajic A., 2011 .
2. ↑ Laplante, 2005 , p. 71-73.
3. ↑ 1 2 3 4 5 Marrón, 1998 , pág. 62-63.
4. ↑ 1 2 Freeman E., 2011 , pág. 622-623.
5. ↑ Laplante, 2005 , p. 73.
6. ↑ Kaplan A., 1964 , págs. 28
7. ↑ Maslow AH, 1966 , págs. quince.
8. ↑ Verde J., 1985 .
9. ↑ MacQuade, 2006 .
10. ↑ Brooks F., 1986 .
11. ↑ Marrón, 1998 , pág. 64-65.

Literatura

• Miroshnichenko E. A. Tecnologías de programación . - Editorial de la Universidad Politécnica de Tomsk, 2008.
• Bulajic A. Patrones de diseño pasados ​​​​y futuros // Actas de la Conferencia de Educación de TI y Ciencias de la Información  (  InSITE). — 2011.
• Smith CU, Williams LG Software Performance AntiPatterns  //  2.º Taller internacional sobre software y rendimiento. — 2000.
• Maslow A. H. La Psicología de la Ciencia . - 1966. - ISBN 0-9760402-3-9 .
• Kaplan A. La conducta de la investigación: Metodología para la ciencia del comportamiento . - San Francisco: Chandler Publishing Co, 1964. - ISBN 0-7658-0448-4 .
• Verde, Jonathan. Diccionario de Argot. - Cassell, 1998. - ISBN 978-0304344352 .
• McQuade TJ Cognición y Economía. - Emerald Group Publishing, 2006. - 77 p.
• Allen E. Errores típicos de diseño. - Editorial "Pedro", 2003. - 224 p. — ISBN 5-887827-304-6 .
• Brooks F. No Silver Bullet: esencia y accidentes de la ingeniería de software. . -TPU, 1986.
• Freeman E., Freeman Al. Patrones de diseño. - Pedro, 2011. - 646 p.
• Marrón WH, Malveau RC Antipatrones. Refactorización de Software, Arquitecturas y Proyectos en Crisis. . - Robert Ipsen, 1998. - 157 p. — ISBN 0-471-19713-0 .
• Laplante PA, Neill CJ Antipatrones: identificación, refactorización y gestión. . - Publicaciones de Auerbach, 2005. - 333 p. — ISBN 0-8493-2994-9 .  (enlace no disponible)