Золотой молоток
Золото́й молото́к (англ. Golden hammer) — антипаттерн проектирования, заключающийся в использовании одного и того же решения везде, в том числе путём искусственной подгонки условий, требований, ограничений задачи под данное решение[1].
Также известен под названиями: закон инструмента (англ. The law of the instrument), молоток Маслоу (англ. Maslow's hammer), «молоточек» (англ. gavel). Может появляться как на управленческом уровне[2], так и на уровне разработчиков[3], суть от этого не меняется.
Суть антипаттерна
правитьЗолотой молоток — уверенность в полной универсальности какого-либо решения и применение этого решения (например, одного из паттернов проектирования в программировании) к любым задачам. Склонность к использованию «золотого молотка» не зависит от опыта специалиста.
Факторы, способствующие появлению «золотого молотка»[4]:
- группа разработчиков стремится использовать знакомую технологию;
- группа разработчиков не знакома с другими технологиями разработки;
- переход на другую технологию сопряжён с определённым риском;
- знакомая технология упрощает планирование и оценку разработки;
- политические причины, в частности, большие инвестиции, уже направленные на раскрутку продукта или технологии[3];
- уверенность в характеристиках собственного продукта, которые не доступны у других продуктов отрасли[3].
Следствиями являются:
- неоптимальное решение (даже если снаружи оно выглядит «красиво»);
- ненужное усложнение или недопустимое упрощение системы.
Признаки и последствия появления золотого молотка[3]:
- идентичные инструменты и технологии используются для огромного количества концептуально разнообразных продуктов;
- решения имеют низкую производительность, масштабируемость и т. д. в сравнении с другими решениями в отрасли;
- архитектура системы лучше всего описана определённым продуктом, пакетом приложений или комплектом инструментальных средств поставщика;
- разработчики, обсуждая требования с аналитиками и конечными пользователями, защищают требования, которые можно приспособить с помощью определённых инструментов или увести их от областей, где они не применимы;
- разработчики становятся изолированными от отрасли. Они демонстрируют отсутствие знаний и опыта работы с альтернативными подходами;
- существующие продукты диктуют дизайн и архитектуру системы;
- все новые разработки основываются в большой степени на определённом продукте или технологии поставщика.
Пример: некоторые веб-компании продолжают использовать и поддерживать самостоятельно разработанные системы кэширования, несмотря на наличие альтернативных решений с открытым кодом[4].
Способы борьбы с золотым молотком
правитьСпособы предотвращения:
- Анализ наличия альтернативных решений, поиск и сравнение других способов решения поставленной задачи. Например разработчики программного обеспечения должны следить за современными технологическими тенденциями. Это касается как и непосредственно разработчиков ПО, так и управляющего менеджмента. Хорошим способом поддержания обмена знаниями о технических новинках, является практика организации дискуссионных совещаний, на которых будут обсуждаться новые технологии (шаблоны, появляющиеся стандарты, новые продукты)[3].
- Прототипирование, сравнение различных способов решения поставленной задачи, путём создания прототипов.
Способы идентификации — отсутствие у менеджера сборника решений для различных задач и появление трудностей при возникновении новых проблемных ситуаций, говорит о появлении «золотого молотка» на управленческом уровне[5]. Для выявления молотка на уровне разработчиков следует использовать просмотр кода (англ. Code review) — мониторинг кода в ходе выполнения поставленной задачи и выявление неоптимальных либо часто повторяющихся решений, анализ и сравнение их альтернатив.
Способы устранения — рефакторинг, позволит оптимизировать код, выбором более подходящих решений и исправлением уже имеющихся.
История термина
правитьПервое упоминание датировано 1964 годом и принадлежит Абрахаму Каплану[англ.][6]:
Я называю это «закон инструмента» (The law of the instrument[англ.]): Дайте маленькому мальчику молоток, и он обнаружит, что по всем окружающим предметам просто необходимо стукнуть.
Оригинальный текст (англ.)I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.— А́брахам Капла́н
Сходная концепция получила название «Молоток Маслоу» по имени Абрахама Харольда Маслоу, который в 1966 году написал:
Я думаю, что если твоим единственным инструментом является молоток, то на что угодно хочется смотреть как на гвоздь[7].
Оригинальный текст (англ.)I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
Английское выражение «a Birmingham screwdriver» («Бирмингемская отвёртка») ссылается на привычку использовать один инструмент для всех целей, и предшествует Каплану и Маслоу[8]. Концепцию также приписывают Марку Твену, хотя нет никаких подтверждений в опубликованных работах Твена[9].
Связь с другими паттернами и антипаттернами
править- Серебряная пуля (англ. silver bullet) — гипотетический универсальный метод в технологии или управленческой технике, увеличивающий на порядок производительность, надёжность и простоту программного проекта[10]. Фредерик Брукс показал, что серебряной пули не существует: никакое технологическое или организационное новшество в принципе не способно радикально снизить имманентную сложность проекта (то есть сложность, обусловленную сложностью самой задачи и другими неустранимыми факторами). «Серебряная пуля» и «золотой молоток» причиняют вред по-разному: если «молоток» приводит к отрицательным последствиям непосредственно, в силу вытеснения им более удачных решений, то «пуля» обычно наносит не прямой, а косвенный вред тем, что на её поиски и попытки применения в итоге затрачивается больше ресурсов, чем она даёт возможность сэкономить.
- Зависимость от поставщика (англ. vendor lock−in). Разработчики активно получают поддержку поставщика в применении «золотого молотка». Весь проект полагается на подход единственного поставщика инструментов/технологий в разработке и реализации продукта[11].
См. также
правитьПримечания
править- ↑ Bulajic A., 2011.
- ↑ Laplante, 2005, с. 71—73.
- ↑ 1 2 3 4 5 Brown, 1998, p. 62—63.
- ↑ 1 2 Фримен Э., 2011, с. 622—623.
- ↑ Laplante, 2005, с. 73.
- ↑ Kaplan A., 1964, pp. 28.
- ↑ Maslow A.H., 1966, pp. 15.
- ↑ Green J., 1998.
- ↑ McQuade, 2007.
- ↑ Brooks F., 1986.
- ↑ Brown, 1998, p. 64—65.
Литература
править- Мирошниченко Е. А. Технологии программирования. — Изд-во Томского политехнического университета, 2008.
- Bulajic A. Design Patterns Past and Future (англ.) // Proceedings of Informing Science & IT Education Conference (InSITE). — 2011.
- Smith C. U., Williams L. G. Software Performance AntiPatterns (англ.) // 2nd International Workshop on Software and Performance. — 2000.
- Maslow A. H. The Psychology of Science. — 1966. — ISBN 0-9760402-3-9.
- Kaplan A. The Conduct of Inquiry: Methodology for Behavioral Science. — San Francisco: Chandler Publishing Co, 1964. — ISBN 0-7658-0448-4.
- Green, Jonathon. Dictionary of Slang. — Cassell, 1998. — ISBN 978-0304344352.
- McQuade T. J. Science and market as adaptive classifying systems // Cognition and Economics / E. Krecké, C. Krecké, R. G. Koppl. — Elsevier, 2007. — P. 77. — 284 p. — ISBN 978-0-7623-1378-5. — ISBN 0-7623-1378-1.
- Аллен Э. Типичные ошибки проектирования. — Издательский дом «Питер», 2003. — 224 с. — ISBN 5-887827-304-6.
- Brooks F. No Silver Bullet — Essence and Accidents of Software Engineering.. — ТПУ, 1986.
- Фримен Э., Фримен Эл. Паттерны проектирования. — Питер, 2011. — 646 с.
- Brown W. H., Malveau R. C. AntiPatterns. Refactoring Software, Architectures, and Projects in Crisis.. — Robert Ipsen, 1998. — 157 с. — ISBN 0-471-19713-0.
- Laplante P. A., Neill C. J. Antipatterns: Identification, Refactoring and Management.. — Auerbach Publications, 2005. — 333 с. — ISBN 0-8493-2994-9. (недоступная ссылка)