Практикуется ли code review в вашей компании? - Управление проектами

Здравствуйте, alnsn, Вы писали:

A>bkat wrote:
>> Или ты хочешь предложить свои услуги ревьюера другим фирмам?
A>Да, хочу узнать, имеет ли это смысл делать в России. Поднимать отечественный
A>рынок

А на западе это практикуется?
Т.е. независимое тестирование,
сертификации процесса разработки в целом — об этом я слышал.

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

Ну тебе виднее. Может дело и выгорит.

bkat wrote:

> А вот просто code review третьими,
> посторонними лицами — это немного необычно.
> Смысл review еще и в том, что свои девелоперы смотрят код других
> и ищут проблемы. Т.е., на мой взляд, важно, что это делают именно свои.
>
> Ну тебе виднее. Может дело и выгорит.
Я работал в компании, которая делает code review и сам это делал.
Есть несколько моментов во внутреннем код ревью. Первое, рука руку моет.
Второе, все варятся в одном котле.
Я думаю, можно совместить code review с обучающим моментом. Сначала я делаю
code review, определяю общие ошибки и недочеты, а потом на общем собрании
их можно обсудить.
--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, alnsn, Вы писали:

A>bkat wrote:

>> А вот просто code review третьими,
>> посторонними лицами — это немного необычно.
>> Смысл review еще и в том, что свои девелоперы смотрят код других
>> и ищут проблемы. Т.е., на мой взляд, важно, что это делают именно свои.
>>
>> Ну тебе виднее. Может дело и выгорит.
A>Я работал в компании, которая делает code review и сам это делал.
A>Есть несколько моментов во внутреннем код ревью. Первое, рука руку моет.

Есть такая проблема. Для этого нужно организовывать нормальное SQA,
которое не зависит от тех, кто управляет проектом.
В общем это уже совсем другое измерение и это стоит бОльших денег
и требует особых подходов. Т.е. проблема шире и не касается только
code review. Тестеры ведь тоже могут на баги глаза закрывать.

A>Второе, все варятся в одном котле.
A>Я думаю, можно совместить code review с обучающим моментом. Сначала я делаю
A>code review, определяю общие ошибки и недочеты, а потом на общем собрании
A>их можно обсудить.

Это может быть полезным, но это скорее что-то типа консультаций.
Часто компании приглашать экспертов на это дело не будут.
code review нужно проводить чаще.

Здравствуйте, alnsn, Вы писали:

A>Недавно вернулся из Германии в Москву и начал работать независимо. Мне
A>интересно, имеет ли тратить часть времени на code review для московских
A>фирм или выгодней искать заказчиков за бугром?

У нас ничего такого нет, и вряд ли когда либо будут нанимать внешних людей для этой цели.

У нас в компании ведется несколько довольно больших проектов, внутри каждого проекта есть команда разработчиков, исходники все в SS(SoS). Так что при желании каждый может посмотреть сделанные за день изменения и поискать ошибки и недочеты. У нас это особенно удобно, так как у нас команда пополам в америке и в москве, так что каждое утро находишь массу сюрпризов, а каждый вечер оставляешь

Соответственно у нас есть любители (я и местный руководитель) просматривать чужой код, посылая друг другу по аське самые интересные индусские приколы типа
while (N>5) N--;

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

Здравствуйте, Xentrax, Вы писали:

X>У нас в компании ведется несколько довольно больших проектов, внутри каждого проекта есть команда разработчиков, исходники все в SS(SoS). Так что при желании каждый может посмотреть сделанные за день изменения и поискать ошибки и недочеты.

Может посмотреть, а может и не посмотреть.
Короче под настроение. В этом и проблема...
code review — это то что планируется и делается независимо от желания и настроения.
В общем вреда от нормально организованного code review нет,
а польза достаточно очевидна.

X>Соответственно у нас есть любители (я и местный руководитель) просматривать чужой код, посылая друг другу по аське самые интересные индусские приколы типа
X>while (N>5) N--;
X>Мы у них в коде их просто молча исправляем, а наш многоэтажный мат и проклятия остаются неуслышанными...

А это вы зря. Как нибудь совершите роковую ошибку и вам все,
что вы сделали втихушку, могут вспомнить.

Нашел проблему, занес ее в базу багов а дальше не твое дело.
Опять же меньше риск поиметь побочные эффекты при исправлении чужого кода.

bkat wrote:

