Дякую, ціквао!
А як шерити дизайн систему написану на тому ж Реакті, якщо інша команда захоче використати Vue?
Чи доведеться кодити загальну базу компонент ще раз?

+

Я бы сказал, что тимлиду стоит учиться объяснять почему он считает, что его совет действительно делает код лучше. Если объяснить не может, но чувствует, что «так точно лучше» — об этом почти всегда можно сказать, ведь если 95% предыдущих решений тимлида были верными, то вырабатывается кредит доверия. Имхо, вот такой тимлид должен быть (поставил на таймкод, буквально 2 минуты слушать): youtu.be/xHa2FFyK67M?t=1255

Если это вопрос конкретно код-стиля, то он на проекте единый и просто не подлежит обсуждению, unless замечание девелопера реально в тему и все «переступают через кучу мусора» просто потому, что так привыкли. В любом случае, если решение автора как минимум не хуже, всегда можно проявить эмпатию и сказать «смотри, твоё решение тоже подходит, но сейчас на проекте другой стиль и мы не готовы вносить эти изменения повсеместно, по таким-то причинам». Таким образом человек почувствует, что его услышали и конфликт сойдет на нет. А если автор реально предлагает хорошее, то почему не имплементить?

Ну и нельзя полностью избежать ситуации, когда каждый останется при своем мнении, со временем таких ситуаций будет сильно меньше. Есть код-стиль проекта, если автора не смог «продать» свои пожелания, значит едем дальше. Как тимлид учится объяснять, почему его совет имеет место быть, так же и автор кода учится «продавать» свои решения.

1) Як ви мотивуєте співробітників робити якісні питання, а не відписки?

By default очікується, що всі будуть виконувати свою роботу якнайкраще та дійсно хочуть передавати власний досвід та розвиватись, намагаємося формувати саме такі команди. Тобто це така ж частина роботи, як і написання коду, при чому не менш важлива, тому не йде мови про зменшення пріорітету

2) У вас в проекті code review робить вся команда або призначена людина?

Призначено декілька людей, али ми підтримуємо постійну ротацію

3) Якщо девелопер робить явну помилку в коді, а ревьюер її пропускає, хто з них двох несе відповідальність за production bug?

Відсутня диференціація як така, тобто, якщо пропустили серйозний баг — робимо ретроспективу щоб зроміти «як так» та які процеси покращити, загалом відповідальність несе вся команда. При цьому важливо зауважити, що і рев’ювер, і розробник обговорюють, як уникнити пропуск такого типу помилок у майбутньому.

Чудова пропозиція про технічні засоби та дякую за ваш приклад з практики!

А ось це типово зайве, а часто і неможливе. Письмова робота має тут безспорну перевагу. Але деякі речі я, наприклад, повторюю в Slack вже російською/українською з більшою кількістю деталей або пояснень (в ревʼю коментарі мають бути англійською, за полісі).

Дійсно, залежить від лімітів. Основна думка була в тому, що аудіальна форма вносить остаточну ясність та покращує комунікацію, що з часом і призводить до прикладу про колегу-аудіала, якому зідзвони зараз вже не потрібні

«Refactor as you go» це дійсно корисна штука, я тут трошки про інше, коли разом із вирішенням задачі отримуєш такий рефакторинг, на тестування якого потрібна була б окрема задача. Або коли рефакторинг в коміті взагалі не стосується задачі. В результаті це гальмує, а інколи унеможливлює деплоймент основної фічі, заради якої задача була створена з самого початку