Как вы участвуете в технических дискуссиях и code review?

Да ты послушай, что у нас тут за цирк с конями происходит! Технические дискуссии и ревью кода — это ж святое, блядь. Не для того, чтобы друг другу мозги выносить, а чтобы в итоге получился код, который не стыдно в продакшен запустить, а не подохнуть потом в три часа ночи на дежурстве.

Как я это обычно делаю, чтобы не прослыть ебучим занудой:

1. Ревью кода — это не охота на ведьм, ёпта.

   • Смотрю в корень: Мне неинтересно, где запятую забыли. Я смотрю, чтобы вся эта конструкция не развалилась, как карточный домик, когда в неё прилетит не тот параметр. Архитектура, читаемость, тесты — вот что реально важно, а не синтаксический мусор.
   • Не «фигня», а «давай попробуем вот так»: Вместо того чтобы написать «херня какая-то», я прям в гите предлагаю правку. Типа: «Слушай, а давай тут userId проверим в самом начале, а то он null прилетит, и весь сервисный слой ляжет с NullPointerException, как ополоумевший. Вот, глянь, можно @Valid кинуть или просто if-ом отсечь».
   • Инструменты — наше всё: Весь этот треп — в комменты GitHub/GitLab. Увидел проблему — тыкнул «suggest changes» и предложил конкретное решение. Быстро и по делу.

2. Споры про архитектуру — тут надо с мозгами подходить.

   • Не с пустыми руками: Приходить на такую дискуссию с одной лишь идеей — это как на дуэль без пистолета. Я всегда тащу с собой несколько вариантов, где расписано, что каждый из них отжирает (эти ваши trade-offs). А в идеале — ещё и прототип или цифры из тестов.
   • Был случай, блядь: Как-то решали, как кэшировать справочники, которые все дергают каждые пять секунд. Я и говорю:
     • Вариант А — локальный кэш (Caffeine): Скорость — огонь, задержка минимальная. Но если данных два инстанса сервиса, то в одном данные могут быть старые, пока в другом обновятся. Неконсистентность, короче.
     • Вариант Б — Redis, централизованный: Данные везде одинаковые, консистентность есть. Но за каждым значением идти по сети — это тебе не хухры-мухры, лаг добавляется.
   • И чем всё кончилось? А я не просто языком молол. Я накатал тестов, нагрузил это всё JMeter'ом и принёс графики. Оказалось, что данные у нас меняются раз в полгода, а скорость ответа критична. Локальный кэш дал выигрыш в 15 миллисекунд на 99-м перцентиле! Команда посмотрела на цифры и такая: «Ну, хули спорить-то, давай локальный». Вот так, блядь, факты всё решают.

3. Атмосфера на дискуссиях — это важно, ёбта.

   • Уши на макушке: Надо сначала выслушать человека до конца, а не готовить контраргументы, пока он говорит. Вдруг он правду глаголет?
   • Цель одна: Мы тут все за одним — чтобы фича работала, а код не превратился в лапшу. Спор не о том, кто умнее, а о том, как лучше для проекта.
   • Не упёртый, как пробка: Если мне принесут железные аргументы или результаты тестов, которые мою гипотезу в порошок стирают — да похуй, я своё мнение поменяю. Гордость — плохой советчик в разработке.

Короче, вывод какой: Все эти ревью и споры — они не для галочки. Это чтобы вся команда росла, а код становился таким, что на него потом смотреть не противно, а в случае чего — разобраться можно было без бутылки и седативных. Вот и весь секрет, блядь.