> Здравствуйте, alnsn, Вы писали:
>
> A>bkat wrote:
>
>>> А вот просто code review третьими,
>>> посторонними лицами — это немного необычно.
>>> Смысл review еще и в том, что свои девелоперы смотрят код других
>>> и ищут проблемы. Т.е., на мой взляд, важно, что это делают именно свои.
>>>
>>> Ну тебе виднее. Может дело и выгорит.
> A>Я работал в компании, которая делает code review и сам это делал.
> A>Есть несколько моментов во внутреннем код ревью. Первое, рука руку моет.
>
> Есть такая проблема. Для этого нужно организовывать нормальное SQA,
> которое не зависит от тех, кто управляет проектом.
> В общем это уже совсем другое измерение и это стоит бОльших денег
> и требует особых подходов. Т.е. проблема шире и не касается только
> code review. Тестеры ведь тоже могут на баги глаза закрывать.

Девелоперы это не тестеры и подход к код ревью и них не такой, как у
тестеров к тестированию. Тестеры это последняя ступень, поэтому с них спрос
выше. Вот они и стараются. А зачем стараться девелоперу при code review
если тестер плохой код и так найдет? Конечно, для создания видимости бурной
деятельности нужно несколько замечаний сделать, но не более того.
Про архитектурные огрехи я вообще молчу. Часто они делаются людьми рангом
выше, чем code reviewer или являются результатом общей деятельности. Если
постоянно против коллектива или начальства идти, то можно завоевать плохую
репутацию.

> Это может быть полезным, но это скорее что-то типа консультаций.
> Часто компании приглашать экспертов на это дело не будут.
> code review нужно проводить чаще.
Согласен, что внутренний код ревью нужен чаще. Тоже самое относится и к
тестированию (ведь бывает же тестирование сторонними фирмами). Преимущества
у внешнего code review все-таки есть.
Во-первых, в бурных проектах в самые критические моменты не хватает людей.
Можно позволить code review только после завершения проекта или после
перехода его в более тихую для девелоперов фазу, например при тестировании.
Но тогда как правило у девелоперов затишье только при условии, что они
изначально написали качественный код и code review не нужен. Иначе у них
запарка с багами. Если в этот момент начать еще и результаты code review в
код добавлять, то вообще будет каша в проекте. Скорее всего он не будет
сделан в срок.
Во-вторых, когда имеешь дело с независимым человеком, то не надо платить
зарплату каждый месяц. Когда нужно заплатил за code review и все.

В-общем, если эту мазу толкать, то наверно среди начальников отделов и
давить на социальную сторону. Например, на какой-нибудь конференции сделать
доклад на эту тему. Понаприводить примеров из реальной жизни, например пост
Xentrax'а.
--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, alnsn, Вы писали:

A>Есть несколько моментов во внутреннем код ревью. Первое, рука руку моет.

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

... << RSDN@Home 1.1.3 beta 1 (Win32NT 5.1.2600.0) >>

Здравствуйте, alnsn, Вы писали:

A>Девелоперы это не тестеры и подход к код ревью и них не такой, как у
A>тестеров к тестированию. Тестеры это последняя ступень, поэтому с них спрос
A>выше. Вот они и стараются. А зачем стараться девелоперу при code review
A>если тестер плохой код и так найдет? Конечно, для создания видимости бурной
A>деятельности нужно несколько замечаний сделать, но не более того.

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

Здравствуйте, bkat, Вы писали:

B>В общем вреда от нормально организованного code review нет,
B>а польза достаточно очевидна.

Вот стану я руководителем, тогда и буду принимать такие решения. А пока у нас выше травы могут быть только иностранные граждане

B>А это вы зря. Как нибудь совершите роковую ошибку и вам все,
B>что вы сделали втихушку, могут вспомнить.

B>Нашел проблему, занес ее в базу багов а дальше не твое дело.

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

Весной туда еду, попробую соблюдать христианские заповеди, и морды никому не бить. Что интересно, у "наших" китайцев и индусок склонность к "стукачеству" выражена значительно меньше.

B>Опять же меньше риск поиметь побочные эффекты при исправлении чужого кода.

Ну это извечный философский спор на тему полезности методик XP. Я не сторонник всех этих новомодных вещей, но код, который могут править сразу несколько человек, особо не советуясь друг с другом, получается по качеству заметно выше уровня квалификации любого из этих программистов.

Хотя, опять же, у нас очень плохо с проектированием, так как что такое проектирование, знает только наш местный ведущий программист, а все американцы и наши (включая даже меня) такой квалификацией не обладают. Так что ядро — ОО структура данных вокруг БД и часть математики, которые контролирует наш ведущий, вносит некую стабильность в царящий вокруг хаос.

Дело в том, что у нас нет людей, которые бы понимали элементарные истины — типа полезности и осуществимости code reuse, code review, refactroing, процесса разработки, крайней необходимости качественной коммуникации между разработчиками, полезности багзиллы.

