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