Что будешь делать если коллега предложит плохую идею

Как реагировать на плохую идею от коллеги

Главный принцип

Профессионализм, уважение и конструктивность. Моя задача — помочь команде принять лучшее решение, не унижая коллегу. Я прошёл через много code reviews, и мой опыт показал, что тон гораздо важнее содержания.

Мой подход

Шаг 1: Перед тем как судить, вслушиваюсь

Коллега: "Давай хранить пароли в логах для отладки"

Моя первая реакция: "Это плохо!" ❌
Правильная реакция: Задать вопросы

// Вопросы, которые помогут мне понять намерение:
// 1. "Почему ты думаешь, это нужно?"
// 2. "Какую проблему это решает?"
// 3. "Чем это лучше текущего подхода?"

Очень часто "плохая идея" на самом деле решает реальную проблему, которую я не видел.

Шаг 2: Объясняю причины, а не просто критикую

❌ Плохо:
"Это плохая идея, так не делают"
"Это нарушает security"

✅ Хорошо:
"Понимаю, что ты хочешь логировать для отладки. Но есть проблемы:
- Пароли в plaintext в логах — security риск
- Log files могут быть украдены/скомпрометированы
- Нарушает PCI DSS compliance

Вместо этого можно:
1. Логировать хеш пароля
2. Использовать debug mode без production
3. Добавить masking для sensitive fields

Это даст тебе отладку БЕЗ рисков"

Практические сценарии из моего опыта

Сценарий 1: Предложили использовать static method для всего

// Коллега предложил:
public class UserUtil {
    public static User createUser(String name) { ... }
    public static void saveUser(User user) { ... }
    public static User getUser(Long id) { ... }
    public static void deleteUser(Long id) { ... }
}

// Мой подход (из опыта):
// 1. Слушаю его аргументы
// 2. Согласен, что static может быть удобнее на первый взгляд
// 3. Но объясняю проблемы:

"Я вижу, что хочешь избежать создания объектов класса.
Но есть пара проблем:

1. Тестируемость:
public class UserServiceTest {
    @Test
    public void testCreateUser() {
        // Как замокировать static метод? Очень сложно.
        // Придётся использовать PowerMock, что slow и fragile
    }
}

2. Dependency Injection:
Если UserUtil будет использовать DB, он не сможет
брать зависимость через конструктор.

3. Разделение ответственности:
UserService — бизнес логика
UserRepository — доступ к БД
UserController — HTTP слой

Это гораздо лучше, чем один huge static класс.

Вариант: если это просто утилиты, то
public final class UserUtils {
    private UserUtils() { }  // Нельзя инстанцировать
    public static String hashPassword(String pwd) { }
}

Но для сервисов — давай использовать объекты."

Сценарий 2: Предложили не писать тесты

Коллега: "Давай не писать тесты, экономим время"

Мой ответ:
"Понимаю, тесты замедляют разработку на начальном этапе.
Но вот что я видел в production:

1. Код без тестов → регрессии при рефакторинге
2. Боимся менять код → технический долг растёт
3. Баги находятся QA или users → дорого
4. Рефакторинг невозможен → legacy code

В долгосрочке тесты экономят время, потому что:
- Уверенность при изменениях
- Документация через примеры
- Баги ловятся рано

Кроме того, наш проект требует 90%+ coverage по SLA.

Давайте напишем хотя бы критичные тесты,
а остальное доделаем позже?"

Как я структурирую обсуждение

1. СЛУШАЮ полностью без перебиваний
   └─ "Мне понравилось, как ты подумал о..."

2. ИЩУ что-то хорошее в идее
   └─ "В твоём подходе есть смысл для X..."

3. ВЫРАЖАЮ СВОИ ОПАСЕНИЯ аккуратно
   └─ "У меня есть опасения по Y, потому что..."

4. ПРЕДЛАГАЮ АЛЬТЕРНАТИВЫ
   └─ "Давай попробуем вариант Z, который..."

5. ИЩУ КОМПРОМИСС
   └─ "Можем ли мы совместить подходы?"

Когда я "нет, не делаем это" (без вариантов)

Есть случаи, когда нужно быть решительнее:

1. Security issues

Коллега: "Давай отключим CSRF protection в dev mode"

Мой ответ: "Нет. Это привычка, которая приведёт к проблемам.
Используем proper mocking вместо отключения защиты."

2. Нарушение архитектуры, которая обговорена

// В нашей архитектуре: Domain → Application → Infrastructure
// Коллега: "Давай в Domain Layer сделаем @Transactional"

Мой ответ: "Нет. Domain должен быть независим от фреймворка.
@Transactional — это инфраструктура.
Это обсуждали в docs/architecture/01_layers.md"

3. Код, который я знаю, будет проблемой

Коллега (junior): "Давай сделаем select N+1 query для простоты?"

Мой ответ: "Не получится масштабироваться.
Я видел это три раза — каждый раз приходилось откатывать.
Давайте сделаём join с первого раза."

Когда я допускаю ошибку и коллега меня исправляет

Я могу ошибаться. Важно принимать это:

Коллега: "Стоп, я нашёл, где твой подход не работает..."

Мой ответ: "Спасибо! Ты прав, я не думал об этом.
Давай переделаем на твой вариант."

Так коллега видит:
- Я открыт к критике
- Я не защищаю свой код из гордости
- Команда важнее эго

Когда идея genuinely плохая, но нужно позволить ошибиться

Иногда коллеги учатся через ошибки.

// Коллега: "Давай заним 100 потоков для HTTP запроса"
// (На очень слабом сервере)

Мой подход:
1. Объясняю риски
2. Показываю расчёты: thread memory × 100 = OOM
3. Предлагаю альтернативу

Если он настаивает (и это не критично):
4. Позволяю попробовать в dev среде
5. Мониторим вместе
6. Когда OOM выбросится — обсуждаем
7. Коллега учится на своём опыте

Инструменты для конструктивного обсуждения

1. ADR (Architecture Decision Record)

Вместо устного спора:
- Документируем решение
- Записываем что пробовали
- Объясняем почему выбрали вариант B

Это избегает переоценки решений каждый раз

2. Proof of Concept

Если спор — давайте сделаем POC:
- Вариант A: твоя идея
- Вариант B: моя идея

Сравним на реальных данных
Побеждает вариант, который быстрее/лучше

3. Metrics

Вместо мнений — используем факты:
- Performance: latency, memory, CPU
- Quality: test coverage, bug density
- Maintainability: cyclomatic complexity, lines changed

Мой опыт

За 10+ лет я видел:

• Junior'ы со свежими идеями выиграли спор с Senior'ами
• Я отстаивал плохую идею из гордости
• Я слишком быстро отрицал новые подходы
• Лучшие решения рождались из компромисса, не из победы одной стороны

Итоговое правило

Спор о коде — не спор о тебе как личности.

Если я говорю "эта идея плохая", это не значит:

• Ты плохой разработчик
• Ты не можешь писать код
• Ты не стоящий человек

Это просто значит: "Вот эта конкретная идея имеет проблемы, давайте найдём лучше."

Команда, которая может открыто обсуждать идеи без обиды — это сильная команда.