Комментарии 9
Вся собранная статистика аккумулируется в SonarQube и используется всеми заинтересованными лицами: программистами – для самопроверки и определения проблемных мест, руководством – для понимания состояния проекта.
Получается вся команда, да еще и руководство (!?) должно знать обо всех нюансах всех частей проекта? Или расскажите, пожалуйста, какие используете метрики для оценки чужого, мне неизвестного, кода. Т.е. примеров бы.
Руководству нет необходимости знать о внутренностях проекта, углубляться в технические решения. Для них как раз высчитываются свои метрики, например, размер технического долга (http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar/). Так, если он постоянно растет, то это сигнал о проблемах на проекте. Также Sonar поддерживает SQALE (http://en.wikipedia.org/wiki/SQALE).
Архитекторам (или техническим лидерам) уже предоставляется больше интересной для них информации. Они, естественно, уже в курсе деталей проекта (архитектуры, установленных правил). Sonar с легкостью покажет проблемные местах в проекте (содержащих большое количество замечаний), подозрительные зависимости, недостаток комментариев, недостаток покрытия кода тестами, дублирование кода. Вся эта информация им необходима для отслеживания того, что архитектура проекта развивается в правильном направлении и соблюдаются установленные стандарты кодирования.
Даже если код не ваш, то наличие в нем замечаний с приоритетом critical очень тревожный звоночек. Дальше можно обратить внимание на зависимости — присутствие в них циклов обычно говорит о проблемах в архитектуре. Отсутствие комментариев грозит тем, что на исправление багов или добавление функционала вы будете тратить больше времени, чем при их наличии.
Архитекторам (или техническим лидерам) уже предоставляется больше интересной для них информации. Они, естественно, уже в курсе деталей проекта (архитектуры, установленных правил). Sonar с легкостью покажет проблемные местах в проекте (содержащих большое количество замечаний), подозрительные зависимости, недостаток комментариев, недостаток покрытия кода тестами, дублирование кода. Вся эта информация им необходима для отслеживания того, что архитектура проекта развивается в правильном направлении и соблюдаются установленные стандарты кодирования.
Даже если код не ваш, то наличие в нем замечаний с приоритетом critical очень тревожный звоночек. Дальше можно обратить внимание на зависимости — присутствие в них циклов обычно говорит о проблемах в архитектуре. Отсутствие комментариев грозит тем, что на исправление багов или добавление функционала вы будете тратить больше времени, чем при их наличии.
Если вас заинтересовал Sonar, то вы можете с ним и его метриками поближе познакомиться на тестовом инстансе nemo.sonarqube.org/.
НЛО прилетело и опубликовало эту надпись здесь
около 10 человек
вы правильно сказали «очень сильно зависит от команды». Если это 3 опытных программиста то объем замечаний минимален и достаточно посмотреть коммиты. Но часто в команде есть всегда неопытный программист, за кодом которого необходимо внимательно следить и проверять, что все замечания были исправлены. Тут уже помощь специальных средств ощутима
вы правильно сказали «очень сильно зависит от команды». Если это 3 опытных программиста то объем замечаний минимален и достаточно посмотреть коммиты. Но часто в команде есть всегда неопытный программист, за кодом которого необходимо внимательно следить и проверять, что все замечания были исправлены. Тут уже помощь специальных средств ощутима
Спасибо за статью, но у меня все равно остались вопросы без ответа
— не ясно как уменьшить время, которое тратится на обзор?
— что делать с недобросовестным обзором?
Я полностью за кодревью, и мы это делаем (в терминах этой стать 95% на github'е), но у меня такое чувство, что что-то не так (дальше в описании крик души). Сборки на каждый пулл-реквест автоматически собираются, все тесты прогоняются, если тесты не работают, то и смотреть как правило пока рано.
— Смотрю на стиль (тут обычно проблем не возникает), выясняю как выглядит картина из далека без деталей, иногда несколько замечаний по API, обсуждаем почему так и решаем как должно быть. Не отнимает много времени, просто прочитать код, оценить что да как.
— смотрю на логику, дебажу тесты. Рассматриваю всякие случаи. Тут начинается «а что если ...», и выясняется, что все плохо. Иногда обсуждаем в переписке, иногда устно, но все равно процесс слияния затягивается, да и такого рода проверка занимает довольно длительное время. Как правило, в таких случаях начинаем думать, как бы это так переписать, чтобы проблема устранялась на уровне архитектуры. В итоге, один пулл-реквест может затянутся на несколько дней или даже неделю. В нормальных условиях у меня рука не поднимается смержить код, когда я точно знаю, что программа может сломаться или работать совсем не так как надо. Это же не на коленке один раз запустить, а отправить юзерам. Обычно в таких случаях вешаю пулл-реквест на себя и объясняю, где баг и никто его не мержит, пока все не исправится.
В общем чувствую себя в эти моменты не по-феншую. Показал коллегам, что их код, простите, говно, затянул разработку и потратил кучу своего времени, в итоге и сам мало сделал или ничего не сделал.
Но я же не все реквесты рассматриваю, бывает даже, что я не успеваю разобраться в каком-нибудь новом модуле, ну а там часто описанный ранее случай. У других членов команды другой подход, и они довольно быстро все мержат, я, честно говоря, не верю, что они разобрались как это работает.
Опять чувствую себя как-то не по-феншую, но засовываю свой перфекционизм до следующего креша.
Получается, что я такой дартаньян, хотя, конечно, и я делаю кучу ошибок опечаток и что-то забываю. В команде отношение ко мне нормальное, наоборот считаем, что, чем раньше нашли проблему, тем лучше, но скорость разработки существенно проседает.
Пробовал поговорить с тимлидом, со всеми вместе и с каждым лично по поводу детализации пулл-реквестов, по поводу времени, как мне уменьшить свои траты, а другие бы лучше все проверяли перед пулл-реквестом. В итоге обсуждения получается, что я делаю все правильно, и менять ничего не надо.
Вариант сменить место работы, конечно, можно рассмотреть, но это кажется слишком кардинально, и, насколько я понял из данный статьи, что ребята решают эти проблемы на одном месте. Возможно, что есть какие-то подходы, которые это все помогают сделать. В утилиты не верю. Можно написать все по всем стайл-гайдам, но в итоге ничего работать не будет. В основном это поведение в многопоточной постоянно работающей программе.
Напоминаю, что вопросы в начале комментария.
— не ясно как уменьшить время, которое тратится на обзор?
— что делать с недобросовестным обзором?
Я полностью за кодревью, и мы это делаем (в терминах этой стать 95% на github'е), но у меня такое чувство, что что-то не так (дальше в описании крик души). Сборки на каждый пулл-реквест автоматически собираются, все тесты прогоняются, если тесты не работают, то и смотреть как правило пока рано.
— Смотрю на стиль (тут обычно проблем не возникает), выясняю как выглядит картина из далека без деталей, иногда несколько замечаний по API, обсуждаем почему так и решаем как должно быть. Не отнимает много времени, просто прочитать код, оценить что да как.
— смотрю на логику, дебажу тесты. Рассматриваю всякие случаи. Тут начинается «а что если ...», и выясняется, что все плохо. Иногда обсуждаем в переписке, иногда устно, но все равно процесс слияния затягивается, да и такого рода проверка занимает довольно длительное время. Как правило, в таких случаях начинаем думать, как бы это так переписать, чтобы проблема устранялась на уровне архитектуры. В итоге, один пулл-реквест может затянутся на несколько дней или даже неделю. В нормальных условиях у меня рука не поднимается смержить код, когда я точно знаю, что программа может сломаться или работать совсем не так как надо. Это же не на коленке один раз запустить, а отправить юзерам. Обычно в таких случаях вешаю пулл-реквест на себя и объясняю, где баг и никто его не мержит, пока все не исправится.
В общем чувствую себя в эти моменты не по-феншую. Показал коллегам, что их код, простите, говно, затянул разработку и потратил кучу своего времени, в итоге и сам мало сделал или ничего не сделал.
Но я же не все реквесты рассматриваю, бывает даже, что я не успеваю разобраться в каком-нибудь новом модуле, ну а там часто описанный ранее случай. У других членов команды другой подход, и они довольно быстро все мержат, я, честно говоря, не верю, что они разобрались как это работает.
Опять чувствую себя как-то не по-феншую, но засовываю свой перфекционизм до следующего креша.
Получается, что я такой дартаньян, хотя, конечно, и я делаю кучу ошибок опечаток и что-то забываю. В команде отношение ко мне нормальное, наоборот считаем, что, чем раньше нашли проблему, тем лучше, но скорость разработки существенно проседает.
Пробовал поговорить с тимлидом, со всеми вместе и с каждым лично по поводу детализации пулл-реквестов, по поводу времени, как мне уменьшить свои траты, а другие бы лучше все проверяли перед пулл-реквестом. В итоге обсуждения получается, что я делаю все правильно, и менять ничего не надо.
Вариант сменить место работы, конечно, можно рассмотреть, но это кажется слишком кардинально, и, насколько я понял из данный статьи, что ребята решают эти проблемы на одном месте. Возможно, что есть какие-то подходы, которые это все помогают сделать. В утилиты не верю. Можно написать все по всем стайл-гайдам, но в итоге ничего работать не будет. В основном это поведение в многопоточной постоянно работающей программе.
Напоминаю, что вопросы в начале комментария.
> не ясно как уменьшить время, которое тратится на обзор?
По факту мы это сделали с помощью автоматизации(Sonar, Confluence) рутинных действий, возникающих при проведении инспекций кода: отправка кода на ревью, отслеживания исправления дефектов, обсуждение спорных мест, автоматическое нахождение очевидных дефектов, вычисление различных метрик (сложность кода, количество комментариев, количество замечаний на класс и тд). Github, кстати, делает часть описанных вещей.
В итоге, остается только ручная проверка. При ней уже смотрится какая задача стояла и как она была реализована (логика, тесты). Без этого все равно никак.
Я не утверждаю, что утилиты — это наше все. Однако, они дают хорошую отправную точку в анализе кода.
> что делать с недобросовестным обзором?
Недобросовестный обзор бесполезен, его можно выкинуть.
Если это делается намеренно, то это саботаж. Надо разбираться в причинах.
Если разработчик говорит, что с твоим кодом все ОК, то это означает, что он теперь отвечает за этот код так же как за свой со всеми вытекающими из этого последствиями.
По факту мы это сделали с помощью автоматизации(Sonar, Confluence) рутинных действий, возникающих при проведении инспекций кода: отправка кода на ревью, отслеживания исправления дефектов, обсуждение спорных мест, автоматическое нахождение очевидных дефектов, вычисление различных метрик (сложность кода, количество комментариев, количество замечаний на класс и тд). Github, кстати, делает часть описанных вещей.
В итоге, остается только ручная проверка. При ней уже смотрится какая задача стояла и как она была реализована (логика, тесты). Без этого все равно никак.
Я не утверждаю, что утилиты — это наше все. Однако, они дают хорошую отправную точку в анализе кода.
> что делать с недобросовестным обзором?
Недобросовестный обзор бесполезен, его можно выкинуть.
Если это делается намеренно, то это саботаж. Надо разбираться в причинах.
Если разработчик говорит, что с твоим кодом все ОК, то это означает, что он теперь отвечает за этот код так же как за свой со всеми вытекающими из этого последствиями.
Да, деление ответственности — обязательная часть review, иначе это все голословно.
А вот когда головой отвечаешь за чужой код — волей-неволей прочитаешь и проверишь частные случаи.
А разбор сценариев «а что если» нужно делать еще ДО реализации. Т.е. проводить не только review кода, но и review дизайна предполагаемого решения.
А вот когда головой отвечаешь за чужой код — волей-неволей прочитаешь и проверишь частные случаи.
А разбор сценариев «а что если» нужно делать еще ДО реализации. Т.е. проводить не только review кода, но и review дизайна предполагаемого решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
У вас здесь ошибка… или о практике инспекций кода в мобильной разработке