Ответ
Моё несогласие всегда должно быть конструктивным и основанным на фактах, а не на личных предпочтениях. Мой алгоритм:
- Глубоко разбираюсь в контексте. Я перечитываю требования (user story, спецификацию), изучаю реализацию и пытаюсь понять мотивы разработчика. Возможно, я что-то упустил.
-
Формулирую конкретные технические аргументы. Я не говорлю "мне не нравится". Я говорю: "Эта реализация может создать проблемы с тестируемостью/производительностью/безопасностью, потому что...". Например, если логика жёстко зашита в коде, а не вынесена в конфигурацию:
# Сложно тестировать разные сценарии if user.country == "Russia": tax = 20 # Магическое число в коде # Легче тестировать TAX_RATES = config.load("tax_rates") # Данные из конфига tax = TAX_RATES.get(user.country, 0) - Предлагаю альтернативу. Я прихожу не только с критикой, но и с готовым вариантом решения или даже прототипом.
- Обсуждаю в правильном формате. Я поднимаю вопрос во время ревью кода или на митинге по планированию, а не в общем чате. Излагаю свою позицию чётко и слушаю контраргументы.
- Принимаю финальное решение команды. Если после обсуждения команда (или тимлид/архитектор) принимает исходный вариант, я его принимаю. Моя задача — высказать профессиональное мнение, а не настоять на своём. После этого я убеждаюсь, что все риски, которые я увидел, покрыты тестами и задокументированы.