Pull to refresh

Comments 34

Посмотрите Gitlab, там недавно появилась фишка с merge requests, что вполне подходит для Code Review.
В принципе, все то же самое на уровне прав записи в ветки и т.п. можно сделать на gitolite — поговаривают, что и веб-морда к нему есть, но я еще не успел попробовать.
Гитлаб, упомянутый в комментарии выше, как раз и основан на гитолит.
Мы юзаем Phabricator. Хорошая штука, когда вообще есть время на ревью.
А он svn поддерживает?
Supports: Git, Subversion, and Mercurial, прям на главной странице написано.
К сожалению почему то для Git все инструменты Code Review требуют чтобы все коммиты шли через их репозиторий. Из за этого какое решение не выбери придется переделывать управление Git проектами и меня везде адреса репозиториев куда пушить. Почему то нет не одного бесплатного решения для Git с Post-Commit Review как в Crucible, это бы позволило не менять бы столько вещей для внедрения Code Review.
Ну, в нашем случае требовалось именно pre-commit review.
Вообще, на мой взгляд от пост-ревью немного толка — сам факт того, что оно «пост» расслябляет.
pre-commit review конечно лучше, но нужно тогда много чего поменять при переходе на него и разъяснить каждому как с ним работать. с post-commit все намного проще в этом плане
А у вас получилось заставить Gerrit нормально отображать русские комментарии к коду? У меня так и не получилось.
У меня получилось, должно быть правильно настроено соединение с базой, ну и база должна быть в utf8. Про это у них даже есть баг, но можно и воркараундом обойти:
[database]
        type = MYSQL
        driver = com.mysql.jdbc.Driver
        url = jdbc:mysql://localhost/reviewdb?characterSetResults=utf8&characterEncoding=utf8&connectionCollation=utf8_unicode_ci&sessionVariables=storage_engine=InnoDB
Сейчас точно не помню но поле этого шага были еще какие-то проблемы с Gerrit из за того что база стала в Utf8
Хм. Удивительно, что мы на это еще не натолкнулись до сих пор.
Действительно, такая проблема есть: code.google.com/p/gerrit/issues/detail?id=1082

Я решил так — в my.cnf добавил вот эти строки:
[mysqld]
default-collation=utf8_unicode_ci
default-character-set = utf8

Перегрузил MySQL, теперь русский в комментариях работает.
[offtop]
за русские комментарии руки бы поотрывал
равно как и за транслитерированные названия методов, переменных, классов…

хотите программировать и комментировать по-русски — учите 1С
[/offtop]
Как это связано вообще?? Код на английском, а коментарии в code review должны быть на том языка на котором проще всего общаться внутри фирмы.
Извините но не каждый сможет вести дискуссию о своем коде на английском.
а, пардон. комментарии к коду (в дискуссии) — ок
воспринял проблему как «русские комментарии в коде»
а остальное наболело от примеров кода испанских и итальянских программистов
Ок, а чем вам мешают комментарии на русском языке в коде?
1. код рано или поздно может (в силу тех или иных причин) выйти за рамки со-язычного гетто и комментарии прийдется тупо переписывать? не всегда вся логика понятна из кода (или не всегда понятны причины именно примененной логики)
2. зачастую это перемеживается с использованием транслита в названиях переменных/методов/классов что выглядит очень плохо. один из многих типичных примеров того, что присылают кандидаты (в данном случае испанец):
public function atenderSuscripciones()
 {
   //Primero miramos si tiene suscripcion con tipo : Obra
   $c = new Criteria();
   $c->add(SuscripcionPeer::SUS_TIPO,'obra');
   $c->add(SuscripcionPeer::SUS_CLAVE,$this->getEdiObra());

   $suscripcionesObra = SuscripcionPeer::doSelect($c);

   $this->hacerPedido($suscripciones);

   //Ahora por tipo: autor

   $autores = $this->autoresID();

   $c = new Criteria();
   $c->add(SuscripcionPeer::SUS_TIPO,'autor');
   $c->add(SuscripcionPeer::SUS_CLAVE,$autores,Criteria::IN);

   $suscripcionesAutor = SuscripcionPeer::doSelect($c);

   $this->hacerPedido($suscripcionesAutor);
   //A continuacion, por tipo: coleccion

   $autores = $this->autoresID();

   $c = new Criteria();
   $c->add(SuscripcionPeer::SUS_TIPO,'coleccion');
   $c->add(SuscripcionPeer::SUS_CLAVE,$this->getEdiColec());

   $suscripcionesColeccion = SuscripcionPeer::doSelect($c);

   $this->hacerPedido($suscripcionesColeccion);


   //Y por �ltimo, por tipo: materia

   $c = new Criteria();
   $c->add(SuscripcionPeer::SUS_TIPO,'materia');
   $c->add(SuscripcionPeer::SUS_CLAVE,$this->materiaId());

   $suscripcionesMateria = SuscripcionPeer::doSelect($c);

   $this->hacerPedido($suscripcionesMateria);
 }


