Терпеть не могу код ревью (1/4)
В жизни каждого разработчика наступает такой момент, когда нужно отдать свой код коллегам на проверку. Я всегда не любил этот процесс: несколько дней твоей кропотливой работы сталкиваются с критическим взглядом со стороны. И вот теперь ты не просто разработчик, а адвокат своего решения, парирующий пассивно-агрессивные комментарии коллег, которые, уж конечно, всегда знают, как лучше. И это, в принципе, довольно популярное мнение среди сообщества.
Чуть больше года назад наша команда на работе стала расширяться. С двух фронтендеров на проекте мы выросли до четырех (а сейчас вообще до 10, но это уже другая история), и это повлекло за собой предсказуемые сложности:
- Если двум людям довольно легко синхронизироваться под определенный код-стайл, архитектуру приложения, то четырем придется потратить больше усилий и времени.
- Стало сложнее ориентироваться в новых классах, утилитарных функциях - это порождало дублирование логики и увеличение кодовой базы.
- Поддерживать код, написанный другими коллегами, очень тяжело, если видишь его впервые.
- “Откуда здесь это вообще взялось? Зачем это нужно?” - часть коллег перестали понимать бизнес-ценность чужих задач.
- Количество багов в приложении увеличивалось от спринта к спринту, рос техдолг.
“Надо наладить код-ревью” - решили мы после очередного спринта, закрытого с кучей багов. Вы уже знаете, как я люблю этот процесс, поэтому именно мне "повезло" первому обкатать его в команде. Я взял большую задачу, реализовал ее, отполировал до блеска и отправил коллегам код нарастерзание оценку.
В тот раз под своим трудом я собрал больше 100 комментариев за сутки. Это мой абсолютный рекорд хайпожорства, вот бы я когда-нибудь на канале столько собирал.
Шутки шутками, там были как комментарии по делу, так и довольно субъективные решения, с которыми уж очень хотелось поспорить. На обсуждение этой задачи мы потратили несколько напряженных дней (в интернете кто-то не прав!), к консенсусу не пришли и задержали команду тестирования, которая готовилась искать баги. Ну и релиз новой версии тоже задержали, стоит ли упоминать.
В общем, с первого раза сделать все красиво, "как в серьезных компаниях", у нас не получилось. После спринта мы сели за разбор полетов и нашли несколько слабых мест в нашей реализации ревью:
❌ Не все понимают, с какой целью вообще проводится ревью - 100+ комментариев как следствие этого непонимания.
❌ Не всем хорошо даётся коммуникация в рамках ревью (а точнее, всем не даётся) - поэтому многие комментарии коллег читаются токсично. Особенно с точкой на конце, ну, вы знаете.
❌ Не установлены рамки, сроки и критерии завершения ревью - по этой причине мы задержали передачу новой фичи тестировщикам.
В конце концов мы закрыли все перечисленные слабые места и полноценно включили код-ревью в наш процесс разработки. О том, какие решения находили, и как я перестал негативно воспринимать ревью, расскажу в постах дальше.
В жизни каждого разработчика наступает такой момент, когда нужно отдать свой код коллегам на проверку. Я всегда не любил этот процесс: несколько дней твоей кропотливой работы сталкиваются с критическим взглядом со стороны. И вот теперь ты не просто разработчик, а адвокат своего решения, парирующий пассивно-агрессивные комментарии коллег, которые, уж конечно, всегда знают, как лучше. И это, в принципе, довольно популярное мнение среди сообщества.
Чуть больше года назад наша команда на работе стала расширяться. С двух фронтендеров на проекте мы выросли до четырех (а сейчас вообще до 10, но это уже другая история), и это повлекло за собой предсказуемые сложности:
- Если двум людям довольно легко синхронизироваться под определенный код-стайл, архитектуру приложения, то четырем придется потратить больше усилий и времени.
- Стало сложнее ориентироваться в новых классах, утилитарных функциях - это порождало дублирование логики и увеличение кодовой базы.
- Поддерживать код, написанный другими коллегами, очень тяжело, если видишь его впервые.
- “Откуда здесь это вообще взялось? Зачем это нужно?” - часть коллег перестали понимать бизнес-ценность чужих задач.
- Количество багов в приложении увеличивалось от спринта к спринту, рос техдолг.
“Надо наладить код-ревью” - решили мы после очередного спринта, закрытого с кучей багов. Вы уже знаете, как я люблю этот процесс, поэтому именно мне "повезло" первому обкатать его в команде. Я взял большую задачу, реализовал ее, отполировал до блеска и отправил коллегам код на
В тот раз под своим трудом я собрал больше 100 комментариев за сутки. Это мой абсолютный рекорд хайпожорства, вот бы я когда-нибудь на канале столько собирал.
Шутки шутками, там были как комментарии по делу, так и довольно субъективные решения, с которыми уж очень хотелось поспорить. На обсуждение этой задачи мы потратили несколько напряженных дней (в интернете кто-то не прав!), к консенсусу не пришли и задержали команду тестирования, которая готовилась искать баги. Ну и релиз новой версии тоже задержали, стоит ли упоминать.
В общем, с первого раза сделать все красиво, "как в серьезных компаниях", у нас не получилось. После спринта мы сели за разбор полетов и нашли несколько слабых мест в нашей реализации ревью:
❌ Не все понимают, с какой целью вообще проводится ревью - 100+ комментариев как следствие этого непонимания.
❌ Не всем хорошо даётся коммуникация в рамках ревью (а точнее, всем не даётся) - поэтому многие комментарии коллег читаются токсично. Особенно с точкой на конце, ну, вы знаете.
❌ Не установлены рамки, сроки и критерии завершения ревью - по этой причине мы задержали передачу новой фичи тестировщикам.
В конце концов мы закрыли все перечисленные слабые места и полноценно включили код-ревью в наш процесс разработки. О том, какие решения находили, и как я перестал негативно воспринимать ревью, расскажу в постах дальше.
🔥18😱2❤1
Да да, телега выкатила бусты для каналов.
1 буст и я начну постить истории.
https://t.me/alek_dev?boost
1 буст и я начну постить истории.
https://t.me/alek_dev?boost
🐳2👍1
Алек, сделай
Терпеть не могу код ревью (1/4) В жизни каждого разработчика наступает такой момент, когда нужно отдать свой код коллегам на проверку. Я всегда не любил этот процесс: несколько дней твоей кропотливой работы сталкиваются с критическим взглядом со стороны.…
Терпеть не могу код ревью (2/4) - Цели
Итак, первая попытка в код-ревью прошла ужасно: мы сорвали сроки, много времени решали, как правильно писать код, а как - нет, и настроение в команде было напряженное.
Мы собрались на разбор полетов, и каждый высказал свое видение, почему наш опыт был неудачным. Вдруг кто-то спросил: “Мы столько времени потратили, сорвали сроки, перессорились, может, нам вообще не проводить ревью?”. Вопрос встретила тишина, потому что за всеми спорами мы забыли про цели, которые мы преследуем, внедряя код-ревью.
В первом посте я описал причины, которые привели нас к решению ввести этот процесс в команде, но не цели. Как итог, мы проводили ревью ради ревью, потому что просто договорились так и подумали, что в той конкретной ситуации нам это поможет.
Мы выбрали три основные долгосрочные цели, которые покрывают конкретные боли. Их было озвучено гораздо больше, но некоторые из-за специфики продукта мы отклонили или объединили в общие. Вероятно, в другой команде, на другом проекте они будут несколько отличаться.
✅ Команда без усилий придерживается правил написания кода
Зачем нужна эта цель: участники команды пишут код в похожем стиле и не испытывают сложности в доработке кода, который написал их коллега.
Если разработчик отдал код на ревью, который по своей архитектуре отличается от того, к чему привыкли остальные - такая штука не пройдет проверку. Да, если мы сейчас вольем эту фичу, то уменьшим Lead Time в моменте (и порадуем заказчика), но значительно проиграем в этой же метрике позже, когда начнем дорабатывать этот грязный код.
Чтобы писать код так, как принято в команде, мы завели отдельную страничку в confluence (вики) и верхнеуровнево описали наш подход и ключевые моменты, на которые стоит обратить внимание + расшарили на всех настройки IDE и почти выровняли правила для линтеров между проектам.
✅ Команда знает, что происходит в проекте
Зачем нужна эта цель: снижение скорости роста кодовой базы, понимание взаимосвязи компонентов и корректная оценка трудозатрат при планировании.
Как писал в первой части, даже старым участникам команды стало тяжело ориентироваться в проекте. Из-за этого выросло количество кода, который повторяет то, что уже было написано ранее. Кто-то завозил новые библиотеки, а другие продолжали изобретать велосипеды, хотя рядом с ними припарковался стильный байк.
Помимо перечисленных проблем, это все еще приводило к тому, что оценки при планировании стали сильно разниться. Для одного участника задача выглядела на 5 сторипоинтов, а для другого - на 13. Один участник знал, что ему для реализации задачи нужно будет дописать функцию и переиспользовать уже существующий компонент, а другой думал, что придется реализовывать весь функционал с нуля.
В целом, следование этой цели покрывает даже не столько технические проблемы, сколько обмен знаниями и практиками среди разработчиков. Кто-то узнал, что задачу можно решать не в лоб, а использовать функционал браузера, реализовал это и все разработчики в ходе ревью узнали, что все эти годы так тоже можно было.
✅ Находить лучшее решение совместно
Зачем нужна эта цель: уменьшение багов, снижение техдолга, обучение сотрудников.
Каждый человек в команде имеет разный опыт, бекграунд, проходил разные курсы - никто не знает, как писать правильно. Но по отдельности каждый знает, как можно написать лучше, потому что видит ситуацию со своего угла.
Кто-то прошарил работу библиотеки - подсказал коллеге, почему лучше использовать другой метод. Кто-то шагнул вперед и видит, что реализованное решение не выдержит масштабирования - предложил и объяснил свое решение.
Это позволяет как совместно обучаться (причем не только ревьюверу и разработчику, но и наблюдателям), так и исправлять баги до того, как QA начнет искать их.
———————————————————————
Казалось бы, зачем эти цели, кто еще не знает, для чего нужно ревью? Для синхронизации. Без определения того, что мы ждем в результате введения процесса, нам было сложно договориться о том, на что мы смотрим в ходе проверки: что важно, а что второстепенно - у каждого свое видение.
Итак, первая попытка в код-ревью прошла ужасно: мы сорвали сроки, много времени решали, как правильно писать код, а как - нет, и настроение в команде было напряженное.
Мы собрались на разбор полетов, и каждый высказал свое видение, почему наш опыт был неудачным. Вдруг кто-то спросил: “Мы столько времени потратили, сорвали сроки, перессорились, может, нам вообще не проводить ревью?”. Вопрос встретила тишина, потому что за всеми спорами мы забыли про цели, которые мы преследуем, внедряя код-ревью.
В первом посте я описал причины, которые привели нас к решению ввести этот процесс в команде, но не цели. Как итог, мы проводили ревью ради ревью, потому что просто договорились так и подумали, что в той конкретной ситуации нам это поможет.
Мы выбрали три основные долгосрочные цели, которые покрывают конкретные боли. Их было озвучено гораздо больше, но некоторые из-за специфики продукта мы отклонили или объединили в общие. Вероятно, в другой команде, на другом проекте они будут несколько отличаться.
✅ Команда без усилий придерживается правил написания кода
Зачем нужна эта цель: участники команды пишут код в похожем стиле и не испытывают сложности в доработке кода, который написал их коллега.
Если разработчик отдал код на ревью, который по своей архитектуре отличается от того, к чему привыкли остальные - такая штука не пройдет проверку. Да, если мы сейчас вольем эту фичу, то уменьшим Lead Time в моменте (и порадуем заказчика), но значительно проиграем в этой же метрике позже, когда начнем дорабатывать этот грязный код.
Чтобы писать код так, как принято в команде, мы завели отдельную страничку в confluence (вики) и верхнеуровнево описали наш подход и ключевые моменты, на которые стоит обратить внимание + расшарили на всех настройки IDE и почти выровняли правила для линтеров между проектам.
✅ Команда знает, что происходит в проекте
Зачем нужна эта цель: снижение скорости роста кодовой базы, понимание взаимосвязи компонентов и корректная оценка трудозатрат при планировании.
Как писал в первой части, даже старым участникам команды стало тяжело ориентироваться в проекте. Из-за этого выросло количество кода, который повторяет то, что уже было написано ранее. Кто-то завозил новые библиотеки, а другие продолжали изобретать велосипеды, хотя рядом с ними припарковался стильный байк.
Помимо перечисленных проблем, это все еще приводило к тому, что оценки при планировании стали сильно разниться. Для одного участника задача выглядела на 5 сторипоинтов, а для другого - на 13. Один участник знал, что ему для реализации задачи нужно будет дописать функцию и переиспользовать уже существующий компонент, а другой думал, что придется реализовывать весь функционал с нуля.
В целом, следование этой цели покрывает даже не столько технические проблемы, сколько обмен знаниями и практиками среди разработчиков. Кто-то узнал, что задачу можно решать не в лоб, а использовать функционал браузера, реализовал это и все разработчики в ходе ревью узнали, что все эти годы так тоже можно было.
✅ Находить лучшее решение совместно
Зачем нужна эта цель: уменьшение багов, снижение техдолга, обучение сотрудников.
Каждый человек в команде имеет разный опыт, бекграунд, проходил разные курсы - никто не знает, как писать правильно. Но по отдельности каждый знает, как можно написать лучше, потому что видит ситуацию со своего угла.
Кто-то прошарил работу библиотеки - подсказал коллеге, почему лучше использовать другой метод. Кто-то шагнул вперед и видит, что реализованное решение не выдержит масштабирования - предложил и объяснил свое решение.
Это позволяет как совместно обучаться (причем не только ревьюверу и разработчику, но и наблюдателям), так и исправлять баги до того, как QA начнет искать их.
———————————————————————
Казалось бы, зачем эти цели, кто еще не знает, для чего нужно ревью? Для синхронизации. Без определения того, что мы ждем в результате введения процесса, нам было сложно договориться о том, на что мы смотрим в ходе проверки: что важно, а что второстепенно - у каждого свое видение.
👍10🔥5
Больше трёх лет я шел к этому моменту. В пятницу был мой последний день работы frontend разработчиком, сегодня я официально продакт.
❤30🍾6😱4🔥1
Терпеть не могу код ревью (3/4) - Регламент
Мой первый PR (pull/merge request - запрос на внесение изменения в код проекта) в рамках нашего нового процесса провисел несколько суток и задержал релиз. Дискуссия под моим кодом с каждым днем только увеличивалась: коллеги продолжали спорить над тем, что уже было исправлено, и начинали новые ветки комментариев под теми частями, за которые не успели зацепиться ранее.
Чтобы не повторять такой опыт, мы договорились о регламенте ревью, который установил рамки в этом процессе:
- Все, что не относится к целям ревью (из предыдущего поста) - не является предметом ревью.
- Ответственный за PR - его автор. Он следит за тем, чтобы ревьюверы не забыли прожать галочку, когда код можно вливать в основную ветку.
- Разработчик вправе не исправлять каждое замечание.
- Однако, есть критичные замечания, которые обязательны к исправлению. Такие ревьювер должен выделять, чтобы они не затерялись среди других комментариев.
- Концептуальные вопросы выносятся на обсуждение в общий чат и позднее закрепляются в стайл гайде (та самая страничка в нашем confluence/wiki), куда можно ссылаться в следующий раз.
- Ревью подлежит только новая функциональность, но не исправления багов.
- Критикуя, оставляй предложения.
- Ревью не только для замечаний: узнали что-то новое из PR своего коллеги, или увидели, что качество кода возросло - отметьте это и похвалите.
После этого мы договорились об ограничениях в сроках проверки PR. Это было нужно, чтобы не затягивать ревью на несколько дней. Помимо этого, определили минимальное условие, необходимое для вливания кода в основную ветку:
- PR “живет” всего 24 часа. Это означает, что у ревьюверов есть только сутки на то, чтобы дать комментарии, а у разработчика - исправить замечания.
- Если за первые 4 часа никто не прокомментировал PR, то разработчик должен попросить об этом в общем чате. Это нужно, чтобы не надоедать каждые полчаса напоминаниями о проверке.
- PR может быть влит в основную ветку только после подтверждения хотя бы одного из ревьюверов.
Как итог, за сутки жизни PR можно успеть прокомментировать только основные недочеты. Огромные ветви обсуждений при регламентированных сроках стали непродуктивными. Больше никаких ревью на несколько дней, долгих дискуссий и споров под твоей работой о том, как правильно писать код, и в какой шараге учат этому лучше.
Ну а чтобы все было совсем хорошо, мы договорились избегать коротких неконструктивных комментариев по типу “Мы так не пишем, переделай”. По двум причинам:
- Само по себе такое сообщение хоть и экономит секунды жизни ревьювера, но никак не ведет к конструктивному диалогу.
- Разбор того, а как в итоге правильно писать, затягивается надолго, поэтому и есть правило “критикуя, предлагай”. Тем самым, автор PR не дожидается следующих комментариев коллеги.
Это, кстати, только одно из нескольких правил коммуникации, о которых мы договорились. О том, как мы разрулили коммуникацию между ревьюверами и разработчиком, расскажу дальше
Мой первый PR (pull/merge request - запрос на внесение изменения в код проекта) в рамках нашего нового процесса провисел несколько суток и задержал релиз. Дискуссия под моим кодом с каждым днем только увеличивалась: коллеги продолжали спорить над тем, что уже было исправлено, и начинали новые ветки комментариев под теми частями, за которые не успели зацепиться ранее.
Чтобы не повторять такой опыт, мы договорились о регламенте ревью, который установил рамки в этом процессе:
- Все, что не относится к целям ревью (из предыдущего поста) - не является предметом ревью.
- Ответственный за PR - его автор. Он следит за тем, чтобы ревьюверы не забыли прожать галочку, когда код можно вливать в основную ветку.
- Разработчик вправе не исправлять каждое замечание.
- Однако, есть критичные замечания, которые обязательны к исправлению. Такие ревьювер должен выделять, чтобы они не затерялись среди других комментариев.
- Концептуальные вопросы выносятся на обсуждение в общий чат и позднее закрепляются в стайл гайде (та самая страничка в нашем confluence/wiki), куда можно ссылаться в следующий раз.
- Ревью подлежит только новая функциональность, но не исправления багов.
- Критикуя, оставляй предложения.
- Ревью не только для замечаний: узнали что-то новое из PR своего коллеги, или увидели, что качество кода возросло - отметьте это и похвалите.
После этого мы договорились об ограничениях в сроках проверки PR. Это было нужно, чтобы не затягивать ревью на несколько дней. Помимо этого, определили минимальное условие, необходимое для вливания кода в основную ветку:
- PR “живет” всего 24 часа. Это означает, что у ревьюверов есть только сутки на то, чтобы дать комментарии, а у разработчика - исправить замечания.
- Если за первые 4 часа никто не прокомментировал PR, то разработчик должен попросить об этом в общем чате. Это нужно, чтобы не надоедать каждые полчаса напоминаниями о проверке.
- PR может быть влит в основную ветку только после подтверждения хотя бы одного из ревьюверов.
Как итог, за сутки жизни PR можно успеть прокомментировать только основные недочеты. Огромные ветви обсуждений при регламентированных сроках стали непродуктивными. Больше никаких ревью на несколько дней, долгих дискуссий и споров под твоей работой о том, как правильно писать код, и в какой шараге учат этому лучше.
Ну а чтобы все было совсем хорошо, мы договорились избегать коротких неконструктивных комментариев по типу “Мы так не пишем, переделай”. По двум причинам:
- Само по себе такое сообщение хоть и экономит секунды жизни ревьювера, но никак не ведет к конструктивному диалогу.
- Разбор того, а как в итоге правильно писать, затягивается надолго, поэтому и есть правило “критикуя, предлагай”. Тем самым, автор PR не дожидается следующих комментариев коллеги.
Это, кстати, только одно из нескольких правил коммуникации, о которых мы договорились. О том, как мы разрулили коммуникацию между ревьюверами и разработчиком, расскажу дальше
👍6🔥2
Алек, сделай
Терпеть не могу код ревью (3/4) - Регламент Мой первый PR (pull/merge request - запрос на внесение изменения в код проекта) в рамках нашего нового процесса провисел несколько суток и задержал релиз. Дискуссия под моим кодом с каждым днем только увеличивалась:…
Спойлер к следующей серии
😁11❤5👻1
Собеседования дизайнеров
Небольшие наблюдения по следам перехода в продуктовый менеджмент. Так сложилось, что уже около месяца мы ищем в команду дизайнера, и продакты принимают в этом непосредственное участие.
Собес у дизайнеров - это, оказывается, отдельный удивительный мир. Чтобы вы понимали, из чего состоит типичное собеседование для разработчика:
1. Прескрининг с HR: могут задать вопросы по теории, в которых сам HR ничего не понимает, но за ошибки отсекут уже здесь
2. Технический собес:
- Рассказ о своем опыте + к рассказу могут последовать более глубокие технические вопросы
- Устная секция “вопрос-ответ” по основам языка программирования и необходимой базе, без которой ты не сможешь работать
- Лайв-кодинг с углубленными вопросами, с озвучиванием размышлений, с объяснениями решений, со спорами, дискуссиями и т.д.
3. Собес на софт-скиллы или, как мы его называем, на адекватность
По желанию еще +2 собеседования по алгоритмам и углубленной теории(Яндекс, привет)
И уже после первых двух этапов разработчик выходит униженный и оскорбленный, потому что мало компаний практикуют адекватную культуру собеседований и транслируют ее на нанимающие команды (но это уже тема для другого разговора)
Тем временем собес на дизайнера:
1. Прескрининг на софт-скиллы
2. Еще один собес на софт-скиллы + "а фигму можете показать? А компоненты умеете? А автолейауты могёте? Нет, прямо сейчас не нужно делать, мы видим, спасибо"
3. Последний собес на софт-скиллы
Если это не идеальная IT-профессия, то что тогда?
Небольшие наблюдения по следам перехода в продуктовый менеджмент. Так сложилось, что уже около месяца мы ищем в команду дизайнера, и продакты принимают в этом непосредственное участие.
Собес у дизайнеров - это, оказывается, отдельный удивительный мир. Чтобы вы понимали, из чего состоит типичное собеседование для разработчика:
1. Прескрининг с HR: могут задать вопросы по теории, в которых сам HR ничего не понимает, но за ошибки отсекут уже здесь
2. Технический собес:
- Рассказ о своем опыте + к рассказу могут последовать более глубокие технические вопросы
- Устная секция “вопрос-ответ” по основам языка программирования и необходимой базе, без которой ты не сможешь работать
- Лайв-кодинг с углубленными вопросами, с озвучиванием размышлений, с объяснениями решений, со спорами, дискуссиями и т.д.
3. Собес на софт-скиллы или, как мы его называем, на адекватность
По желанию еще +2 собеседования по алгоритмам и углубленной теории
Тем временем собес на дизайнера:
1. Прескрининг на софт-скиллы
2. Еще один собес на софт-скиллы + "а фигму можете показать? А компоненты умеете? А автолейауты могёте? Нет, прямо сейчас не нужно делать, мы видим, спасибо"
3. Последний собес на софт-скиллы
Если это не идеальная IT-профессия, то что тогда?
😁10👍1💯1
Если вам когда-нибудь было интересно, как ChatGPT так хорошо может отвечать на ваши сообщения, то очень рекомендую бесплатный Стэнфордский курс по NLP:
YouTube-плейлист
Домашки и практические задания
Внутри: чуть вышмата, чуть истории развития NLP, чуть лингвистики, чуть харизматичный препод - создатель одной из популярных моделей векторного представления слов и все приправлено максимально возможным в этом жанре сторителлингом. В совокупности получается очень доступный для понимания курс не только NLP, но и принципов машинного обучения.
10/10
YouTube-плейлист
Домашки и практические задания
Внутри: чуть вышмата, чуть истории развития NLP, чуть лингвистики, чуть харизматичный препод - создатель одной из популярных моделей векторного представления слов и все приправлено максимально возможным в этом жанре сторителлингом. В совокупности получается очень доступный для понимания курс не только NLP, но и принципов машинного обучения.
10/10
❤13❤🔥2🔥1🎉1
Алек, сделай
Если вам когда-нибудь было интересно, как ChatGPT так хорошо может отвечать на ваши сообщения, то очень рекомендую бесплатный Стэнфордский курс по NLP: YouTube-плейлист Домашки и практические задания Внутри: чуть вышмата, чуть истории развития NLP, чуть лингвистики…
Кстати, сегодня у Яндекса стартует новый сезон тренировок, в этот раз по трём направлениям:
- Алгоритмы
- ML
- DevOps
Бесплатно, на месяц и с возможностью попасть в штат по упрощённой схеме. Сам попробую заскочить на трек ML, присоединяйтесь!
- Алгоритмы
- ML
- DevOps
Бесплатно, на месяц и с возможностью попасть в штат по упрощённой схеме. Сам попробую заскочить на трек ML, присоединяйтесь!
Тренировки Яндекса по алгоритмам, ML и DevOps
Новый сезон Тренировок по алгоритмам и ML
👍5❤4🔥1
Алек, сделай
Спойлер к следующей серии
Терпеть не могу код ревью (4/4) - Общение
В завершающем посте расскажу про нашу внутреннюю кухню: как мы пофиксили коммуникацию, сделав ее комфортной и понятной для всех участников процесса.
Коммуникация в интернете - это, на мой взгляд, самостоятельный навык, которому надо учиться, как правописанию или ораторскому мастерству. В реальной жизни, помимо слов, мы также используем невербалику: интонации, жесты, мимику, образы. В сети же у нас ограниченный набор инструментов для донесения своих мыслей. Мы можем использовать скобочки, эмодзи, изображения или даже описывать, какой интонацией наше сообщение надо “прочитать”. Но все это оказывается тщетно, когда сообщения доходят до получателя: сколько бы усилий и красок в текст вы не вложили, интерпретация зависит от контекста и привычек оппонента. Так случилось и у нас.
После той самой сотни комментариев под своей работой я пришел к коллегам и сказал, что мне было не очень приятно читать токсичные и неконструктивные комментарии. Один из них удивился, сказал, что вообще не вкладывал негатив в комментарии, и что он всегда так общается.
Посудите сами, что было тогда:
🔝 “Это не должно работать”
🔝 “А вот это вообще можно было лучше сделать”
🔝 “Уже есть функция, которая делает ровно тоже самое”
🔝 “У нас так не принято, переделай”
Несмотря на то, что комментарии действительно неконструктивны, я допустил, что мой коллега, может быть, и не закладывал все те негативные эмоции, с которыми я читал его сообщения. Стало понятно, что мы по-разному воспринимаем текст, и надо приходить к общему знаменателю.
Что мы сделали, чтобы это исправить:
🔝 Поделили комментарии к коду на несколько типов и сформировали формат сообщения
🔝 Ревьювер объясняет, почему он оставил этот комментарий
🔝 Если ревьювер видит необходимость переписать решение, то к комментарию прилагаются указания / инструкция / вариант решения / ссылка на источники с пояснениями (используй код-ревью как еще один канал для обучения и менторства)
🔝 Поощряем использование эмодзи в комментариях
🔝 Хорошие решения стоит подмечать и давать позитивную обратную связь
🔝 Ввели анекдоты к пулл реквестам (по желанию)
До этих правил мы дошли не сами, а подсмотрели у других команд: в Яндекс Практикуме, у Гугла, Гитлаба. Привожу слегка перефразированные, но реальные комментарии из нашего репозитория, чтобы понимать, к чему мы пришли:
В итоге общее впечатление команды от ревью от спринта к спринту стало сглаживаться даже по мнению того самого коллеги. Сейчас, спустя год, мы не всегда придерживаемся такого формата - это остается по желанию ревьювера. Но в самом начале такие упражнения помогли участникам процесса осознаннее подходить к код-ревью.
В завершающем посте расскажу про нашу внутреннюю кухню: как мы пофиксили коммуникацию, сделав ее комфортной и понятной для всех участников процесса.
Коммуникация в интернете - это, на мой взгляд, самостоятельный навык, которому надо учиться, как правописанию или ораторскому мастерству. В реальной жизни, помимо слов, мы также используем невербалику: интонации, жесты, мимику, образы. В сети же у нас ограниченный набор инструментов для донесения своих мыслей. Мы можем использовать скобочки, эмодзи, изображения или даже описывать, какой интонацией наше сообщение надо “прочитать”. Но все это оказывается тщетно, когда сообщения доходят до получателя: сколько бы усилий и красок в текст вы не вложили, интерпретация зависит от контекста и привычек оппонента. Так случилось и у нас.
После той самой сотни комментариев под своей работой я пришел к коллегам и сказал, что мне было не очень приятно читать токсичные и неконструктивные комментарии. Один из них удивился, сказал, что вообще не вкладывал негатив в комментарии, и что он всегда так общается.
Посудите сами, что было тогда:
Несмотря на то, что комментарии действительно неконструктивны, я допустил, что мой коллега, может быть, и не закладывал все те негативные эмоции, с которыми я читал его сообщения. Стало понятно, что мы по-разному воспринимаем текст, и надо приходить к общему знаменателю.
Что мы сделали, чтобы это исправить:
До этих правил мы дошли не сами, а подсмотрели у других команд: в Яндекс Практикуме, у Гугла, Гитлаба. Привожу слегка перефразированные, но реальные комментарии из нашего репозитория, чтобы понимать, к чему мы пришли:
❗️Обрати внимание:
В проекте это значение используется ещё несколько раз. Думаю, ее можно вынести в константы, чтобы повысить читаемость.
❓ Есть вопрос:
Почему ты решил остановиться именно на этой библиотеке? Смотрел ли в сторону *Library_name*? Судя по описанию, она работает быстрее и весит меньше.
🚀 Возможность для улучшения:
Кажется, здесь компонент будет перерисовываться много раз на странице из-за изменения состояния. Попробуй вынести его отдельно и кешировать, чтобы избежать замедления работы. *Пример кода по возможности*
В итоге общее впечатление команды от ревью от спринта к спринту стало сглаживаться даже по мнению того самого коллеги. Сейчас, спустя год, мы не всегда придерживаемся такого формата - это остается по желанию ревьювера. Но в самом начале такие упражнения помогли участникам процесса осознаннее подходить к код-ревью.
Please open Telegram to view this post
VIEW IN TELEGRAM
✍4❤3👍2🔥2
Открытый вопрос
Пару месяцев назад ко мне обратился начинающий разработчик с просьбой помочь ему подготовиться к первому собеседованию на позицию стажёра на фронтенд. Сегодня он написал, что успешно прошел стажировку и принят в штат 🎉
Теперь ему интересно, как джуну можно быстро прокачаться до миддла?
Вопрос жизненный, и ответ на него может быть у каждого разный, в зависимости от опыта и контекста. Поэтому, коллеги-разработчики, очень любопытно узнать ваше мнение:
если бы начинали вашу карьеру с самого начала, на какие навыки и умения (хардовые и софтовые) вы посоветовали самому себе обратить внимание в первую очередь? В какой момент вы осознали, что перешли из джунов в миддлы?
Пару месяцев назад ко мне обратился начинающий разработчик с просьбой помочь ему подготовиться к первому собеседованию на позицию стажёра на фронтенд. Сегодня он написал, что успешно прошел стажировку и принят в штат 🎉
Теперь ему интересно, как джуну можно быстро прокачаться до миддла?
Вопрос жизненный, и ответ на него может быть у каждого разный, в зависимости от опыта и контекста. Поэтому, коллеги-разработчики, очень любопытно узнать ваше мнение:
если бы начинали вашу карьеру с самого начала, на какие навыки и умения (хардовые и софтовые) вы посоветовали самому себе обратить внимание в первую очередь? В какой момент вы осознали, что перешли из джунов в миддлы?
✍4🔥1
Главное отличие этого Нового года от всех предыдущих в том, что в жанр "открыток из вотсапа" стали попадать изображения из генеративных моделей.
Это ли не киберпанк?
Это ли не киберпанк?
🔥18