Как действуешь, если не согласен с реализацией фичи?

«Как действуешь, если не согласен с реализацией фичи?» — вопрос из категории Софт-скиллы, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый пример ответа, который можно адаптировать под свой опыт.

Ответ

Моё несогласие всегда должно быть конструктивным и основанным на фактах, а не на личных предпочтениях. Мой алгоритм:

  1. Глубоко разбираюсь в контексте. Я перечитываю требования (user story, спецификацию), изучаю реализацию и пытаюсь понять мотивы разработчика. Возможно, я что-то упустил.
  2. Формулирую конкретные технические аргументы. Я не говорлю "мне не нравится". Я говорю: "Эта реализация может создать проблемы с тестируемостью/производительностью/безопасностью, потому что...". Например, если логика жёстко зашита в коде, а не вынесена в конфигурацию:

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