Все верно, согласен. Автоматизация проверок - это очень хорошая и нужная практика. Если она внедрена в компании, то становится гораздо проще и легче.
А если такой практики нет, то нужно поднимать вопрос о ее внедрении. А по моему (субъективному) опыту в некоторых компаниях с ходу это сделать довольно проблематично. Поэтому новому сотруднику лучше сперва начать с себя, а затем перенести эту практику на уровень отдела/компании.
Год только начался, поэтому таких лайфхаков будет еще немало.
Такие вещи должны быть описаны в конфе, согласен. Но если бы все было так просто, то тогда наша статья состояла из одного предложения: "Если в вашем коде нашли ошибку, то внимательно почитайте конфлюенс и исправьте ее".
Если человек пришел в компанию, где есть хорошая база знаний и где хорошо работает система погружения, то вопросов нет.
Но на деле (на основе субъективного опыта авторов статьи) бывают компании, у которых либо нет базы знаний, либо она устарела. И получаются ситуации, когда код написан, передан в ревью, но не протестирован.
И в этом случае, пусть лучше у новичка будет 4 мнения от 3 разработчиков, чем непротестированный код в ревью.
И стоит таким правильным товарищам выйти из своей зоны комфорта как тут же становятся и мидлами и джунами.
Ну да. Любой может на время стать «джуном» в новом проекте. Или с новым продуктом.
И еще я очень часто сталкивался с таким моментом, что ответ может повлечь за собой только еще больше вопросов, особенно когда этот товарищ не из твоей команды. Это приводит к разведению холиваров и отвлечению от работы, поэтому иногда лучше все-таки промолчать.
Так наша основная мысль в том, что указание на ошибку или вопрос о решении — это сигнал. Сигнал, что нужно еще раз внимательно все перечитать и проверить (если мы про текст). Указание на ошибку или вопрос о решении — это не оскорбление. А просто знак, говорящий о том, что надо обратить внимание на отдельный кусок текста или на весь текст целиком (или код). Либо понимать, что этот кусок - костыль, и в будущем он может аукнуться.
К данной теме я могу ещё отнести кейс, когда спрашиваешь разработчика - почему он пошёл таким путем, а не вот таким (либо использовал функцию А , вместо функции Б), и вместо ответа получаешь коммит с исправлениями.
Вот да. То же и к тексту относится. Бывает, оставишь в гугл-доке коммент с вопросом, а потом видишь, что твое замечание снято и текст переписан. Но вопрос-то остается: "Почему такое решение?" Думаю, важно не бояться диалога. И не бояться говорить о своей позиции в выборе решения. Позиция, даже если она иногда неверная, лучше, чем ее отсутствие.
Он не очень приличный, потому не будем его сюда писать) Но он очень просто гуглится по запросу "анекдот про строителя мостов"
Это шуточка у нас такая. В разделе №5 - мешать (людям), а в разделе №5 - мешать (напитки в себе).
Вспомнили, что иногда на корпоративах дежурит карета скорой помощи. Так что можно попросить у них)
Мы серьезно. Но тег добавили.
Все верно, согласен. Автоматизация проверок - это очень хорошая и нужная практика. Если она внедрена в компании, то становится гораздо проще и легче.
А если такой практики нет, то нужно поднимать вопрос о ее внедрении. А по моему (субъективному) опыту в некоторых компаниях с ходу это сделать довольно проблематично. Поэтому новому сотруднику лучше сперва начать с себя, а затем перенести эту практику на уровень отдела/компании.
Год только начался, поэтому таких лайфхаков будет еще немало.
Такие вещи должны быть описаны в конфе, согласен. Но если бы все было так просто, то тогда наша статья состояла из одного предложения: "Если в вашем коде нашли ошибку, то внимательно почитайте конфлюенс и исправьте ее".
Если человек пришел в компанию, где есть хорошая база знаний и где хорошо работает система погружения, то вопросов нет.
Но на деле (на основе субъективного опыта авторов статьи) бывают компании, у которых либо нет базы знаний, либо она устарела. И получаются ситуации, когда код написан, передан в ревью, но не протестирован.
И в этом случае, пусть лучше у новичка будет 4 мнения от 3 разработчиков, чем непротестированный код в ревью.
Начинающий специалист может не знать о том, что в команде принят такой сценарий. И при следующем ревью сразу перейдет к сути)
Ну да. Любой может на время стать «джуном» в новом проекте. Или с новым продуктом.
Так наша основная мысль в том, что указание на ошибку или вопрос о решении — это сигнал. Сигнал, что нужно еще раз внимательно все перечитать и проверить (если мы про текст). Указание на ошибку или вопрос о решении — это не оскорбление. А просто знак, говорящий о том, что надо обратить внимание на отдельный кусок текста или на весь текст целиком (или код). Либо понимать, что этот кусок - костыль, и в будущем он может аукнуться.
Так в ответ на "Я так придумал" последует другой вопрос: "Почему так придумал?" Нормальный конструктивный диалог.
Если все описано в Конфле, то у трех разработчиков уж должно быть единое мнение)
Вполне нормальная позиция.
Вот да. То же и к тексту относится. Бывает, оставишь в гугл-доке коммент с вопросом, а потом видишь, что твое замечание снято и текст переписан. Но вопрос-то остается: "Почему такое решение?" Думаю, важно не бояться диалога. И не бояться говорить о своей позиции в выборе решения. Позиция, даже если она иногда неверная, лучше, чем ее отсутствие.