Comments 29
UFO landed and left these words here
Спасибо за отзыв.

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

Однако, статья всё-таки очень беглая и поверхностная.
Но тем не менее статья раскрывает важную истину. Кому нужна конкретика — теперь знает в каком ключе копать.
«Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live» (С)
Я приведу перевод:

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете

Стив Макконнелл «Совершенный код»
Недавно, ставя процесс разработки в компании всего четырех человек, столкнулись с подобной проблемой. А именно: один человек пишет, второй полночи рецензирует и правит, с утра второй выдает претензии первому, а тот кричит о том, что если у него такой плохой код, то почему он работает, и если его постоянно переделывают — то зачем он вообще работает?) И было много всего, что тут описано, причем проблема решилась, по крайней мере приостановилась, за счет как раз подхода XP — их посадили в пару.
Считаю, впрочем, что рецензирование важно для всех участников процесса, по крайней мере нам, как мне кажется, оно дало очень многое, хотя и не без описанных проблем. Но пользы точно больше)
Иногда просто с ума сходишь, когда на проекте меняется программист.
На проект потрачено 400 часов, и тут он тебе заявляет, что по-хорошему надо всё переписать: «Выделите только мне на это несколько часов».
В итоге ты не соглашаешься и оказывается, что через неделю он все-таки умудрился всё это переписать :)
Спасибо за перевод, было интересно почитать.

Сейчас подумываю о том, что как только появится больше опыта, будет полезно присоединиться к какому-нибудь небольшому open source проекту, но вот нигде не встречал статей или руководств «как начать»…
а что тут сложного? находишь проект который тебе нравится смотришь в местный багтрекер и чтонить простое делаешь. О том как извлекать код из репозитория и делать патчи мануалов море.
Тут главное начать и не боятся сложностей. Всегда есть куча мелких багов до которых руки не доходят. А для неопытных они самое то.
А слово «ревизия» вы сами придумали? Просто обычно так переводится слово revision, которое есть единичное изменение в системе контроля версий. Даже не сразу понял что вы о code review речь ведёте.
Я же не спорю с тем, что такое слово есть. Но использование его в качестве перевода code review мне режет слух и глаз. Возможно, только мне :)
О, хороший вопрос! :)
Вообще, я долго думал, как перевести «code review». Было три варианта:
* обзор кода;
* инспекция кода;
* ревизия кода.

Тогда я открыл Википедию, ввёл туда «code review» и получил вот эту ссылку. Там как раз и написано «ревизия».
Кстати, мне бы инспекция кода была понятнее — в одном из тулов на английском этот процесс назывался именно code inspection.
Кому-то понятнее один вариант, кому-то – другой, кто как привык.

Отсутствие общепринятого перевода некоторых IT-терминов действительно создаёт проблемы, приходится смотреть по контексту. Те же «design patterns» кто-то называет шаблонами, а кто-то паттернами.

А в нашем случае даже в англоязычных терминах нет согласья: в статье «review», у вас — «inspection».

Что поделать – «трудности перевода» ©. :)
Я тоже пока не прочитал несколько абзацев не мог понять о чём идёт речь. За ревизией уже закрепилось значение как «версия» кода. потому лучше всё таки было использовать другие варианты. Та же инспекция кода.
Классно! Спасибо за перевод, нашел у кого-то в блоге ссылку на статью, было лень читать на английском. :)
Отличная статья. Вот бы еще и инструмент хороший для ревью кода, а за одно и для подготовки патчей с отложенным комитом для ревью под SVN или CVS. Я делаю ревью кода разработчиков при чекауте. В этом случае код уже в репозитории и процедура его изменения (пинать автора или писать ему письмо) очень трудоемкое занятие. Я видел пару платных инструментов типа гугловского мандриана (видел демо около года назад и оценил общую концепцию) но они заточены под систему контроля версий которая умеет делать отложеные комиты.
Посмотрите на Git. Попробуйте схему, когда патчи мёрждат рецензенты.
Спасибо, гит я использовал. Не хватает пока ему нормальной визуальной поддержки, а заливаться из текстовой консоли напрягает. (раньше приходилось для него cygwin ставить)
Пробовали tortoisegit?

Сам не кушал, но ходят слухи, что программа уже вполне на уровне.

Да и, признаться, консоль не так плоха. Любимые команды можно заальясить, стандартные операции автоматизировать скриптами. Git настолько хорош, что его вроде как уже даже умудрились на C# портировать.
smartbear.com/
Не без недостатков, но хорошая штука. Хотя и тоже платная. Впрочем, кряки находятся без проблем :)

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

Мы в итоге купили, поюзав месяца с два.
да, smartbear видел, хорошо сделали, вот именно такой системы и не хватает для полного счастья. Кстати сейчас у них акция лицензия на 5 юзеров за 5 баксов. Сейчас куплю.
В MediaWiki используется специальная система. Право ставить статус «ok» (или resolved) имеют права два главных разработчика. Право ставить fixme и другие статусы имеют почти все основные разработчики.

Процесс обновления движка на Википедии выглядит так. Когда у основных разработчиков появляется время, то они просматривают все изменения и ставят ok/fixme/reverted. Потом, когда все fixme исправляются, движок обновляется к новой версии (при этом часто возникает необходимость обновить структуру базы данных, что может быть весьма долго и трудно) и, после проверки в живых условиях на специальном сайте, запускаются глобально.
Only those users with full accounts are able to leave comments. Log in, please.