Когда мы только начинаем свою карьеру в сфере разработки, легко представить программирование как чёрно-белую картину: есть «хороший» код и «плохой» код, а критерии оценки кажутся универсальными и неизменными. Однако опыт показывает, что в реальности всё гораздо сложнее: ваш подход к написанию кода — это нечто гибкое, зависящее от конкретных целей, сроков и даже настроения. Патрик Дуброй в своей статье «Five coding hats» предлагает интересную аналогию с «шляпами», которые мы «надеваем» в зависимости от обстоятельств. Мне эта идея кажется очень созвучной, и в этой статье я хочу поделиться, как я её вижу и дополняю собственными наблюдениями.
Несколько слов о концепции «шляп»
В своё время Эдвард де Боно предложил метод «Шесть шляп мышления», где каждая шляпа символизирует определённый тип умственной деятельности. Патрик Дуброй, опираясь на эту идею, рассказывает о пяти «программировочных шляпах» — каждая из них отражает особый стиль кодирования и настрой (mindset), с которым разработчик подходит к задаче. Ниже я рассмотрю их и добавлю свои комментарии, а также немного технических подробностей, которые, на мой взгляд, могут быть полезны на практике.
🏴☠️ Капитанская шляпа (Captain’s hat)
Когда нужно «идти строго по уставу», значит пора надевать капитанскую шляпу. Здесь вы делаете ставку на аккуратные, маленькие и безопасные изменения, обширное покрытие тестами, строгие ревью кода и подробные описания коммитов. Всё это необходимо, чтобы исключить риск серьёзных ошибок и максимально упростить откат изменений при необходимости.
Чем это может быть полезно на практике?
🦺 При критических апдейтах, если ошибка может затронуть тысячи (или миллионы) пользователей.
⚖️ Когда команда работает в жёстко регламентированном окружении (например, финтех или медицинское ПО).
⛵ При сложном непрерывном деплое (Continuous Deployment) — капитанский подход поможет избежать «штормов» в продакшене.
С технической точки зрения капитанская шляпа подразумевает:
- Интеграцию с CI/CD-пайплайном, строгие проверки качества (линтеры, статические анализаторы).
- Подробные отчёты о покрытии тестами, приоритет TDD (Test-Driven Development - Разработка через тестирование).
- Согласованность с код-ревьюерами, одобренные RFC (Requests for Comments - Запросы на комментарии) внутри команды.
🐕 «Босяцкая» шляпа (Scrappy hat)
В стартапах и при быстрых экспериментах почти все носят «босяцкую» шляпу — ориентир на «минимально жизнеспособный продукт» (MVP) и принцип «лучше сделать хоть как-то, чем не сделать вовсе». Тут никто особо не печётся о тестах или структурной красоте кода, главное — получить работающий прототип и проверить идею «на зуб».
Когда это оправдано?
🐾 При быстром создании прототипов и демоверсий.
⚡ Когда нужно доказать жизнеспособность концепции (POC — Proof of Concept - Доказательство концепции).
💡 При ранней стадии развития продукта, когда многое может кардинально поменяться.
Технически «босяцкая» шляпа предполагает:
- Минимум ритуалов: коммиты могут быть большими, без детального описания.
- Низкий приоритет рефакторинга и тестирования (прототип «однодневка»).
- Возможна работа в одиночку или в небольшой связке, без формальных процессов.
🛠️ Шляпа МакГайвера (MacGyver Hat)
Для «МакГайвер-подхода» главное — разузнать, «а получится ли вообще?». Это когда вы берёте подручные инструменты — может, баш-скрипты, протоколы на коленке, временные хаки — чтобы за час понять, имеет ли идея смысл, прежде чем тратить дни на чистовую реализацию.
Когда это особенно полезно?
🔧 При исследовательских задачах, особенно в области оптимизации производительности.
⚙️ Когда нужны несколько быстрых экспериментов, чтобы выбрать лучшее направление.
🪚 При интеграции разных систем: перед серьёзным внедрением хочется проверить, «склеиваются» ли они вообще.
Технически это может выглядеть так:
- Использование временных хардкодов и заглушек, чтобы проверить концепцию.
- Быстрый анализ логов и метрик, например, через ad-hoc скрипты (Python, Bash).
- При необходимости — сборка временного окружения (docker-compose с минимумом сервисов).
🧑🍳 Шляпа шеф-повара (Chef’s hat)
«Шеф» не только готовит блюдо (функциональность), но и старается подать его красиво. В программировании это означает особое внимание к чистоте, элегантности кода. Часто такой подход сводится к рефакторингу и шлифовке стиля: переименовать переменные так, чтобы читались «как книга», разбить логику на осмысленные модули, добавить грамотные комментарии.
Когда это действительно нужно?
🍲 При работе над публичным API или библиотекой, которую будут читать и использовать другие.
✨ При подготовке «витринного» кода (например, для презентаций или конкурсов).
🧽 Когда есть немного свободного времени в спринте, и вы хотите сформировать идеальный код.
Однако важно не увлечься «полировкой»: бывает, что «шеф» готовит так долго и старательно, что блюдо (код) устаревает ещё до подачи в продакшен.
Технические детали могут включать:
- Применение инструментов форматирования (Prettier, Black и т. д.).
- Создание подробных комментариев или документации в стиле Doxygen, JSDoc.
- Использование шаблонов проектирования и «чистой» архитектуры.
🧑🏫 Учительская шляпа (Teacher’s hat)
В этом режиме код становится средством обучения, а не просто решения задачи. Иногда мы пишем учебные примеры для статьи, репозитория или документации, где не так важна производительность или обработка ошибок, зато критичны понятность и наглядность.
Где применять?
📚 В обучающих материалах и инструкциях (GitHub, документация, мастер-классы).
🏫 При написании демо-программ, объясняющих какую-то концепцию новичкам.
🪄 В постах о технологиях, где ключевое — продемонстрировать идею, а не закрыть все крайние случаи (edge cases).
Технические аспекты:
- Меньше технического «шума» (отсутствие сложной логики обработки ошибок).
- Дополнительные комментарии, описывающие каждое нетривиальное действие.
- Возможно, демонстрация нескольких решений одной задачи для разных уровней разработчиков.
Личный взгляд: можно ли совмещать «шляпы»?
На мой взгляд, главная сила этого подхода — возможность гибко переключаться. Я часто начинаю разработку новой фичи «босяцкой» шляпой, делая быстрый прототип. Если вижу, что идея жизнеспособна, в дело вступает «МакГайвер», чтобы проверить производительность или различные варианты реализации. А когда всё устаканилось, и продукт пошёл в продакшен, я надеваю «капитанскую» шляпу, чтобы всё протестировать и оформить по правилам.
Иногда к завершению цикла хочется слегка «прокачать» код для будущих поколений разработчиков — тогда в ход идёт «шеф» или «учитель». Ведь красиво написанный и понятный код не только радость глазам, но и реальная помощь тем, кто будет поддерживать проект.
Почему это здорово для командной работы?
Очень полезно, если вся команда понимает, в каком «режиме» сейчас идёт работа. Иногда споры возникают из-за того, что один разработчик в «капитанском» настрое, а другой — «босяцком». Первый кричит: «Где тесты? Где описание коммитов?», а второй недоумевает: «Зачем это всё, если я просто пробую идею?». Открытый диалог о том, какую «шляпу» мы все носим в данный момент, снимает кучу недопонимания и помогает лучше распределять усилия.
🤖 Технические детали при переключении стилей
Чтобы эффективно менять «шляпы» на практике, можно:
- Иметь несколько веток (branch) в репозитории. Например, prototype-branch для «босяцких» экспериментов и stable-branch для «капитанской» стабильности.
- Использовать feature toggles (флаги функционала), позволяющие отключать сырой код в продакшене.
- Настроить разные пайплайны в CI: быстрый и упрощённый — для прототипов, и основательный — для ключевых компонентов.
Заключение
Код — это не только инструкции для машины, но и отражение нашей разработческой культуры. Разные ситуации требуют разных подходов, и нет одной «золотой шляпы», которая подойдёт под любой проект. Пробуйте, экспериментируйте, не бойтесь «менять головные уборы» и ищите баланс между скоростью, безопасностью и красотой реализации.
Ссылка на оригинальную статью
Надеюсь, эта статья вдохновит вас на осознанный выбор «шляпы» в каждом новом проекте. Удачного кодинга!