Я ведь прямо спросил менеджера — стесняется ли он использовать багзилу, чтобы выход версии не зарубили коммерческие ("ах, у вас 500 багов — пока не исправите, не будет версии, а ее мы между прочим обещали уже неделю назад в коробках иметь"), так он ответил, что нет, просто иногда проще позвонить местным программистам и попросить сделать. И они делают. Только не всегда так, как надо, а ты сидишь, знаешь, как надо, только не знаешь, что баг вообще есть.

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

Здравствуйте, Xentrax, Вы писали:

X>Ну это извечный философский спор на тему полезности методик XP. Я не сторонник всех этих новомодных вещей, но код, который могут править сразу несколько человек, особо не советуясь друг с другом, получается по качеству заметно выше уровня квалификации любого из этих программистов.

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

Ты, кстати, упомянул про стукачество.
В чем оно выражается, если не секрет?

Здравствуйте, alnsn, Вы писали:

A>Недавно вернулся из Германии в Москву и начал работать независимо. Мне
A>интересно, имеет ли тратить часть времени на code review для московских

А что подразумевается под code review. Например, задача обратного проектирования туда входит?
А то сижу уже третий месяц в серьезной фирме... Может я code reviewer?
Есть ли доп. информация?
Где почитать?

BlackHeretic wrote:

> А у нас все организовано так, что подобной халатности как правило не
> бывает. Все продукты собираются из компонент. Каждая компонента имеет
> ответственного за нее человека. Если компонента крупная, то есть еще и
> помощники ответственные за ее части. Как правило ответственный — это
> человек компоненту разработавший и в любом случае ее поддерживающий и
> развивающий. Короче, если есть проблемы с компонентой, то спрашивают с
> ответственного. Таким образом писать баговый код ему не выгодно и
> устраивать показушное ревью тоже. В случае если мне нужно поменять что-то
> в его коде есстественно ревью мне делает он. Думаю излишне говорить с
> каким ревностным вниманием это производится.
У вас наверное молодой проект. Нужно подождать годика два-три когда часть
ответственных уйдет, часть повысят и им уже будет не до поддержки своих
частей. Придется заставлять молодое поколение вникать в эти компоненты, а
они будут наверняка материться, потому что они будут воспитаны на новых
технологиях, старые им будут казаться пещерными реликвиями, на изучение
которых нельзя (!) терять время. Можно конечно вместо них набрать матерых
code maintainer'ов, но по-моему, им уже все равно, есть работа, хорошо, нет
работы — еще лучше.
Так и убьется творческое начало а проекте. Элементарной текучкой и
неумолимой сменой технологий. Кроме того, если отдел начнет расширятся, то
начнется политическая борьба и тд и тп.
--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

Posted via RSDN NNTP Server 1.8 beta

alex-chin wrote:

> Здравствуйте, alnsn, Вы писали:
>
> A>Недавно вернулся из Германии в Москву и начал работать независимо. Мне
> A>интересно, имеет ли тратить часть времени на code review для московских
>
> А что подразумевается под code review. Например, задача обратного
> проектирования туда входит? А то сижу уже третий месяц в серьезной
> фирме... Может я code reviewer? Есть ли доп. информация?
> Где почитать?
Любой программер, который чувствует, что созрел до того, чтобы помогать
другим, может это делать. Главное тут найти интерес к твоим способностям.
Возможно что-то в этом духе (мне конечно до Скота Мейерса еще далеко, но
буду стремиться):
--- cut ---
"We had Scott Meyers with the team for 3 days. We reviewed some critical
sections of our work and have since implemented a redesign of one internal
section of code based on our conversations, and have plans to do the same
for two other major sections. Scott provided that extra little bit of
insight that you get from being an outsider to the problem, and he is very
fast at getting to the underlying issues in problems that are new to him. I
found the execise to be quite worthwhile and would happily bring him back
every 6 months or so."
--- cut ---
http://www.aristeia.com/consulting_frames.html

--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, alnsn, Вы писали:

A>alex-chin wrote:

>> А что подразумевается под code review. Например, задача обратного
>> проектирования туда входит? А то сижу уже третий месяц в серьезной
>> фирме... Может я code reviewer? Есть ли доп. информация?
>> Где почитать?
A>Любой программер, который чувствует, что созрел до того, чтобы помогать
A>другим, может это делать. Главное тут найти интерес к твоим способностям.
A>Возможно что-то в этом духе (мне конечно до Скота Мейерса еще далеко, но
A>буду стремиться):
A>http://www.aristeia.com/consulting_frames.html

Да... Ну это тепличные условия

A>"We had Scott Meyers with the team for 3 days"

3 (Три!) дня и типа критические части, дизайн уже успел посмотреть. Жуть. Ну подумай. Ну кто тебя возьмет на три дня копаться в коде? И ты успеешь? На месяц на полгода я понимаю... И сколько ты возьмешь за день работы?

