Ответ
Я придерживаюсь принципа «сильное мнение, слабо держась за него». Мои действия в такой ситуации:
- Уточняю контекст решения: Задаю вопросы, чтобы понять аргументацию тимлида или команды (сроки, сложность поддержки, согласованность с архитектурой).
- Привожу аргументы: Если вижу существенные технические риски в выбранном подходе (производительность, безопасность, масштабируемость), представляю их конкретно, с примерами или ссылками на best practices.
- Принимаю финальное решение команды: После дискуссии поддерживаю выбранный путь, даже если мое предложение не приняли. Лояльность решению команды важна для ее эффективности.
- Документирую дискуссию: В комментариях к PR или в документации кратко фиксирую рассмотренные альтернативы. Это создает историю принятия решений для будущего рефакторинга.
Пример:
// Мое предложение (чистый стрим API):
List<String> result = items.stream()
.filter(Predicate.not(String::isBlank))
.map(String::trim)
.toList();
// Принятое решение (классический цикл):
List<String> result = new ArrayList<>();
for (String item : items) {
if (item != null && !item.isBlank()) {
result.add(item.trim());
}
}
// Комментарий в PR: "Рассматривался вариант со Stream API для лучшей читаемости,
// но выбран цикл для явности и чуть меньшего overhead на малых коллекциях."
Главный итог — решение должно быть технически обоснованным и принятым командой, а не победой в споре.