Комментарии 29
НЛО прилетело и опубликовало эту надпись здесь
«Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live» (С)
Недавно, ставя процесс разработки в компании всего четырех человек, столкнулись с подобной проблемой. А именно: один человек пишет, второй полночи рецензирует и правит, с утра второй выдает претензии первому, а тот кричит о том, что если у него такой плохой код, то почему он работает, и если его постоянно переделывают — то зачем он вообще работает?) И было много всего, что тут описано, причем проблема решилась, по крайней мере приостановилась, за счет как раз подхода XP — их посадили в пару.
Считаю, впрочем, что рецензирование важно для всех участников процесса, по крайней мере нам, как мне кажется, оно дало очень многое, хотя и не без описанных проблем. Но пользы точно больше)
Считаю, впрочем, что рецензирование важно для всех участников процесса, по крайней мере нам, как мне кажется, оно дало очень многое, хотя и не без описанных проблем. Но пользы точно больше)
Спасибо за ссылку на выступление Гвидо
Иногда просто с ума сходишь, когда на проекте меняется программист.
На проект потрачено 400 часов, и тут он тебе заявляет, что по-хорошему надо всё переписать: «Выделите только мне на это несколько часов».
В итоге ты не соглашаешься и оказывается, что через неделю он все-таки умудрился всё это переписать :)
На проект потрачено 400 часов, и тут он тебе заявляет, что по-хорошему надо всё переписать: «Выделите только мне на это несколько часов».
В итоге ты не соглашаешься и оказывается, что через неделю он все-таки умудрился всё это переписать :)
Спасибо за перевод, было интересно почитать.
Сейчас подумываю о том, что как только появится больше опыта, будет полезно присоединиться к какому-нибудь небольшому open source проекту, но вот нигде не встречал статей или руководств «как начать»…
Сейчас подумываю о том, что как только появится больше опыта, будет полезно присоединиться к какому-нибудь небольшому open source проекту, но вот нигде не встречал статей или руководств «как начать»…
а что тут сложного? находишь проект который тебе нравится смотришь в местный багтрекер и чтонить простое делаешь. О том как извлекать код из репозитория и делать патчи мануалов море.
Тут главное начать и не боятся сложностей. Всегда есть куча мелких багов до которых руки не доходят. А для неопытных они самое то.
Тут главное начать и не боятся сложностей. Всегда есть куча мелких багов до которых руки не доходят. А для неопытных они самое то.
К нам! К нам на зеленые ноутбуки и маемовские таблетки! osll.spb.ru
А слово «ревизия» вы сами придумали? Просто обычно так переводится слово revision, которое есть единичное изменение в системе контроля версий. Даже не сразу понял что вы о code review речь ведёте.
В глоссарии для subversion это слово переводится как «правка»
А как же гоголевский Ревизор? =)
Там понятие ревизии было
Там понятие ревизии было
О, хороший вопрос! :)
Вообще, я долго думал, как перевести «code review». Было три варианта:
* обзор кода;
* инспекция кода;
* ревизия кода.
Тогда я открыл Википедию, ввёл туда «code review» и получил вот эту ссылку. Там как раз и написано «ревизия».
Вообще, я долго думал, как перевести «code review». Было три варианта:
* обзор кода;
* инспекция кода;
* ревизия кода.
Тогда я открыл Википедию, ввёл туда «code review» и получил вот эту ссылку. Там как раз и написано «ревизия».
Кстати, мне бы инспекция кода была понятнее — в одном из тулов на английском этот процесс назывался именно code inspection.
Кому-то понятнее один вариант, кому-то – другой, кто как привык.
Отсутствие общепринятого перевода некоторых IT-терминов действительно создаёт проблемы, приходится смотреть по контексту. Те же «design patterns» кто-то называет шаблонами, а кто-то паттернами.
А в нашем случае даже в англоязычных терминах нет согласья: в статье «review», у вас — «inspection».
Что поделать – «трудности перевода» ©. :)
Отсутствие общепринятого перевода некоторых IT-терминов действительно создаёт проблемы, приходится смотреть по контексту. Те же «design patterns» кто-то называет шаблонами, а кто-то паттернами.
А в нашем случае даже в англоязычных терминах нет согласья: в статье «review», у вас — «inspection».
Что поделать – «трудности перевода» ©. :)
Классно! Спасибо за перевод, нашел у кого-то в блоге ссылку на статью, было лень читать на английском. :)
Отличная статья. Вот бы еще и инструмент хороший для ревью кода, а за одно и для подготовки патчей с отложенным комитом для ревью под SVN или CVS. Я делаю ревью кода разработчиков при чекауте. В этом случае код уже в репозитории и процедура его изменения (пинать автора или писать ему письмо) очень трудоемкое занятие. Я видел пару платных инструментов типа гугловского мандриана (видел демо около года назад и оценил общую концепцию) но они заточены под систему контроля версий которая умеет делать отложеные комиты.
Посмотрите на Git. Попробуйте схему, когда патчи мёрждат рецензенты.
smartbear.com/
Не без недостатков, но хорошая штука. Хотя и тоже платная. Впрочем, кряки находятся без проблем :)
позволяет ревьюить локальные изменения до чек-ина для систем, которые неумеют отложенные коммиты.
Мы в итоге купили, поюзав месяца с два.
Не без недостатков, но хорошая штука. Хотя и тоже платная. Впрочем, кряки находятся без проблем :)
позволяет ревьюить локальные изменения до чек-ина для систем, которые неумеют отложенные коммиты.
Мы в итоге купили, поюзав месяца с два.
В MediaWiki используется специальная система. Право ставить статус «ok» (или resolved) имеют права два главных разработчика. Право ставить fixme и другие статусы имеют почти все основные разработчики.
Процесс обновления движка на Википедии выглядит так. Когда у основных разработчиков появляется время, то они просматривают все изменения и ставят ok/fixme/reverted. Потом, когда все fixme исправляются, движок обновляется к новой версии (при этом часто возникает необходимость обновить структуру базы данных, что может быть весьма долго и трудно) и, после проверки в живых условиях на специальном сайте, запускаются глобально.
Процесс обновления движка на Википедии выглядит так. Когда у основных разработчиков появляется время, то они просматривают все изменения и ставят ok/fixme/reverted. Потом, когда все fixme исправляются, движок обновляется к новой версии (при этом часто возникает необходимость обновить структуру базы данных, что может быть весьма долго и трудно) и, после проверки в живых условиях на специальном сайте, запускаются глобально.
говорящая опечатка — «повешению качества кода»…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перевод: Я ненавижу тебя: твой код – хлам!