Модерация. Как реализовано у вас?

Друзья, добрый день.
Поделитесь опытом. Стоит задача построить процесс модерации ораклового кода. С целью:
1. соблюдения внутреннего регламента
2. избежать выпуска ляпов в релиз.

Интересуют следующие аспекты
1. Какая система контроля версий используется
2. Что проверяется в момент модерации? Учитывается ли семантика задачи? Заключение выдается субъективное или ссылкой на регламент.
3. Кто инициирует модерацию. Разработчик или модерируются все коммиты на определенную ветку.
4. Занимаются выделенные люди или все по немногу
5. Какие технические инструменты используются. Например для автоматизации проверок, автоматизации обмена сообщениями между модератором и разработчиком
6. Другие важные на ваш взгляд моменты.

jigan,

"модерация" как ты ее называешь имеет мало отношения к системе конроля кода.
Она имеет оношение к процессу разработки.
В примитивном виде dev -> code review -> test.
Все три фазы выполняются разными людьми, задача переходит от одного к другому (и обратно при необходимости) по мере выполнения.

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

dbms_photoshop

jigan, "модерация" как ты ее называешь имеет мало отношения к системе конроля кода. Она имеет оношение к процессу разработки. В примитивном виде dev -> code review -> test. Все три фазы выполняются разными людьми, задача переходит от одного к другому (и обратно при необходимости) по мере выполнения. Выжный момент, что все должно быть формализировано по возможности, но в разумных пределах. Все таки успех проекта в конечном итоге зависит от определенных личностей. Так что если команда по большой части состоит из бездарностей, то как не организовывай процесс - будет получаться говнокод.

Она может иметь отношение, если используются встроенные инструменты в CVS систему, слышал например в гите есть возможность обмениваться сообщениями между исполнителем и модератором кода.
Написал модерация а не ревью, так как ревью в моем понимании требует погружение я семантику задачи, а модерация быстрый просмотр на наличие ляпов и регламента.
Про личностей не спорю, но это не имеет отношения к процессу. Сам раньше так считал и частично продолжаю считать. Но с опытом и ростом команды и числа проектов, внешними командами, приходишь в выводу что все твои прошлые мысли это отмазки чтобы не сделать нормальный процесс.
Вопрос dev -> code review перехлодит как, разработчик явно ставит задачу?

jigan
слышал например в гите есть возможность обмениваться сообщениями между исполнителем и модератором кода

Какие нафиг сообщения? Есть workflow или определенная последовательность действий и смены состояний по русски.
Закончивший работать над задачей меняет ее состояние dev->review или review->dev (если review failed) и привязывает (assign) задачу к "новому адресату". Вновь получивший задачу получает уведомление по почте или другим путем от системы* в атоматическом режиме.

jigan
Вопрос dev -> code review перехлодит как, разработчик явно ставит задачу?

Ревьювщик в задаче может посмотреть что необходимо сделать и задать уточняющие вопросы разработчику/постановщику при необходимости.
Дальше он анализирует сделанное на соответвие необходимому и удовлетворению стандартам разработки.

jigan
Про личностей не спорю, но это не имеет отношения к процессу. Сам раньше так считал и частично продолжаю считать. Но с опытом и ростом команды и числа проектов, внешними командами, приходишь в выводу что все твои прошлые мысли это отмазки чтобы не сделать нормальный процесс.

Не стоит свои рефлексии обобщать на всех. Я сказал в точности то, что хотел сказать.
Я сторонник делать единообразным и оговоренным в стандарте все начиная от имен сущностей и переменных и заканчивая пользованием beautifier с одинаковыми настройками всеми членами команды.
Но формализировать нормальный код точки зрения перфоманса крайне затруднительно.
Если человек деревянный в вопросах перфоманса и не умеет делать номальный дизайн - ему это не поможет.

*система = Issue tracking system

Хренак, хренак и в продакшн.

jigan,

автор
1. соблюдения внутреннего регламента

C этой задачей, как уже упоминалось, справится Issue Tracking System а-ля JIRA и
вот такой продукт и PL/SQL плагин к нему.
Недостаток последнего - платный, но "любой каприз за ваши деньги"...