Вот тебе совет — ищи "помойки". Не ООП, а процедурный код. И объем шоб был огромный. Возможно скриптинг. Чтобы сами владельцам "помоек" было западло копаться. А тут ты. С настраиваемыми синтаксическими анализаторами. Визуализаторами алгоритмов. Моделями прикладной области. Вот это будет работа.

Да...

Вот сижу и обхаживаю такую помойку...
12.000 модулей.

А у тебя анализаторы и визуализаторы есть? Или только GOF и Refactoring?

alex-chin wrote:
> 3 (Три!) дня и типа критические части, дизайн уже успел посмотреть. Жуть.
> Ну подумай. Ну кто тебя возьмет на три дня копаться в коде? И ты успеешь?
> На месяц на полгода я понимаю... И сколько ты возьмешь за день работы?
Конечно побольше, я не так шустер как он. Можно периодически разные куски.

> А у тебя анализаторы и визуализаторы есть? Или только GOF и Refactoring?
Прибавь к GOF и Refactoring ворнинги от компилятора. Я после твоего поста
вспомнил концовку фильма не бойся, я с тобой

--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, bkat, Вы писали:

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

Ну у нас уже привыкли, кроме того у нас весь код в SoS — все изменения видны, и к этому у нас уже привыкли. Кроме нескольких нервных товарищей. Что характерно, не очень качественных программистов. Так что у нас есть классы, у которых 2-3-4 постоянных автора.
Я осмелюсь утверждать, что такой подход к разработке удивительно хорошо существует в условиях окружающего хаоса и проектных решений, выработанных в аське и распространяемых устно. В "по книжке" организованном процессе я бы предпочел более четкое разделение работы по программистам.

B>Ты, кстати, упомянул про стукачество.
B>В чем оно выражается, если не секрет?

Это вообще-то не в тему проектирования и организации процесса.
Я вскользь уже описал. Наши программисты почти все не злопамятные, и не пишут кляуз — "а он сделал такой-то баг", а исправляют все сами, предупреждая только виновника. Амеркианцы сначала идут докладывать, какие мы козлы, а потом уже исправляют. А так как менеджер программировать умеет по сути только математику в forrtran-alike style, то ему все эти наши дважды удаленные указатели кажутся страшным преступлением, особенно учитывая, что они отладочныую версию редко используют по историческим причинам (старая память об отладке по компорту). Я конечно понимаю, что близость менеджера вызывает желание настучать, но ведь это же должно надоесть почти по каждому багу докладывать, кто его сделал. Вот не надоедает. Возможно это связано с низким профессионализмом.

Здравствуйте, alnsn, Вы писали:

A>BlackHeretic wrote:

A>У вас наверное молодой проект. Нужно подождать годика два-три когда часть
A>ответственных уйдет, часть повысят и им уже будет не до поддержки своих
A>частей. Придется заставлять молодое поколение вникать в эти компоненты, а
A>они будут наверняка материться, потому что они будут воспитаны на новых
A>технологиях, старые им будут казаться пещерными реликвиями, на изучение
A>которых нельзя (!) терять время. Можно конечно вместо них набрать матерых
A>code maintainer'ов, но по-моему, им уже все равно, есть работа, хорошо, нет
A>работы — еще лучше.
A>Так и убьется творческое начало а проекте. Элементарной текучкой и
A>неумолимой сменой технологий. Кроме того, если отдел начнет расширятся, то
A>начнется политическая борьба и тд и тп.

Ну вообще-то нашей фирме более десяти лет, время жизни проекта как такового 3-4 года.
Насчет нового поколения — не согласен — состав меняется таким образом, что преемственность
обеспечивается хорошая (я работаю забугром — здесь в среднем человек на фирме работает 3-5 лет, потом
переходит на новое место. Особенно в начале скачут.)
А технологии — с ними никакой связи — компоненты были, есть и будут есть — неважно, в каком языке и
в какой технологии программирования.
Кстати, на смену морально устаревшим компонентам пишутся новые, их замещающие.
В общем не малый опыт оказывает — личная ответственность за код — отличное решение.
За доказательство можно взять то что в своей области наша фирма занимает первое место в мире (поверте на слово

От:	alnsn	http://nasonov.blogspot.com
Дата:	31.01.04 09:51
Оценка:

	От:	bkat
	Дата:	31.01.04 10:58
	Оценка:

От:	alnsn	http://nasonov.blogspot.com
Дата:	31.01.04 11:01
Оценка:

	От:	bkat
	Дата:	31.01.04 11:48
	Оценка:

От:	alnsn	http://nasonov.blogspot.com
Дата:	31.01.04 19:31
Оценка:

От:	Xentrax	http://www.lanovets.ru
Дата:	31.01.04 21:54
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	01.02.04 12:28
Оценка: