Антипаттерн "Золотой молоток" - что это такое и почему его лучше избегать

В различных сферах разработки существует множество устоявшихся антипаттернов, но некоторые из них по настоящему можно понять только по мере достижения определенного профессионального опыта. Т.е. то, что по неопытности вам вначале кажется как "вау, это же отличное решение!", потом по мере получения горького опыта превращается в "ну нафиг, лучше избегать этого". И как-раз одним из таких примеров, является антипаттерн "Золотой Молоток".

Что за антипаттерн "Золотой Молоток"?

Золотой молоток (англ. "Golden Hammer", он же Закон инструмента, Молоток Маслоу и пр.) — антипаттерн, заключающийся в фанатичном использовании одного и того же решения везде, где возможно. Лучше всего смысл золотого молотка передает следующее высказывание:

«Я предполагаю, что если единственный инструмент, который вы имеете — молоток, то заманчиво рассматривать всё как гвозди» - А.Маслоу

Некоторые могут спутать Золотой молоток с типичным консервативным подходом, что в корне неверно. Суть в том, что при любом нормальном подходе (новаторском, консервативном и пр.), вначале изучается "задача", а уже затем подбирается подходящий "инструмент". В случае Золотого молотка, вначале берется именно "инструмент" и уже под него как-то подгоняется "задача", при этом все неподошедшие нюансы зачастую как-бы тихонько забываются или уходят в тех. долг (типа "разберемся со всеми нюансами когда-нибудь потом..."), а в абсурдных случаях вообще сама задача официально обьявляется какой-то неправильной.

Примеры проявления этого антипаттерна из личного опыта в IT

Сразу хочу выделить отдельным моментом деструктивное влияние этого антипаттерна в различных учебных заведениях, при обучении будущих программистов. Чтобы было понятно о чем идет речь, приведу один печальный пример из собственного опыта.

Когда я учился в ВУЗе, у нас был преподаватель (профессор!), который очень любил Microsoft Access и требовал использовать его во всех лабораторных, курсовых и дипломных работах. Причем упор делался даже не на SQL, а именно на инструментарий MS Access. Т.к. на практике это требование было просто безумным, да и преподавателя этого небыло в комиссии на защите диплома, то все просто проигнорировали это требование и разумно использовали более подходящие под задачи SQLite, MySQL/MariaDB, PostgreSQL и пр.

Данная ситуация является типовым примером золотого молотка, когда преподаватель может быть вполне неплохим, но он когда-то искренне уверовал, что Access является универсальным инструментом (его Золотой Молоток!) для всех задач и авторитетно стал навязывать всем, даже в тех случаях, когда это абсолютно неуместно. Т.е. вместо того, чтобы студент, как будущий специалист, получил возможность в дипломной работе проявить себя и самостоятельно подобрал бы подходящую под задачу СУБД, он вынужден как угодно натянуть саму задачу под использование MS Access. И самое печальное видеть то, что при этом студент вполне понимает весь дибилизм ситуации, но сделать ничего не может и в итоге появляется разочарование в обучении, пропадает интерес к программированию, да и вообще ко всей сфере разработки.

Но вернемся к практической разработке, где этот антипаттерн встречается очень часто. Как бы странно не звучало, но прям наиболее частое проявление этого антипаттерна я встречал почему-то именно у Java-разработчиков. Может конечно это мне так не везло, но многие из них уверенно пытались решать задачи только с помощью Java, даже в тех случаях, когда это решение выглядело просто безумно и кошмарно, при этом обязательно не забывая высокомерно смотреть на другие более подходящие языки программирования.

Встречал и безумные попытки писать фронтенд приложения чисто на Java, через трансляцию Java кода в Typescript с помощью какой-то заброшенной малоизвестной утилиты... Или разработка простейшей сайт-визитки (коммерческий проект!), на той же Java, с уверенностью считая, что зато все будет безопасно, при этом даже не задумываясь о том, что потом клиенту надо будет искать редких и дорогих специалистов, готовых разобраться в малоизвестной системе и внести необходимые правки на сайт. И это обращаю внимание, мне еще попадались люди, которые работали в типовом кровавом энтерпрайзе (конкретно, банковский сектор) на серьезных должностях.

Конечно помимо Java могу вспомнить множество других случаев из других сфер разработки, например той же веб-разработки, в которой программисты сплошь и рядом помешаны на JavaScript, даже там, где он нафиг не нужен. Но это можно долго рассказывать, я же всего лишь хотел привести несколько примеров для наглядности.

При этом скажу честно, все эти люди, про которых я упомянул, так или иначе являлись неплохими разработчиками. Просто по мере своего профессионального развития, они в какой-то момент, незаметно для себя, попались в ловушку Золотого молотка. И такое вполне бывает, каждый ошибается, ибо не ошибается тот, кто ничего не делает. Просто на эту проблему нужно явно обратить внимание и разобраться с тем, как бороться с этим ужасным золотым молотком.

