Используется ли у вас Code Review?
Yep. Пользуем Code Collaborator
Интересно стало, практикуется ли у кого-нибудь на работе Code Review (просмотр закоммиченного кода на предмет соблюдения code style, грамотного комментирования, используемых алгоритмов и т.д.)? И если да, то более интересный мнеДа, используются. Код не может быть закоммичен без двух code review: один от человека с твоего проекта, другой — от человека, который обладает readability по языку (т.е. человек знает, как "правильно" писать на этом языке на котором написан changelist. Понятно, что если этот readability есть у тебя или твоего основного ревьювера, отдельный readability review не нужен.
вопрос - как это организовано, какие тулзы используются и т.д.?
Тулзы используются внутренние.
Используем.
Разные тулзы.
Разные тулзы.
О, круто. Это как раз одно из двух приложений, которые я хотел повнимательнее рассмотреть (Code Collaborator и Crucible)
Тогда ещё несколько вопросов:
1) Используете ли вы его интеграцию с Эклипсом? Если да, то насколько она тесная (то есть, что позволяет делать - из обзора как-то не очень это понял). Если нет, то насколько комфортно просматривать код через его собственный интерфейс?
Просто, понятное дело, что отдельного человека для конторля кода никто выделять не будет - значит, это обудет разработчик, у которого есть свои текущие задачи. Поэтому считаю очень важным обеспечить максимально комфортный просмотр кода (то есть с навигацией и прочим который, честно говоря, с трудом себе представляю вне привычной среды разработки (в нашем случае IDEA).
2) Какие образом Collaborator встроен в процесс разработки? То есть интересна схема работы: Разработчик завершил некую функциональность и теперь он хочет её закоммитить - что происходит дальше? а) Он коммитит в vcs и коммит автоматом отправляется на просмотр, б) Человек сам формирует диф и сам отправляет его на просмотр, а только затем, получив одобрение, коммитит в vcs, в) какой-то иной вариант
Других вариантов я придумать не могу, а в случае (а) получается, что просмотр совершается постфактум, то есть уже после того, как коммит попал в репозиторий, а в случае (б) слишком много ручной работы.
Тогда ещё несколько вопросов:
1) Используете ли вы его интеграцию с Эклипсом? Если да, то насколько она тесная (то есть, что позволяет делать - из обзора как-то не очень это понял). Если нет, то насколько комфортно просматривать код через его собственный интерфейс?
Просто, понятное дело, что отдельного человека для конторля кода никто выделять не будет - значит, это обудет разработчик, у которого есть свои текущие задачи. Поэтому считаю очень важным обеспечить максимально комфортный просмотр кода (то есть с навигацией и прочим который, честно говоря, с трудом себе представляю вне привычной среды разработки (в нашем случае IDEA).
2) Какие образом Collaborator встроен в процесс разработки? То есть интересна схема работы: Разработчик завершил некую функциональность и теперь он хочет её закоммитить - что происходит дальше? а) Он коммитит в vcs и коммит автоматом отправляется на просмотр, б) Человек сам формирует диф и сам отправляет его на просмотр, а только затем, получив одобрение, коммитит в vcs, в) какой-то иной вариант
Других вариантов я придумать не могу, а в случае (а) получается, что просмотр совершается постфактум, то есть уже после того, как коммит попал в репозиторий, а в случае (б) слишком много ручной работы.
Тулзы используются внутренние.Из всех известных мне компаний подобные внутренние тулзы, вроде, только у гугла
А каким образом ваши внутренние тулзы встроены в процесс разработки (вопрос номер 2 постом выше)?
Разные тулзы.А названия?
И аналогичный вопрос насчёт их места в процессе разработки.
Из всех известных мне компаний подобные внутренние тулзы, вроде, только у гуглану, у меня такая же информация
А каким образом ваши внутренние тулзы встроены в процесс разработки (вопрос номер 2 постом выше)?Делаешь CL в Perforce, mondrian подхватывает CL. После этого просишь (либо через web интерфейс, либо из коммандной строчки) кого-то поревьювить, он смотрит, может оставлять комменты в mondrian прямо в snapshot-е твоего кода. Ты исправляешь замечания, он тебе говорит LGTM, и нажимает кнопочку Approve. После этого у тебя появляются права на submit.
>Из всех известных мне компаний подобные внутренние тулзы, вроде, только у гугла
а как же
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...
это если речь про coding style
а как же
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...
это если речь про coding style
Не, code style это за компанию упомянул. Его и IDEA сама проверить может, и плагины соответствующие есть.
А вопрос был именно по организации процесса ручного просмотра (например, на предмет быдлокода) изменений, которые собираются закоммитить в репозиторий.
А вопрос был именно по организации процесса ручного просмотра (например, на предмет быдлокода) изменений, которые собираются закоммитить в репозиторий.
С идеей интеграции нет (может, уже есть, надо глянуть единственно, оно предоставляет возможность предъявить свою diff-утилиту - я это не использую. Так что с интеграцией плохо (ага, навигации нет, по коду погулять нельзя, это да, напрягает). Используется вариант б. Ручной работы нет, надо в консоли набрать что-то вроде "ccollab addchanges new ."
Либо через гуёвину, но имхо она от лукавого. Это при условии наличия перевариваемой тулой vcs. Смотрим, когда время на это есть, то есть не отрываемся от работ насущных. Да, это сильно замедляет разработку, но есть мысль что на исправление (а находится и исправляется немало) ушло бы существенно больше времени. Иногда когда review-ров много (обычно, это заинтересованные, то есть те, чью функциональность так или иначе затронули процесс сходится долго. Код рассматривается на предмет адекватности и читаемости.
Либо через гуёвину, но имхо она от лукавого. Это при условии наличия перевариваемой тулой vcs. Смотрим, когда время на это есть, то есть не отрываемся от работ насущных. Да, это сильно замедляет разработку, но есть мысль что на исправление (а находится и исправляется немало) ушло бы существенно больше времени. Иногда когда review-ров много (обычно, это заинтересованные, то есть те, чью функциональность так или иначе затронули процесс сходится долго. Код рассматривается на предмет адекватности и читаемости.
Ну вот тут описан один из вариантов организации рыботы тысяч программистов в одном проекте.
http://ldn.linuxfoundation.org/how-participate-linux-communi...
2.2: THE LIFECYCLE OF A PATCH как раз про review
ну и в других местах есть
http://ldn.linuxfoundation.org/how-participate-linux-communi...
2.2: THE LIFECYCLE OF A PATCH как раз про review
ну и в других местах есть
у нас на работе аналогичный процесс: ccollab в кмдлайне (гуй не адекватен дефекты, комит, тормоза в разработке, улучшение качество кода.
Оставить комментарий
ifani
Интересно стало, практикуется ли у кого-нибудь на работе Code Review (просмотр закоммиченного кода на предмет соблюдения code style, грамотного комментирования, используемых алгоритмов и т.д.)? И если да, то более интересный мне вопрос - как это организовано, какие тулзы используются и т.д.?