Comments 33
Посмотрите Gitlab, там недавно появилась фишка с merge requests, что вполне подходит для Code Review.
В принципе, все то же самое на уровне прав записи в ветки и т.п. можно сделать на gitolite — поговаривают, что и веб-морда к нему есть, но я еще не успел попробовать.
Гитлаб, упомянутый в комментарии выше, как раз и основан на гитолит.
К сожалению почему то для 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? У меня почему-то имя пользователя отображается всегда знаками вопроса…
Что-то подобное по-моему было, решилось вот этим, если я правильно помню:
[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 из коробки?
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

Since 2006

Location

Россия

Website

badoo.com

Employees

201–500 человек

Registered

15 December 2009

Habr blog