Как можно избежать этот антипаттерн и причем тут "зона комфорта"

Одним из ключевых моментов является понимание того, что антипаттерн "Золотой Молоток" имеет свойство коварно и незаметно привести разработчика в ложное чувство зоны комфорта отдельных технологий. Но не обманывайтесь, дамы и господа!

Ну сами посудите, вот сидит на проекте такой супер-крутой разработчик, отлично знающий какой-нибудь Python и тот же Django, ну прям суперзвезда всего программирования. Ему комфортно, ибо профессиональной репутации "супер-пупер-звездного-мега-синьор-разработчика" ничего не угрожает, он авторитетен, его значимость для проекта высокая, ну и соответственно есть возможность требовать для себя всех материальных благ (деньги!) из проекта. В своем стеке технологий, он одним своим супер-синьорным взглядом может превратить любого мидл-разработчика в ничтожного джуниора, сломив его жалкие знания.

Но потом вдруг выясняется, что окружающий мир как назло непостоянен и этот разработчик по воле судьбы может оказаться в проекте, где Python не совсем подходит и тогда такой зазвездившийся разработчик может начать саботировать использование другой технологии, побоявшись лишиться авторитета и статуса "супер-пупер-звездного-мега-синьор-разработчика", со всеми материальными плюшками.

И вот исходя из вышеописанного момента, мы должны вспомнить часто повторяемые слова про то, что хороший программист должен постоянно учиться. Именно постоянное расширение профессионального кругозора и изучение (постоянное!) новых технологий, методик, подходов, альтернативных решений и пр. позволит научиться избегать золотого молотка, а также не даст вам профессионально "закостенеть" сидя в одном и том же стеке технологий.

«Чем больше я знаю, тем больше я понимаю, что ничего не знаю» - Сократ

Например, вам очень нравится использовать JavaScript, но в какой-то момент вы сталкиваетесь с очень ресурсоемкой задачей со сложной организацией многопоточности при ограниченности ресурсов. Вы конечно можете можете возиться с JIT, воркерами, уродливыми псевдооптимизациями и пр., но в какой-то момент вам будет проще выделить эту ресурсоемкую задачу в отдельную программу/библиотеку/сервис с использованием более подходящего языка, как например Golang. Ну или если вы пишете какую-то уберсложную суперсистему на C++, то вы вполне можете для упрощения и удобства, вынести высокоуровневый функционал в более простой и встраиваемый язык Lua или тот же Python.

Ну и чисто на мой взгляд немаловажную роль играет совокупность факторов среди ЛПР (лицо принимающее решение) проекта:

• широта профессионального опыта — без этого ЛПР опасаясь за свою репутацию будет бояться выходить из "зоны комфорта" единственной известной ему технологии.
• личная выгода за отличный результат — ну тут все просто, ибо какой смысл ЛПР тратить свои силы, чтобы делать что-то качественно, если для него нет никакой выгоды от этого.
• личная ответственность за плохой результат — с этим пунктом надо быть очень осторожным, но он очень важен, поскольку личная ответственность постоянно вынуждает критично относиться к выбранному стеку технологий и в случае золотого молотка действует отрезвляюще.

Еще раз обращаю ваше внимание на то, что все эти пункты должны рассматриваться только в совокупности. В любом другом случае, ЛПР в своей работе скорее всего тупо пойдет по пути наименьшего для себя сопротивления и будет принимать решения, которые наиболее проще лично для него, а на все остальное будет пофиг. Я думаю, многие неоднократно сталкивались с такими случаями в повседневной жизни и видели, к чему это обычно приводит.

Заключение

Уверен, многие вспомнят немало случаев, когда они сталкивались с этим антипаттерном вокруг себя. Но, давайте зададимся вопросом, а многие ли честно согласятся признать то, что сами злоупотребляли этим самым "Золотым молотком"?

Вот лично я, где-то по незнанию, где-то по неопытности, но чаще тупо из-за слепой гордости и самоуверенности, немало раз приходил к этому антипаттерну, что впоследующем приводило к негативным результатам, о которых я потом неоднократно пожалел. И только значительно позднее, по мере накопления опыта и увеличении личной ответственности за общий итоговый результат, я стал понастоящему понимать, насколько же коварный и вредный этот антипаттерн. Но таков уж мой опыт и лучше прийти к таким знаниям поздно, чем никогда.

В итоге хочу посоветовать вам максимально избегать ситуации Золотого Молотка, критично относится к принимаемым решениям в проекте, делать постоянный внешний контроль своих знаний и решений (с обратной связью!), ну и постоянно развивать и расширять свои познания. Помните, что программисты должны всегда учиться.