"О, великие принципы SOLID, благословите мой код на чистоту и ясность. Пусть функции мои будут едины в своей ответственности, как воины в строю, и не возьмут на себя бремя чужих забот. Пусть классы мои будут открыты для расширения, но закрыты для изменения, как крепость, стойкая против врага. Да не нарушит новый код работу старого! Пусть заменяются мои подтипы без нарушения порядка, как звенья одной цепи. Пусть интерфейсы будут разделены, как ветви дерева, и зависимости инверсированы, как отражение в зеркале. Пусть будет так, как завещал Мартин, и код мой будет чист, как ряса, как помыслы мои."
Все знают про канареечные релизы (canary deployment). Это когда новую версию сначала выкатывают на небольшую группу пользователей, чтобы проверить, не задохнется ли канарейка. Но что делать, когда нужно релизить много и регулярно? Тут нам на помощь приходят петушиные релизы!
Что такое петушиные релизы?
Петушиные релизы - это когда все обновления выкатываются рано утром, пока пользователи еще спят. Как петух, который встает с первыми лучами солнца, команда разработки поднимается засветло, чтобы подготовить свежую версию продукта к началу рабочего дня.
Преимущества подхода:
Более высокий когнитивный ресурс у инженера с утра - "утро вечера мудренее"
Минимальное влияние на пользователей (они еще спят)
Время на "настаивание" релиза перед началом активного использования
Возможность быстро откатиться, если что-то пошло не так
Предсказуемый график релизов
Возможность обновить все сервисы системы одновременно в тихий утренний час (даже если релиз не будет бесшовным, это вряд ли кто-то заметит - все полусонные)
Когда это особенно полезно?
Когда бизнесу нужны новые фичи "еще вчера"
При работе с микросервисной архитектурой
Когда команда распределена по разным часовым поясам
Исторический контекст
Как петухи исторически помогали людям вовремя просыпаться и спасали от пожаров своим криком, так и петушиные релизы помогают командам поддерживать здоровый баланс между скоростью доставки и стабильностью системы.
И помните: лучше регулярные петушиные релизы, чем ждать, пока жареный петух клюнет!
Позвольте представить вам концепцию эллинского подхода в архитектуре.
Она черпает вдохновение из древнегреческих устных традиций и философского подхода к обмену знаниями. Как известно, Сократ выступал против письменной фиксации философских идей, полагая, что письмо не может передать всю глубину и сложность мысли так, как это делает устное общение.
Вот некоторые потенциальные преимущества такого подхода в контексте программной архитектуры:
Личное взаимодействие: Устный обмен информацией подразумевает тесное общение, что может способствовать лучшему пониманию и командной работе.
Гибкость: Отсутствие строгой документации может сделать процесс более адаптивным и гибким.
Быстрое принятие решений: Устное общение обычно быстрее письменного, что может ускорить процесс принятия решений.
Фокус на главном: Отсутствие необходимости в документации может позволить команде сосредоточиться непосредственно на разработке.
Представьте, какими чудесными были бы наши рабочие встречи! Никаких утомительных записей - только живой диалог в лучших традициях античной Греции.
Однажды Диоген увидел, как разработчик читает требования и плачет, а слёзы смывают грязь с его лица. Диоген перестал ходить к реке умываться, сказав: «Мальчик превзошёл меня в простоте жизни».
В мире разработки программного обеспечения, как и в философии, существуют различные школы мысли, подходы и мировоззрения. Каждый архитектор и разработчик — осознанно или нет — следует определённым принципам, которые, для нужд этой статьи, удивительным образом перекликаются с древними философскими учениями. Давайте рассмотрим эти параллели.
Я нагуглил некоторое количество философских школ и спешу предложить вам такую аналогию:
Киники — просто и минималистично.
Платоники — невыносимо сложно и идеалистично.
Стоики — надёжно, но рано или поздно всё упадёт.
Софисты — красиво, но непрактично.
Прагматики — работает, и ладно.
Схоласты — бесконечные обсуждения архитектуры, но ни одной строчки кода.
Теперь давайте остановимся подробнее на каждой школе мысли.
Киники
«Зачем нам фреймворк? Есть же bash!»
Документация? «Читайте код».
CI/CD? git push --force решает все проблемы.
Docker? systemd нам в помощь.
Намеренно пишут неортодоксальный код, чтобы «встряхнуть» команду.
Проводят демонстрации багов прямо на проде.
Платоники
Реальный код — это лишь несовершенная тень идеального дизайна.
Каждый баг — это лишь тень несовершенства реального кода.
Нам нужен ещё один слой абстракции между абстракциями.
Простое решение не может быть правильным по определению.
В идеальном мире каждый метод — это интерфейс.
Настоящая архитектура существует только в UML-диаграммах.
Стоики
Падение прода неизбежно, а каждая ошибка может стать последней.
Стремление важнее результата — «Ничего не получилось, но мы сильно старались».
Никто не ощущает баги — о них только думают.
Не облекай свой код в пышные абстракции.
Люди пишут код с багами невольно.
Являюсь ли я частью проблемы или её решения?
Если вы слышите, как кто-то читает молитву о безмятежности, то перед вами стоик: «Боже, дай мне душевный покой принять тот код, который я не могу изменить, мужество изменить тот, что могу, и мудрость отличить одно от другого».
Софисты
Красота кода важнее его практичности.
На код-ревью больше обсуждают стиль, чем функциональность.
«Да, это медленнее работает, зато посмотрите, какая архитектура!»
Могут убедить заказчика, что баг — это фича.
На код-ревью побеждает не самый правый, а самый красноречивый.
Прагматики
«Работает? Не трогай. Не работает? Почини как можешь».
Документация? «Код сам себя документирует».
Архитектура — это то, что получилось в итоге.
Технический долг? «Будущие проблемы решим в будущем».
«Лучшее — враг хорошего, а рефакторинг — враг работающего».
Схоласты
Команда может месяцами обсуждать «идеальную архитектуру».
Создаются сложные диаграммы и документация.
Проводятся бесконечные митинги по дизайну.
Каждое решение требует согласования на архитектурном комитете.
Но реальный код так и не пишется.
Заключение
Возможно, главный урок, который мы можем извлечь из этой аналогии — это то, как много вокруг людей с неправильными подходами и мировоззрениями. Но не унывайте и помните мудрые слова Марка Аврелия:
Сегодня мне придётся столкнуться с людьми навязчивыми, неблагодарными, заносчивыми, коварными, завистливыми, неуживчивыми. Эти свойства проистекают от незнания ими добра и зла. Я же, познавший прекрасную природу добра и постыдную — зла, понимаю и природу тех, кто заблуждается.
Чему может научить сениора разработчика философ Диоген?
Древние греки были великими, и их мудрость помогает нам и по сей день. Возьмите к примеру Диогена. Рукоблудствуя на глазах у всех, он приговаривал: «Вот если бы голод можно было унять, потирая живот!».
И вот теперь на вопрос архитектора: «Антон, почему вы думаете, что это сложно сделать за неделю?», я могу ответить как философ: «Вот если бы задачу можно было решить, нарисовав стрелку на диаграмме».
