Некоторые компании проводят обзоры кода, чтобы реализовать свое собственное стремление к совершенству разработчика и снизить стоимость производственных дефектов или невозможности обслуживания кода. Другие делают это потому, что регуляторы или даже клиенты просят их продать продукт или услугу за пределами своей организации. Несколько дней назад я утверждал, что наиболее эффективный процесс проверки кода — это процесс проверки в течение нескольких минут после принятия, к которому они относятся. Я не особо останавливался на разнице между проверками до фиксации (то есть, пока они не «пройдут», фиксация не может быть выполнена) и проверками после фиксации (которые предполагают приоритетную последующую работу в случае «неудачи» «).
Где хранятся «записи» проверки кода?
В BigTable (разреженная, распределенная многомерная отсортированная карта Google)
- Google Мондриана. Частный Google, конечно
- Rietveld использует BigTable через AppEngine (для всех)
В обычной реляционной схеме
- Тигель — Oracle, SqlSever, Maria / MySQL или Postgres
- CodeCollaborator — Oracle, SqlSever, Maria / MySQL
- Геритт — MySQL / Мария или PostgreSQL
- Phabricator — MySQL
А как насчет этих записей в Source-Control вместо этого?
Учитывая, что различия для коммитов исходят из системы Source-Control, есть вероятность, что Source-Control может быть местом, где могут храниться обзоры. Это может быть ветвь одной и той же системы контроля версий, но нет смысла объединять ветки. Это привлекательно, поскольку система аутентификации для коммиттеров для одной ветви по умолчанию такая же, как и система аутентификации для другой ветви. Возможно, проще всего иметь отдельный репозиторий, который связан только по соглашению, но с внутренней конфигурацией они могут совместно использовать аутентификацию:
диверсия
http://svn.mycompany.com/trade_engine (has trunk, tags, branches) http://svn.mycompany.com/trade_engine_reviews (has no trunk, tags, branches)
Гит
git://git.mycompany.com/trade_engine.git (has directories - master and others) git://git.mycompany.com/trade_engine_reviews.git (has just master)
смешанный
git://git.mycompany.com/trade_engine.git (has directories - master and others) http://svn.mycompany.com/trade_engine_reviews (has no trunk, tags, branches)
Обзор как отдельный документ JSON?
Из статьи «Непрерывный обзор», которая была опубликована несколько дней назад , ниже приведено описание последнего коммита в стволе:
ph7785:svn_workingcopy paul$ svn diff -c 5 Index: trunk/file.txt =================================================================== --- trunk/file.txt (revision 4) +++ trunk/file.txt (revision 5) @@ -1,4 +1,4 @@ -Efficiently unleash socially-awkward information without +Efficiently unleash tie-dyed information without any value. Dramatically -maintain clicks-and-mortar solutions without +maintain empirical solutions without functional aspects.
Как видите, diff довольно компактен. Я думаю, что было бы лучше хранить в формате JSON. Если бы это было так, это было бы немедленно совместимо с веб-технологиями, такими как AngularJS.
В этом сообщении фиксации отсутствуют некоторые важные вещи (кто это сделал, когда и т. Д.), Которые можно извлечь из второй команды:
ph7785: paul$ svn log -c 5 ------------------------------------------------------------------------ r5 | harry | 2013-12-04 17:07:04 -0500 (Wed, 04 Dec 2013) | 1 line follow-up change on trunk ------------------------------------------------------------------------
Конечно, мы бы объединили их вместе.
JSON-версия diff
Вот что я думаю (5.json):
{
"who": "harry"
"when": "2013-12-04 17:07:04 -0500",
"message": "follow-up change on trunk",
"changes": [
{
"index": "file.txt",
"to": "file.txt (revision 3)",
"from": "file.txt (revision 5)",
"chunks": [
{
"locn": "-1,4 +1,4",
"lines": [
"-Efficiently unleash cross-media information without",
"+Efficiently unleash sexed-up information without",
"-maintain clicks-and-mortar solutions without",
"+maintain empirical solutions without",
" functional aspects."
]
}
]
}
]
}
С этой целью я задал вопрос о StackOverflow несколько дней назад . Я был обеспокоен кучей команд Unix sed, собранных вместе, чтобы превратить diff в JSON, и уместностью того, что я сделал. Бен Ресер (команда разработчиков Subversion и сотрудник WanDisco) присоединился к Python, что было бы лучше в долгосрочной перспективе.
Я бы предпочел, чтобы ‘svn diff’ принимал командную строку arg ‘-json’, чтобы выложить сам формат JSON, но это большая работа для команды Svn.
В любом случае, следуя принципам работы инструментов проверки кода, я вижу, что обзоры на уровне файлов могут выглядеть примерно так:
{
"who": "harry"
"when": "2013-12-04 17:07:04 -0500",
"message": "follow-up change on trunk",
"changes": [
{
"index": "file.txt",
"to": "file.txt (revision 3)",
"from": "file.txt (revision 5)",
"chunks": [
...
],
"reviews": [
"review": {
"who": "paul",
"when": "2013-12-07 14:58",
"what": "Great Work"
"status": "LGTM"
}
]
}
]
}
Также будет необходимость в комментариях к строкам:
{
"who": "harry"
"when": "2013-12-04 17:07:04 -0500",
"message": "follow-up change on trunk",
"changes": [
{
"index": "file.txt",
"to": "file.txt (revision 3)",
"from": "file.txt (revision 5)",
"chunks": [
{
"locn": "-1,4 +1,4",
"lines": [
"-Efficiently unleash cross-media information without",
"+Efficiently unleash sexed-up information without",
"reviews": [
"review": {
"who": "paul",
"when": "2013-12-07 14:58",
"what": "Should use alternate to 'Sexed-up'; Too 'Malcolm Tucker'"
"status": "REWORK-NEEDED"
}
]
"-maintain clicks-and-mortar solutions without",
"+maintain empirical solutions without",
" functional aspects."
]
}
],
"reviews": [
"review": {
"who": "paul",
"when": "2013-12-07 14:58",
"status": "REWORK-NEEDED"
}
]
}
],
"rollup_status": "REWORK-NEEDED"
}
Разработка приложения вокруг этой идеи
С очень небольшим количеством строк кода мы могли бы создать систему обзора, которая работает достаточно хорошо для повестки дня «обзор всех коммитов (на транке) как можно скорее». Мы были бы открыты о том, какие технологии на среднем уровне, но предложили бы что-то минимальное (Sinatra — мой подход):
Опять же, мы также не знаем, какая серверная технология для «управления исходным кодом», с Subversion, только перечисленной на этой диаграмме, как наиболее известный выбор. Кстати, я даже не начал это кодировать, хотя было бы весело.
Source-Control как бэкэнд для обзоров — правда ??
Да, я вообще думаю, что Source-Control является жизнеспособным хранилищем для некоторых типов приложений, и, как правило, может быть некоторая конвергенция между инструментами управления исходным кодом и хранилищами key-val / doc .
Плюсы и минусы
Вот еще несколько причин, почему Source-Control подходит:
- Различия в форме JSON — это хорошо структурированные текстовые файлы с разделителем-кареткой
- Постепенное перезапись одного и того же документа снова и снова, если он постоянно печатается, ведет к чистому и авторитетному аудиту
- Непосредственно не помогает соблюдению Sarbanes Oxley, но успокоит регуляторов / клиентов, упомянутых в начале статьи.
- Возможность доступа к данным (и их истории) без промежуточного уровня — непосредственно из кассы — может быть хорошим способом инициировать пакетный анализ проверок аудиторами и т. Д.
Это не все розы, хотя:
- В коммите / рецензии JSON, как он есть, содержатся все рецензии. На промежуточном уровне должна быть проверка непротиворечивости, чтобы гарантировать, что каждый предыдущий отзыв для той же самой фиксации так или иначе не изменяется, когда последние рецензенты взвешивают свой комментарий к обзору
- Не все технологии Source-Control готовы быть бэкэндами для произвольного хранения документов, и возможности запросов к ним в основном незрелые. Subversion, например, может выступать в качестве бэкэнда WebDAV, и этого может быть достаточно для необходимого взаимодействия GET / PUT, которое необходимо без непреднамеренного использования. У всех есть API для взаимодействия, но не все так просто для написания кода
- Source-Control не может удержаться,
unreviewed_commits.jsonесли там хранится индекс - Два человека, одновременно проверяющие один и тот же коммит, имеют проблему «кто доминирует / как объединить», если есть «средний уровень», пытающийся организовать это (по крайней мере, без семантического слияния )
- JSON отличается от двоичных файлов? Хммммм
И есть некоторые аспекты управления исходным кодом, которые просто не применяются:
- Сообщения коммита для каждого этапа отдельного обзора будут высоко структурированы, тогда как обычно вы подробно объясняете
- Ветки в репозитории отзывов, не имеют смысла
Другие факторы
- Для основного репозитория, который запустил разностную распаковку, нужно было бы выполнить триггер фиксации, превратить его в JSON, распечатать его ( jshon ) и поместить в репозиторий обзоров (как показано на диаграмме).
- Вам может понадобиться способ восстановить предметы, которые были пропущены, если курок по какой-то причине сломался на мгновение
- Вам все еще понадобится обычная база данных, для которой элементы еще не проверены, как показано на диаграмме выше
- Нужно создать способ перестроения этого индекса
- Вы можете сойти с простого документа, расположенного в текущем каталоге, так как он очень маленький
Наконец, вы не сможете хранить рабочую копию на стороне сервера для каждого рецензента. Вместо этого вам нужно будет получать все документы из бэкэнда Source-Control всякий раз, когда они необходимы. В веб-приложении AngularJS (или эквивалентном) для этого, которое не обсуждалось слишком много, большая часть действия после предоставления «текущего» состояния обзора находится на самой странице. Только когда нажата кнопка «Сохранить / отправить», JSON возвращается к веб-технологии среднего уровня в виде PUT, который затем красиво печатает, проверяет и отправляет его в инструмент управления исходным кодом, управляющий репозиторием обзора.
Также Читайте …
- Документ — это контракт на тип приложения JavaScript MVC, которое я предлагаю.
- Данные отеля управляются в Source-Control как часть открытых данных, подкрепленных записью в блоге source-control .
- Источник-Control при поддержке приложения Sinatra для приложения-конфигурации . Начатый в Github, более полной версии в Perforce и порте Subversion, который находится в стадии разработки.
И Hotel-Data, и App-Config-App намеренно объединяют технологию шаблонов Web 1.0 (Sinatra) с современной средой JavaScript MVC (Angular).