Комментарии 68
Долго ридел текст силясь чтонибудь андрерстуд.
НЛО прилетело и опубликовало эту надпись здесь
Ну нормальный такой вариант (насколько я смог выловить суть). Только это не парное программирование, а дополнительная проверка специально обученными (и оплачиваемыми!) роботами, что каждое изменение в код должным образом документируется.
не «роботами», а именно таким же точно человеком который сидит рядом.
Да и я не говорил, что это парное программирование, это некий такой компромисс и вроде как оба сидят программируют и каждый друг за другом наблюдает.
Да и я не говорил, что это парное программирование, это некий такой компромисс и вроде как оба сидят программируют и каждый друг за другом наблюдает.
Смысл парного программирования в том, что человек, у которого нет клавиатуры гораздо больше сосредотачивается не над тем, как и что пишут, а над тем, зачем пишут. В данном случае от парного программирования остается лишь то, что участников — двое.
Еще раз перечитайте мой текст, где я сказал что это парное программирование? Я сказал лишь, что это альтернатива. Так же когда ты отсматриваешь код у тебя в этот момент нет клавиатуры и ты сморишь зачем же это написано, а не как. Я всегда смотрел зачем здесь вот это изменение.
Вообще-то, это нормальная практика, которая называется Code Review и ничего общего с парным программированием не имеет. Есть даже достаточно мощные тулзы специально предназначенные для этой практики, которые позволяют автоматически рассылать код перед коммитом на оценку старшим девелоперам (которых может быть несколько), и только после получения подтверждений коммитить.
Эффект от парного программирования в том, что когда долго и жестко кодишь, иногда залипаешь на чем-то простом, вроде «что же тут за условие в коде должно быть». Два мозга вместо одного с такими задачами справляются быстрее.
Эффект от парного программирования в том, что когда долго и жестко кодишь, иногда залипаешь на чем-то простом, вроде «что же тут за условие в коде должно быть». Два мозга вместо одного с такими задачами справляются быстрее.
что бы не вводить в заблуждение — я переименовал топик.
Тогда можно чуть подробнее про организацию процесса. Есть ряд таких проблем с этой практикой — вот сидит человек, пишет, а тут бац, ему код на ревью присылают. Ему сразу надо отрываться, терять концентрацию. Или наоборот другой перегиб — писал, писал человек, закоммитил. А через день видит, что не прошел коммит и ему вспоминать, что он там вчера накодил. Интересно кто как делает, на самом деле. )
Отсматриваешь когда у тебя есть время. То есть не теряешь над своей задачей концентрации.
А вот если через день к тебе пришёл твой коммит, который не прошёл до тестера, то ты должен посмотреть и исправить, а если ты через день не можешь вспомнить что ты там написал, то представляете как в коде будет разбираться человек, который через месяц будет это поддерживать, а через год? Значит вы такую фигню написали. По хорошему день назад тебе достаточно посмотреть на код и ты вспоминаешь, а вот если дольше, то уже только если хороший код.
А вот если через день к тебе пришёл твой коммит, который не прошёл до тестера, то ты должен посмотреть и исправить, а если ты через день не можешь вспомнить что ты там написал, то представляете как в коде будет разбираться человек, который через месяц будет это поддерживать, а через год? Значит вы такую фигню написали. По хорошему день назад тебе достаточно посмотреть на код и ты вспоминаешь, а вот если дольше, то уже только если хороший код.
Посмотрел, бросил текущую задачу, пошел исправлять, отправил, потом вернулся, дописал предыдущую задачу, опять отправил, от ревьюера вернулись обе + поступила новая задача…
ИМХО, такая параллельность ни к чему хорошему не приведет. В данном случае лучше действовать последовательно. То есть не надо, ожидая результатов проверки, начинать новую задачу. А проверка может и не быть быстрой — ревьюер занят!
ИМХО, такая параллельность ни к чему хорошему не приведет. В данном случае лучше действовать последовательно. То есть не надо, ожидая результатов проверки, начинать новую задачу. А проверка может и не быть быстрой — ревьюер занят!
Отсюда напрашивается вопрос — а не будет ли потеря 50% времени одного программиста (200% — 150%) — меньшим из зол? Может, лучше бы сидели они вместе за одним компом…
Если вам больше одного раза возвращается — то вы очень плохой программист, у нас такого не было скажем так.
То есть вы реально считаете, что если вы отправляете свой тикет на тестирование (без ревью) и вам возвращают это плохо? Ну в смысле лучше сидеть и ничего не делать и ждать пока тебя оттестируют? вот это вообще медленно и потеря времени будет. К тому же когда с ревью возвращается это обычно подправить код или написать документацию, что не занимает очень много времени.
То есть вы реально считаете, что если вы отправляете свой тикет на тестирование (без ревью) и вам возвращают это плохо? Ну в смысле лучше сидеть и ничего не делать и ждать пока тебя оттестируют? вот это вообще медленно и потеря времени будет. К тому же когда с ревью возвращается это обычно подправить код или написать документацию, что не занимает очень много времени.
Резюмирую свою позицию. Я бы не стал применять такую практику, потому что:
1. Второй программист вынужден постоянно отвлекаться от своей основной работы. В конце концов ему это надоест и он начнет писать отписки.
2. Сам процесс очень прерывистый, слишком частые переключения с задачи на задачу
3. Слишком сильные ограничения на компетентность первого программиста: если ему вернутся более чем 2 задачи (от тестеров или ревьюера), и он работает над третьей, то возникает мозговой коллапс
4. Как следствие всего что выше — пониженный уровень концентрации.
1. Второй программист вынужден постоянно отвлекаться от своей основной работы. В конце концов ему это надоест и он начнет писать отписки.
2. Сам процесс очень прерывистый, слишком частые переключения с задачи на задачу
3. Слишком сильные ограничения на компетентность первого программиста: если ему вернутся более чем 2 задачи (от тестеров или ревьюера), и он работает над третьей, то возникает мозговой коллапс
4. Как следствие всего что выше — пониженный уровень концентрации.
1. программист в день отвлекается от основной работы очень много раз, так что пусть он лучше отвлекается на то что ревьюит код, а не то что бы по хабрам и лепрам лазить.
2. В принципе ничего не мешает во время именно перерывов делать ревью — ревью это только отсмотр кода, ты просто должен отсмотреть и понять где явные неточности, где ошибки оформления кода, а где забыл и пропустил ескейпинг. То есть вы переключаетесь только тогда когда вам надо, а не частые.
3. У вас никогда не было больше 4-х тикетов? Да ну не поверю, а висит он и висит, делаешь когда придёт время.
4. Концентрация наоборот выше. Ты всегда в готовности.
З. Ы. Мне кажется вы не понимаете смысла ревью.
2. В принципе ничего не мешает во время именно перерывов делать ревью — ревью это только отсмотр кода, ты просто должен отсмотреть и понять где явные неточности, где ошибки оформления кода, а где забыл и пропустил ескейпинг. То есть вы переключаетесь только тогда когда вам надо, а не частые.
3. У вас никогда не было больше 4-х тикетов? Да ну не поверю, а висит он и висит, делаешь когда придёт время.
4. Концентрация наоборот выше. Ты всегда в готовности.
З. Ы. Мне кажется вы не понимаете смысла ревью.
Чорт! Рус, ты только что назвал меня плохим программером:)))
ЗЫ у меня было несколько тикетов таких;))
ЗЗЫ пойду упьюсь:)
ЗЫ у меня было несколько тикетов таких;))
ЗЗЫ пойду упьюсь:)
Когда мозг залипать начинает, надо встать, походить по комнате, клавиатуру из рук выпустить) У меня почему-то решения быстрее в голову приходят, если не сидишь за компом и в код смотришь, а ходишь туда-сюда:)
Очень интересно! А что это за тулзы такие? Как называются? Можно линки на них?
Я пытаюсь в своей компании внедрить подобную технику, но пока все проходит достаточно вяло. Из отрицательных моментов выделяются 2:
— приходится отвлекать людей, когда у них нет времени для ревью. Причем если ревьюверов больше одного, то собраться становится еще сложнее;
— Вижу что ревьювится далеко не каждая строчка кода. Т. е. только основные моменты, а хочется чтобы человек показывал каждое изменение. Это сложно, поскольку сам ревьюемый может и не вспомнить, что он менял.
Соответственно, на лицо нехватка автоматизации. Ясно же, что через Subversion все эти изменения получить можно. Рассылка по емейлу изменений в чекине — неплохой шаг. В общем, хотел бы узнать как это в других компаниях работает
Я пытаюсь в своей компании внедрить подобную технику, но пока все проходит достаточно вяло. Из отрицательных моментов выделяются 2:
— приходится отвлекать людей, когда у них нет времени для ревью. Причем если ревьюверов больше одного, то собраться становится еще сложнее;
— Вижу что ревьювится далеко не каждая строчка кода. Т. е. только основные моменты, а хочется чтобы человек показывал каждое изменение. Это сложно, поскольку сам ревьюемый может и не вспомнить, что он менял.
Соответственно, на лицо нехватка автоматизации. Ясно же, что через Subversion все эти изменения получить можно. Рассылка по емейлу изменений в чекине — неплохой шаг. В общем, хотел бы узнать как это в других компаниях работает
Навскидку не скажу.
Можно погуглить code review tools.
Можно подождать. kriconf.ru/2008/index.php?type=info&doc=speech_archive — тут по идее когда-нибудь должен появится архив с КРИ-2008. Там как раз должен быть доклад нивала на тему code review и других практик, которые они используют — докладчик много тулзов называл, для Java/Jidea.
Можно погуглить code review tools.
Можно подождать. kriconf.ru/2008/index.php?type=info&doc=speech_archive — тут по идее когда-нибудь должен появится архив с КРИ-2008. Там как раз должен быть доклад нивала на тему code review и других практик, которые они используют — докладчик много тулзов называл, для Java/Jidea.
> Очень интересно! А что это за тулзы такие? Как называются? Можно линки на них?
Мы такое вот-вот откроем на reviework.com как публичный сервис
Мы такое вот-вот откроем на reviework.com как публичный сервис
Идея интересная.
Главная проблема, как со всем новым — чтобы прижилась в коллективе.
Главная проблема, как со всем новым — чтобы прижилась в коллективе.
последнее слово предпоследнего абзаца
P.S. Без претензий, опечатка, бывает, просто заметил
P.S. Без претензий, опечатка, бывает, просто заметил
А у вас что-нить подобное использовалось/используется?
однажды пользовался с удаленым программистом
collabedit'ом
НЛО прилетело и опубликовало эту надпись здесь
А вывод и мораль где в топике? На прошлой работе у меня использовался Code Review, дисциплинирует, однако человек с опытом лажу комитить не будет в любом случае :) Штука полезная, но не всегда. Я бы предпочел использовать автоматизированные средства типа юнит тестов для того, чтобы проверять функционал на регрешены, нежели вот такой вот упредительный контроль. Мелкие ошибки все равно просачиваются :)
У нас это используется. Часто помогает избежать простых недочетов, которые программист, который писал код, мог допустить. Я считаю, что применение code review очень оправдано.
В Гугле весь код в репозиторий (кроме личных экспериментов разработчиков) попадает только после code review.
у нас тоже некоторое время использовался code review
причем не только для новых разработчиков, но и для опытных — молодыми
и это очень сильно подняло качество кода на проекте
причем не только для новых разработчиков, но и для опытных — молодыми
и это очень сильно подняло качество кода на проекте
Когда вы уже Макконнелла прочитаете? То про парное программирование пишут, как про открытие великое, теперь до обзоров добрались.
Если чуть развить тему автора, то еще нужны чеклисты, по которым делается ревью и неплохо было бы использовать какой-нибудь инструмент для автоматического кодревью, который бы экономил ваше время и деньги.
Скользкий момент тут в том, что самые гадкие ошибки, из серии тут починили, а там отвалилось, отловить это не поможет.
Ну и при достаточно большой и сложной системе один человек это врядли потянет, потому что надо вникать во все тонкости всех частей системы и держать их в голове.
А вообще сама идея неплохая.
Ну и при достаточно большой и сложной системе один человек это врядли потянет, потому что надо вникать во все тонкости всех частей системы и держать их в голове.
А вообще сама идея неплохая.
Забейте на этот топик, прочитайте книгу «Совершенный код», там подробно описывается как проводить инспекции кода, а так же про парное программирование в совершенно другой главе.
Статью нужно было начинать со слов: А вот у нас в компании…
Потому что первый абзац начисто всех путает. Code Review, который вы описываете, имеет совершненно другие цели нежели Pair Coding.
А вообще Code Review вполне живая\состоявшаяся практика для оценки кода свежим взглядом. Ревьювер может увидеть какие-либо потенциальные проблемы или ошибки, ну и стандарты кодирования само собой. Времени ревью отнимает совсем не много, а если в команде есть пионеры, за которыми нужен глаз да глаз, так и вообще must have. Вам бы еще CheckStype/PMD plugins начать использовать, у ревьювера еще меньше времени это будет отнимать.
Ну и насчет парного, одно другому не мешает и вы вполне можете в дополнение к ревью еще и парное программирование использовать.
Потому что первый абзац начисто всех путает. Code Review, который вы описываете, имеет совершненно другие цели нежели Pair Coding.
А вообще Code Review вполне живая\состоявшаяся практика для оценки кода свежим взглядом. Ревьювер может увидеть какие-либо потенциальные проблемы или ошибки, ну и стандарты кодирования само собой. Времени ревью отнимает совсем не много, а если в команде есть пионеры, за которыми нужен глаз да глаз, так и вообще must have. Вам бы еще CheckStype/PMD plugins начать использовать, у ревьювера еще меньше времени это будет отнимать.
Ну и насчет парного, одно другому не мешает и вы вполне можете в дополнение к ревью еще и парное программирование использовать.
CodeReview который здесь описан является предпосылкой к PairProgramming иначе, PairProgramming может быть поражден из хорошего и долго практикования CodeReview. Тем ни менее цели разные.
CodeReview ставит своей целью inspeciton: codestyle inspection, design inspection, algoritm inspection и т. д. Фактически это способ удержания качества самого кода, но не качества продукта. У CodeReview есть недостаток, который упоминался выше: это отвлечение вытягивание ревьювещего программиста из «потока», т. е. когда программист занят своей задачей и тут его отвлекают на ревью и ему срочно нужно выгружать, а потом загружать свою проблему из головы и обратно. Есть вариация OfflineCodeReview — реализуется с помощью специальных тулзов и нотификаций — это когда ревьюверу позволено делать ревью в удобное время в режиме оффлайн. Но у такого способа свой недостаток: если у вас достаточно короткие итерации, то вы будете терять ритм из-за длинных циклов попадания кода в основную ветвь разработки.
Логическим продолжением CodeReview является PairProgramming. Это такая мысль: а почему бы нам постоянно, в каждый момент не ревьювить код. В этом случае нет проблем с выгрузкой/загрузкой проблем в/из головы, потому как оба программиста делают это одновременно. Но PairProgramming ставит своей целью не inspection, а problem solving. И действительно это убийство сразу N зайцев: повышение эффективности — программисты постоянно поддерживают друг друга в потоке не давая отвлекаться на долго и давая друг другу передохнуть, постоянный inspection (review), и значительно улучшенный обмен знаниями и информацией в команде (хороший PairProgramming подразумевает смену пар). Однако часто можно услышать о не работоспособности PairProgramming, основной причиной к этому я считаю психологический фактор программистов и тут как раз важнейшую роль будет играть способность лидера команды к организации общего пространства мышления, но это уже совсем не в ключе этого поста…
CodeReview ставит своей целью inspeciton: codestyle inspection, design inspection, algoritm inspection и т. д. Фактически это способ удержания качества самого кода, но не качества продукта. У CodeReview есть недостаток, который упоминался выше: это отвлечение вытягивание ревьювещего программиста из «потока», т. е. когда программист занят своей задачей и тут его отвлекают на ревью и ему срочно нужно выгружать, а потом загружать свою проблему из головы и обратно. Есть вариация OfflineCodeReview — реализуется с помощью специальных тулзов и нотификаций — это когда ревьюверу позволено делать ревью в удобное время в режиме оффлайн. Но у такого способа свой недостаток: если у вас достаточно короткие итерации, то вы будете терять ритм из-за длинных циклов попадания кода в основную ветвь разработки.
Логическим продолжением CodeReview является PairProgramming. Это такая мысль: а почему бы нам постоянно, в каждый момент не ревьювить код. В этом случае нет проблем с выгрузкой/загрузкой проблем в/из головы, потому как оба программиста делают это одновременно. Но PairProgramming ставит своей целью не inspection, а problem solving. И действительно это убийство сразу N зайцев: повышение эффективности — программисты постоянно поддерживают друг друга в потоке не давая отвлекаться на долго и давая друг другу передохнуть, постоянный inspection (review), и значительно улучшенный обмен знаниями и информацией в команде (хороший PairProgramming подразумевает смену пар). Однако часто можно услышать о не работоспособности PairProgramming, основной причиной к этому я считаю психологический фактор программистов и тут как раз важнейшую роль будет играть способность лидера команды к организации общего пространства мышления, но это уже совсем не в ключе этого поста…
Для всех английских терминов из вашего коммента есть вполне адекватные русские переводы. Problem solving — это зачет. Следующее предложение должно было выглядеть так: «И actually это killing сразу N rabbits».
ЗЫ. Извиняюсь за придирки — наболело.
ЗЫ. Извиняюсь за придирки — наболело.
Прошу прощения, что невольно наступил на Вашу мазоль.
Дело в привычке, Все слова написанные на английском языке имеют для меня смысл терминов (так например слово «кролик» в контексте обсуждения является метафорой, но не термином). Все термины англоязычного происхождения и заниматься трудностями перевода мне не хочется, поэтому я употребляю их как есть. К том же, так проще выделять термины из текста.
Еще раз приношу свои извинения.
P. S. По количеству взаимно наступленых мазолей мы квиты :)
Дело в привычке, Все слова написанные на английском языке имеют для меня смысл терминов (так например слово «кролик» в контексте обсуждения является метафорой, но не термином). Все термины англоязычного происхождения и заниматься трудностями перевода мне не хочется, поэтому я употребляю их как есть. К том же, так проще выделять термины из текста.
Еще раз приношу свои извинения.
P. S. По количеству взаимно наступленых мазолей мы квиты :)
То, что вы это делаете, уже лучше, чем если бы нет.
Но лучше не тикет после коммита создавать, а не коммитить до получения положительного отзыва от ревьюера. Иначе в HEAD trunk'а попадает неотревьюенный код.
Почитайте про Mondrian — программу, используемую для этого в Google (созданную Гвидо ван Россумом). Например, вот краткое введение, вот видео тек-толка, слайды.
Сейчас доступен Rietveld — опенсорсовый клон Mondrian'a на App Engine. Исходники на Google Code. Описание.
Но лучше не тикет после коммита создавать, а не коммитить до получения положительного отзыва от ревьюера. Иначе в HEAD trunk'а попадает неотревьюенный код.
Почитайте про Mondrian — программу, используемую для этого в Google (созданную Гвидо ван Россумом). Например, вот краткое введение, вот видео тек-толка, слайды.
Сейчас доступен Rietveld — опенсорсовый клон Mondrian'a на App Engine. Исходники на Google Code. Описание.
> Но лучше не тикет после коммита создавать, а не коммитить до получения положительного отзыва от ревьюера. Иначе в HEAD trunk'а попадает неотревьюенный код.
Лучше не использовать svn, а перейти на другой инструмент, в котором ветки создаются и удаляются «на раз».
Мы работаем с git и каждый тикет у нас ведётся в отдельной ветке. Сливает в master как раз человек, который просматривает код.
Лучше не использовать svn, а перейти на другой инструмент, в котором ветки создаются и удаляются «на раз».
Мы работаем с git и каждый тикет у нас ведётся в отдельной ветке. Сливает в master как раз человек, который просматривает код.
cvsspam и SVN::Notify с рассылкой по всему списку разработчиков.
Вольно или енвольно, мы все становимся участниками Code Review :)
Вольно или енвольно, мы все становимся участниками Code Review :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XP. Недопарное программирование (Code review).