Ответ
Мой подход зависит от масштаба и влияния решения. Я разделяю их на несколько уровней:
-
1. Локальные решения (в рамках одной задачи):
- Процесс: Принимаю самостоятельно, основываясь на лучших практиках и стандартах кодирования команды.
- Согласование: Происходит на этапе Code Review. Коллеги проверяют корректность и оптимальность выбранного подхода.
-
2. Командные решения (влияют на архитектуру сервиса/модуля):
- Процесс:
- Формулирую проблему и предлагаю 1-2 варианта решения в виде небольшого документа (Design Doc или ADR - Architecture Decision Record).
- Выношу на обсуждение с командой (тимлидом и другими разработчиками).
- Обсуждаем плюсы и минусы каждого подхода, выбираем оптимальный.
- Согласование: Решение фиксируется в Confluence или в репозитории в виде ADR, чтобы к нему можно было вернуться в будущем.
- Процесс:
-
3. Кросс-командные и глобальные архитектурные решения:
- Процесс: Здесь требуется более формальный подход. Я инициирую встречу с участием всех заинтересованных сторон.
- Согласование:
- С Тимлидом/CTO для утверждения архитектурной части.
- С Продукт-менеджером для валидации соответствия бизнес-требованиям.
- С лидами смежных команд (например, Frontend, DevOps), если решение их затрагивает.
В любом случае, я стремлюсь к балансу между скоростью принятия решений и их качеством, предпочитая открытое обсуждение и коллективную ответственность за результат.
Ответ 18+ 🔞
Да ты послушай, как у нас тут с решениями-то всё устроено, это ж целая наука, блядь! Не просто так пальцем в небо ткнуть. Смотри, я тебе по полочкам разложу, как я этот цирк организую.
Ну, во-первых, есть решения, которые по масштабу — как муха на стене. Локальные, короче. Допустим, надо мне какой-нибудь helper написать или в существующем сервисе хуйню поправить.
- Как решаю: Сам, блядь. Беру, смотрю на лучшие практики, на то, как у нас в команде принято, и делаю. Не царское это дело каждый чих согласовывать.
- Где меня проверяют: А вот тут-то и начинается веселье, на Code Review! Присылаю пул-реквест, а коллеги уже там: «А че так? А может этак? О, тут можно оптимизировать, ёпта!». Здорово же, все при делах, и я не накосячил где-то втихаря.
А теперь, внимание, второй уровень — командные решения. Это когда уже не просто код, а архитектура какого-нибудь модуля под угрозой, или новый сервис городить. Тут уже одному мозгов может не хватить, или, что хуже, накосячить можно на овердохуища.
- Как решаю: О, тут уже процесс, блядь! Я не просто делаю, а сначала сажусь и пишу короткий документик. Типа «Вот проблема, вот два варианта, как её решить — один с костылями, но быстро, другой красивый, но дольше». Называться это может Design Doc или ADR (Architecture Decision Record), если по-умному.
- Где согласовываем: Выношу это всё на обсуждение команде. Собираемся, и начинается: «А давайте вот так! — Не, так хуёво, потому что... — А если эдак?». Спорим, ругаемся, находим консенсус. Потом это решение, как приговор, записываем в Confluence или прямо в репозиторий, чтобы через полгода не орать: «Кто, блядь, это придумал?!» — а просто открыть записку и всё понять.
Ну и апогей всего этого бардака — решения кросс-командные или глобальные. Это когда твоя идея может потянуть за собой пол-компании, или отъебёт коллег из другого отдела. Тут уже не просто митинг, а целый съезд народных депутатов, ёпта!
- Как решаю: Формально, блядь, очень формально. Инициирую встречу, куда зову ВСЕХ, кого это может ебнуть.
- С кем согласовываю:
- С тимлидом или CTO — чтобы архитектурно не налажать, а то потом «сам дурак» не прокатит.
- С продукт-менеджером — а то сделаешь красоту, а он: «Это ни хуя не решает проблему пользователя, идиот!».
- С лидами других команд (фронтенда, девопса) — чтобы они потом не пришли с вилами: «Ты чего, сука, нам работу на месяц подбросил своим «гениальным» решением?!».
И знаешь, в чём главный фокус-покус? Найти, блядь, баланс. Чтобы не тормозить всё в попытках угодить всем и согласовать каждую запятую, но и не нестись сломя голову, как охуевший, создавая монстров, которых потом всем миром расхлёбывать. Открытое обсуждение, коллективная ответственность — вот наш девиз. А иначе — пиши пропало, проекту пиздец.