Ответ
Я придерживаюсь принципа «сильное мнение, слабо держась за него». Мои действия в такой ситуации:
- Уточняю контекст решения: Задаю вопросы, чтобы понять аргументацию тимлида или команды (сроки, сложность поддержки, согласованность с архитектурой).
- Привожу аргументы: Если вижу существенные технические риски в выбранном подходе (производительность, безопасность, масштабируемость), представляю их конкретно, с примерами или ссылками на 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 на малых коллекциях."Главный итог — решение должно быть технически обоснованным и принятым командой, а не победой в споре.
Ответ 18+ 🔞
Да ты посмотри, какой у нас тут философ подъехал! «Сильное мнение, слабо держась за него» — это ж надо такую хуйню умную придумать, я аж зауважал! Ну ладно, сейчас разберем твою, блядь, стратегию выживания в офисе.
Слушай, а в целом-то логика железная, ей-богу. Вот смотри, как это в жизни выглядит.
Твой тимлид такой выходит, весь из себя важный, и говорит: «Делаем вот так, на костылях, но быстро!». А у тебя внутри всё, блядь, сжимается, потому что ты-то видишь, что это пиздец как воняет будущим техдолгом. Но ты не кричишь сразу «Да ты что, мудак?!». Нет, ты включаешь режим «уточняю контекст».
Ты такой: «Слушай, а че так срочно? Может, там сверху начальство дышит в затылок? Или мы эту хуйню через месяц выкинем нахер?». Это, блядь, святое — понять, откуда ноги растут. Может, человек просто под прессом, а не идиот.
Дальше, если риски реальные — ну там производительность на уровне «хуй с горы покатится», или безопасность — «дыра, в которую можно трактором заехать» — вот тут уже надо аргументы готовить. Не просто «это говно», а конкретно: «Вот тут у нас будет O(n²), а данных овердохуища. Вот тут можно инъекцию впихнуть, если чурка неопытная будет править». Без паники, по делу.
А вот потом — самый, блядь, важный момент. Команда (или тот же тимлид) сказала «Нет, Вася, делаем на костылях». И ты… соглашаешься. Да, вот так вот. Потому что если ты будешь саботировать или киснуть, то всем будет только хуево. Команда должна двигаться в одну сторону, даже если это, по твоему мнению, не самая лучшая сторона.
Но! Чтобы твоя душа не болела, ты делаешь хитрожопую фишку — документируешь. Прям в коде или в PR пишешь: «Ребята, тут мы могли бы сделать через стримы (пример ниже), но решили через цикл, ибо так проще для новичков. Если будут проблемы с перфомансом — смотрим сюда». Это, блядь, не пассивная агрессия, это страховка на будущее. Когда через полгода всё ебнется, все поймут, что ты был прав, но не мудак, который «я же говорил».
Твой пример с кодом — он в точку, ёпта! Один вариант — красивый, современный, а второй — простой, как три копейки. И решение часто принимается не в пользу «красивого», а в пользу «понятного всем дебилам в проекте, включая меня завтрашнего». И это, блядь, нормально!
Главный итог, как ты верно подметил — не победить в споре, а чтобы команда сделала обоснованный выбор. А если выбор оказался ебанутым — ну что ж, зато все вместе ошиблись, и у тебя есть запись в летописи, почему так вышло. Чих-пых всем в сраку, идём дальше.