автор
2. избежать выпуска ляпов в релиз.

Полностью избежать не выйдет, но если не проводится хотя бы тестирование - все остальное просто не имеет смысла.

автор
1. Какая система контроля версий используется

SVN

автор
2. Что проверяется в момент модерации?

Как таковой модерации не используется (кроме редких случаев критических участков кода).
Все необходимые для корректного коммита данные проверяются Hook-скриптом.
При деплойменте на тестовые/продуктивные среды ДБА проверяют корректность коммита на соответствие внутреннему регламенту.
Большая часть этой проверки также автоматизирована (на AFTER DDL триггере).

автор
6. Другие важные на ваш взгляд моменты.

Лучше иметь небольшое количество толковых Oracle-разработчиков, которые следуют внутренним Регламентам, имеют высокие профессиональные навыки и не косячат на пустом месте, чем большое количество Junior, Low-Middle разработчиков.

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

Если же необходимо обеспечить соблюдение Регламентных процедур, то нужно стараться максимально автоматизировать этот процесс. С помощью стороннего софта или внутренними разработками...

Amberit
Недостаток последнего - платный, но "любой каприз за ваши деньги"...

В чем преимущества последнего?
Джира прекрасно скрещивается с SVN и можно без проблем смотреть во вкладочке source конретного issue какой код был (какие файлы) изменен.
Вдобавок можно прикрутить желаемую програмулины для сравнения исходной версии и измененной.

Amberit
Все необходимые для корректного коммита данные проверяются Hook-скриптом.

Как интересно подобный скрипт проверит если альтернативно одаренная личность сделала код, который делает 15 раз full scan вместо 1 full scan + case.
Я такой шедевр наблюдал буквально на прошлой неделе.

Amberit
Лучше иметь небольшое количество толковых Oracle-разработчиков, которые следуют внутренним Регламентам, имеют высокие профессиональные навыки и не косячат на пустом месте, чем большое количество Junior, Low-Middle разработчиков.

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

Как-то 7 лет назад был я на семинаре Database Options Details и там была картинка как пастух ведет стадо баранов, при этом следует позади.
Суть (по заыслу организаторов) сводилась к тому, что пастуху не надо бежать впереди паровоза, а главное направлять стадо в нужное русло.
Потом как оказалось по отзывам многих эта картинка оскорбила, а мне очень даже понравилась. :)

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

Собственно картинка и показывает отличие хорошего архитектора от плохого +

dbms_photoshop,

автор
В чем преимущества последнего?

Например, отлавливание говнокода вида WHEN OTHERS THEN NULL; проверка наличия блока EXCEPTION вообще, отсутствия стандартизированного комментария перед процедурой и т.д. и т.п. (на что хватит фантазии и возможностей описать средствами встроенного языка либо регулярными выражениями)...

Существует достаточно мощный шаблонизатор правил, многие встроенные по дефолту тоже достаточно полезны. На 30 дней дают триальный период, по запросу через e-mail триальный период без проблем продлевают. Но при этом достаточно навязчиво предлагают купить, дабы навсегда забыть о головной боли и стать полноценным обладателем этой чудо-таблетки...

автор
Как интересно подобный скрипт проверит если альтернативно одаренная личность сделала код, который делает 15 раз full scan вместо 1 full scan + case.

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

Этот модуль предназначен для контроля регламентов именно с точки зрения FrameWork'ов и технической части. Для WorkFlow JIRA хватает с головой...

автор
В экстремальном случае может быть вообще один толковй архитектор

На 2-3 разработчиков еще хватит. Больше уже зашиваться начнет. Хотя многое зависит от объема изменяемого кода и вменяемости изменяющих код. ИМХО.

автор
а главное направлять стадокоманду в нужное русло.

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

Всем отписавшимся спасибо, я услышал как у вас.
Продолжаю собирать опыт, отписываемся по пунтам.
Не нужно тут писать полезна или нет модерация, сколько каких разрабов брать. Это решается на другом уровне по текущим объемам проектов. Задача построить грамотно процесс и посмотреть кто какими инструментами пользуется. Подключать планируется любое кол-во разработчиков, отдельные команды, аутсорс.