есть еще масса примеров хорошо документированного кода, но тоже на испанском или итальянском. что демонстрирует такой код германскому проекту с британскими корнями и разноязыкими разработчиками? то что хакер педидо?
3. вырабатывается привычка такого образа ведения кода, которую потом сложно исправить (то, к чему человек привыкал годами не выкорчевать за недели/месяцы)
4. в большинстве (не во всех случаях, но в большинстве) случаев качество кода и программиста оказывается относительно невысоким. скорее всего это характеризует образ мышления.
обратное правило не работает — если все на pure english — это конечно не означает, что человек гуру =)
1. код рано или поздно может (в силу тех или иных причин) выйти за рамки со-язычного гетто и комментарии прийдется тупо переписывать? не всегда вся логика понятна из кода

a) На деле не встречал и даже не слышал отдаленно. Если проект у мультиязычной компании, то принимается соглашение о комментариях
б) Есть у меня золотое правило, хочешь написать комментарий — перепиши код.

2. зачастую это перемеживается с использованием транслита в названиях переменных

Кто говорит о наименовании переменных? Я написал про комментарии.

3. вырабатывается привычка такого образа ведения кода, которую потом сложно исправить

Что сказать то хотели по делу?

4. в большинстве (не во всех случаях, но в большинстве) случаев качество кода и программиста оказывается относительно невысоким. скорее всего это характеризует образ мышления.

Опять не понял, при чем тут это, в разрезе моего тезиса про русскоязычные комментарии.
Но, если разработчики, скорее всего не очень квалифицированные, то их комментарий на русском понять будет, скорее всего, проще чем на ломанном английском(в перемешку с транслитом). Да и напишут они на русском больше, нежели чем на английском.

Резюме.
В сухом итоге, ничего против русскоязычных комментариев высказано не было.

На деле не встречал и даже не слышал отдаленно. Если проект у мультиязычной компании, то принимается соглашение о комментариях

компании открывают офисы в других странах, компании покупаются другими компани и сливаются с ними, происходит различный обмен знаниями и т.п. и такое происходит достаточно часто.
а иногда даже писанные сугубо для себя исходники попадают в чужие руки. хотя бы в качестве примера кода при поиске работы.
Компании открывают офисы в других странах, компании покупаются другими компани и сливаются с ними, происходит различный обмен знаниями и т.п. и такое происходит достаточно часто.

Процент таких компаний, думаю очень небольшой(наберется процент ли?)

В подавляющем же большинстве случаев, как я уже писал выше, комментарии на русском языке смотрятся предпочтительнее.
спор становится бесперспективным — мне давно не приходилось работать с компаниями бесперспективно-ориентированными исключительно на локальный рынок, а вам, видимо, не приходилось работать в других компаниях.

явно каждый останется при своем.

кстати, комментарии на русском вас смотрятся предпочтительнее с какой позиции? разработчика, архитектора, тестера, технического менеджера, бизнес-менеджера, и тп?

Разработчика — корявыие и куцые английские комментарии нед оставляют радости.

Архитектора — комментарий анотации должны легко пояснить, что делает метод даже студенту 3 курса.

Менеджера — не нужно думать о том, что кто-то плохо знает английский.
А еще он прекрасно поддерживает аутентификацию через LDAP
Я бы всё-таки предпочел обычную таблицу пользователей в базе данных.
Ну и интерфейс для управления ими впридачу.
А не было ли проблем с русскими именами в LDAP? У меня почему-то имя пользователя отображается всегда знаками вопроса…
Что-то подобное по-моему было, решилось вот этим, если я правильно помню:
[database] type = MYSQL driver = com.mysql.jdbc.Driver url = jdbc:mysql://localhost/reviewdb?characterSetResults=utf8&characterEncoding=utf8&connectionCollation=utf8_unicode_ci&sessionVariables=storage_engine=InnoDB
Ну и в БД должны быть все таблицы в utf8
А можно ли в Gerrit ревьюить не отдельные комиты и бранчи целиком? Т.е. если я работаю по git-flow я хочу ревьюить фичу или багфикс в целом (возможно это N комитов в отдельном бранче).
Я такого не помню, к сожалению.
Кстати, с Геррита мы уже ушли на самописное решение для review + интеграцию с Jira.
А это решение ваше способно с ветками работать? В опенсорс не планируете выложить?
Наше решение работает только с feature branches и сделано на основе gitphp версии 0.2.4. Скорее всего мы его не будем выкладывать в таком виде в опенсорс, потому что:

— почти все изменения являются специфичными для нашего workflow
— сам gitphp весьма далеко ушел от того вида, в котором он был в версии 0.2.4: портирование всех изменений займет много времени
— также там есть много кода для интеграции с JIRA, нашим gitosis и прочее, которое нам придется оттуда выпиливать

Тем не менее, есть некоторые правки (например, «драматически» улучшающие производительность), которые мы уже адаптировали к последнему мастеру и даже выложили (об этом будет отдельная статья, сроки назвать не могу). В общем, наша система ревью сильно заточена под наш стиль разработки и вряд ли мы будем это выкладывать.
Поддерживает ли Gerrit авторизацию в Git репозитории по ssl из коробки?

Где, собственно, исполняется программа Gerrit? Локально или удаленно?

Sign up to leave a comment.