В качестве некоторой формализации процесса code review можно вводить определенные теги к комментариям коду. Например: Recommendation, Defect, Code style, Vulnerability и т.д. И далее договориться в команде какие теги являются блокирующими к прохождению ревью, а какие нет. Соответственно, Recommendation может быть опциональным и если автор изменения согласен с замечанием и имеет возможность исправить — исправляет, а может и не исправлять.
Очень классно, что во всей этой истории у Вас и руководителя получилось рабочее и конструктивное решение серьезной проблемы, респект обоим участникам процесса.
Разговор в форме «one-2-one» и «2+1» это, как мне кажется, будут абсолютно два разных разговора. В немалом количестве ситуаций, во втором случае, у человека с которым идет разговор будут темы, которые не хочется поднимать с дополнительным человеком, который присутствует. Если разговор касается каких-то серьезных рабочих проблем, то мне кажется самый лучший формат «one-2-one».
А Вы не спрашивали их сколько времени они тратят на самообразование вне работы: чтение литературы и статей, просмотр видео с профильных конференций и т.д.?
Давайте я попробую сформулировать свой вопрос с более практической точки зрения. Разработчик в рамках задачи реализовал какую-то новую фичу в проекте, например в рамках требования от бизнеса. После этого ему нужно написать автотест (согласно повествованию в статье). Для того чтобы написать автотест, как мне кажется, должен существовать какой-то план тестирования этой фичи. Конечная же задача чтобы выполнялось требование от бизнеса. Далее на основе плана пишется код автотеста. Если это так, то кто составляет план и кто верифицирует что план верный? И есть ли какое-то ревью теста?
Legacy проект это в первую очередь, по моему опыту, это очень много баг фикса. Причём баг фикса преимущественно без рефакторинга, потому что как раз на него бизнес не очень хочет выделять время (тема отдельных долгих обсуждений). Отсюда вытекает, как Вы написали, много анализа кода — это действительно присутствует. Среди советов можно добавить: 1) фикс бага только с добавлением теста на данный сценарий (исключение тест добавить невозможно или очень дорого) 2) ведение базы знаний по решенным проблемам: что случилось? почему? как решили? что сделали чтобы снизить вероятность повторения?
А какие могут быть советы в рамках «Путь разработчика» для кардинальной горизонтальной смены предметной области, в которой работаешь, при этом учитывая что в текущей предметной области у тебя уровень Senior. Например, сейчас у тебя Mobile Development или Desktop Apps, а хочется уйти в Backend Highload, но при этом опыта в последнем у тебя нет конечно, а Junior'ом не хочется получится быть.
В сети или в курилке часто можно услышать утверждения о том, что TOEFL/IELTS проверяют не уровень владения языком, а умение соответствовать шаблонам.
Мне кажется эти утверждения исходят из непонимания того, что для оценки на сертификационном/экзаменационном уровне каких-то знаний нужен какой-то единых подход, единая мера весов. В результате часть времени подготовки к экзамену уходит на понимание структуры экзамена, чтобы в итоге сам процесс экзамена не стал сюрпризом.
Еще хочется добавить, чтобы получение сертификата — это отличная цель (особенно когда лень что-то делать). Есть точка A (текущий уровень владения иностранным языком) и есть точка B (следующий уровень), к которой нужно прийти/достичь — многих людей это сильно мотивирует.
Давно замечаю, что немалое количество людей (в первую очередь менеджеров) считает отпуск панацеей от выгорания: «нужно больше отдыхать», «сходи в отпуск». Очень верно подмечено про баланс рутины и мозгового штурма. Если ты постоянно занят простой рутиной, то через какое-то время становится очень сложно участвовать в мозговых штурмах и вообще решать серьёзные задачи. Мозг становится растренированным. И если человек амбициозен и хочет задач, когда нужно постоянно думать, довольно часто, на него начинает это давить психологически. Хороший менеджер должен чувствовать такие ситуации и решать их.
Спасибо большое за пост, очень структурировано и лаконично!
Если кто-то написал херовый код, то так ему и скажи: «Ты написал херовый код».
Вот здесь не соглашусь, т.к. ощущается небольшой перегиб. Разработчик вполне может оказаться обидчивыми (да, такое может быть) и запомнит это надолго. Руководитель после этого будет уже в меньшей степени после этого восприниматься как друг. Плюс сам разработчик будет иметь больше боязни при изменения в коде. Мне кажется если кто-то написал реально плохой код — нужно максимально корректно разобрать ошибки и без эмоций.
Всё зависит от автора, а точнее от его уровня компетенции. Если Junior или Middle-недавний-Junior начинает игнорировать (а главное может это делать совершенно спокойно) замечания Senior'ов или архитектора, то мне кажется что-то точно не так с процессами. Поэтому в общем случае давать право игнорировать замечания нельзя.
Какие методы остановки продолжительных споров в рамках Code Review можно предложить? Особенно в ситуациях, когда «стопарится» занесение кода в master. Например, реализация метода верная, но не кому-то она не нравится и начинается обсуждение (долгий тред) на один день. Может ли быть ограничение по времени на завершение Code Review?
Могу порекомендовать репозиторий C++ links, где автор публикует найденные полезные ресурсы по С++ по различным категориям.
Очень классно, что во всей этой истории у Вас и руководителя получилось рабочее и конструктивное решение серьезной проблемы, респект обоим участникам процесса.
А тест-планы тоже разработчики прорабатывают и составляют, на основе которых пишутся автотесты?
хочетсяполучится быть.Мне кажется эти утверждения исходят из непонимания того, что для оценки на сертификационном/экзаменационном уровне каких-то знаний нужен какой-то единых подход, единая мера весов. В результате часть времени подготовки к экзамену уходит на понимание структуры экзамена, чтобы в итоге сам процесс экзамена не стал сюрпризом.
Еще хочется добавить, чтобы получение сертификата — это отличная цель (особенно когда лень что-то делать). Есть точка A (текущий уровень владения иностранным языком) и есть точка B (следующий уровень), к которой нужно прийти/достичь — многих людей это сильно мотивирует.
А есть какое-то взвешенное объяснение этого? Чем это выгоднее и/или удобнее для руководителя?
Вот здесь не соглашусь, т.к. ощущается небольшой перегиб. Разработчик вполне может оказаться обидчивыми (да, такое может быть) и запомнит это надолго. Руководитель после этого будет уже в меньшей степени после этого восприниматься как друг. Плюс сам разработчик будет иметь больше боязни при изменения в коде. Мне кажется если кто-то написал реально плохой код — нужно максимально корректно разобрать ошибки и без эмоций.
а тесты были написаны?