Здравствуйте, Gaperton, Вы писали:
G>Вообще, дизайн ревью необходимы для того, чтобы сделать code review более эффективными на практике. Почему:
И 5-е. Пожалуй, самое существенное. Введение design review имеет радикальный положительный эффект на сроки разработки и их предсказуемость в условиях наличия новых, неопытных сотрудников, в условиях присутствия значительной базы существующего кода. Проверено.
Подобные сотрудники тратят достаточно много времени на то, чтобы разобраться с существующим кодом, и найти правильный способ решения своих задач. Часто выясняется, что их подходы неверны, что приводит к затягиванию сроков из-за того, что они сами постоянно переделывают свою работу, или молча тупят, либо — к потоку дефектов в соседнем коде, индуцированным их действиями. Они повышают хрупкость кода и вносят баги со странными симптомами, которые потом ловятся опытными сотрудниками.
Введя обязательное design review, вы бьете подход к проблеме на два этапа, проскочить которые нельзя. 1 — "я понимаю, что и как я собираюсь сделать", и 2 — "я делаю". Делая это, вы выносите источник неопределенности в первый этап, который строго ограничиваете временными рамками, и сотрудник делает доклад о выбранном подходе к решению проблемы. Он должен описать изменения с точностью до класса. Его доклад слушают 1-2 опытных разработчика, и ищут ошибки. По показаниям — проводя ликбез в виде кратких лекций по архитектуре и принципам устройства системы, если это необходимо (правильное решение задачи проектирования является как бы практическим заданием к лекции — так автоматически само собой получается).
После того, как предлагаемое решение прошло design review, у сотрудника уже практически не остается шансов дать большую вариацию в сроке выполнения работы — вся неопределенность снята . Как и по крупному налажать. Кроме того, при данной схеме мы контроллируем обучение сотрудника.
Ну, и это отличный способ, помогающий от отмазок ленивых сотрудников, ссылающихся на сложность своей темы и задач.
Данный способ показал себя как наиболее эффективное комплексное решение для адаптации новых сотрудников. Эффект от одного этого процесса в процентном отношении к прочим мерам настолько велик, что ими можно пренебречь, не тратя зря силы.
D>>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???
B>3 дня назад мне делали. общий обьем — что-то около 3к строк (всего). B>человек затратил около 2-х недель, что бы вычитать весь мой код. B>сидели 2 часа в компании с еще одним, в митингруме с проектором — отвечал на вопросы. вроде отбился.
Нормальный средний темп кодревью, при котором реально найти ошибки — примерно 200 строк кода в час. Плюс-минус, потому, что средний.
3к строк будет примерно 15 часов чистого времени. При условии 4-х часов чистого времени в день (полная загрузка) имеем дня 4, вообще-то. То есть, кодревью выполнялось скорее медленно. Если ревьювер при этом еще и не нашел в коде багов (критерий эффективности ревью, ваще на нем ошибки положено ловить) — это отрицательная работа. От такого code review пользы немного.
Медленно и неэффективно оно может быть по разным причинам. Например:
1) Человек, кто проводит код ревью, не проводил ранее дизайн ревью этого же кода. Лечится либо kick-off meeting перед началом ревью (что считается необходимым для экспертизы материала такого объема), где автор объясняет, что тут ваще происходит, и как оно ваще работает. Либо, что гораздо эффективнее во всех смыслах, введением отдельного дизайн-ревью, где автор докладывает, как он собирается решать задачу, до того, как пишет основную массу кода. Для дизайн ревью в простейшем случае сойдет устный доклад у маркерной доски. И те же люди, кто проводил дизайн ревью, потом выполняют код ревью.
2) Человек вообще не специалист в данной теме — маловероятно, что он найдет какие-либо ошибки кроме пунктуации, эстетики, и соблюдения стандарта кодирования. Подобные ошибки, к слову, ловятся в темпе побыстрее чем 200 строк в час.
3) Давайть на ревью такие большие фрагменты кода — фашызм. Надо стараться бить на части. Опять же, проводя до этого дизайн ревью, чтобы люди были в курсе.
Здравствуйте, debugx, Вы писали:
D>Привет всем, D>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом??? D>Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии. Есть ли смысл проводить Codу review? Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Перед тем, как заливать код в TFS проводится ревью кода одним из сениор девелоперов. Важно, что код сениоров тоже подвергается ревью. Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован. Впрочем, понятно, что мелкие изменения типа переименования внутренней переменной метода никто не проверяет.
Чтобы ускорить процесс ревью активно пользуемся функциями shelve/unshelve. Таким образом ревьюверу даже не надо отрывать свой зад от кресла, чтобы отревьювить чужой код.
Могу сказать, качество кода улучшается прямо на глазах. Постоянно происходит обмен знаниями и наилучшими практиками внутри команды.
Вообще, дизайн ревью необходимы для того, чтобы сделать code review более эффективными на практике. Почему:
1) Они снижают затраты на code review, и совокупные затраты на все review.
2) Ошибка, которая может быть обнаруженная на дизайн ревью, в исправлении почти бесплатна, и является напротив — наиболее дорогой ошибкой, будучи найденной на код ревью.
3) Надо учесть социальный фактор. Бывает так, что на кодревью выясняется, что весь подход к решению задачи неправильный, и делать по хорошему надо не так. Однако, автор уже написал дохрена кода! Во-первых, ревьюверы чувствуют себя виноватыми, и им тяжело сказать человеку, что надо все выбросить, и переделать. Во-вторых, человеку самому грустно и обидно это делать. Поэтому, такой код имеет все шансы пройти кодревью, и таки оказаться в репозитории. Если не проводить design review, подобная ситуация будет возникать регулярно.
4) Design review позволяют привить культуру предварительного проектирования в масштабе компании, и являются, кроме того, единственным способом как-то контроллировать закрытие задачи "проектирование".
Здравствуйте, debugx, Вы писали:
D>кто-нибудь использует такую процедуру как Code review?
Регулярно. Код не чекинется без этого.
D>Как это происходит?
Беруться измененные файлы до и после изменений и высылается на инспекцию. Если изменения существенны желательно еще иметь описание того что было сделанно. Можно использовать различные тулзы для этого.
D>вы реально выделяете час времени в неделю, садитесь с командой
Не час, а столько, сколько нужно. Каак только реализация закончена код отправляется на проверку.
D>и начинаете стебаться друг над другом???
Это же не детский сад. Если есть проблемы в коде они указываются.
D>Есть ли смысл проводить Codу review? Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Есть. Проекты большие бывают и делают их разные люди.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
B>можно я тут мелкую ремарочку?..
B>Здравствуйте, SEDEGOFF, Вы писали: SED>>Поставьте эксперемент на двух сотрудниках — слабом и сильном. Замерьте — что измениться.
B>вот тут я хотел бы заметить, что не проверка "сильным" — "слабого" (а кто их определяет?!..), а проверка "любым — любого".
Проверка слабым сильного (или, вернее, неопытным опытного), помимо эффекта свежего взгляда (сильный тоже может легко дать косяка, опечатавшись в каком-нть присваивании), имеет очень сильный эффект обучения новичков как техникам программирования, используемым в проекте, так и программированию вообще, если проверяющий действительно слабее опытного чисто как программист.
более того, у эффекта свежего взгляда есть один побочный глобальный эффект: новичок (не в смысле студент, а в сымсле новый человек в команде) будет задавать вопросы об архитектуре, которые в команде могут считаться самоочевидными, хотя реально все уже могло с тех пор несколько раз поменяться и очевидность когда-то принятого решения или практики уже не так очевидна, а иногда и просто ошибочна.
Здравствуйте, DimitrySTD, Вы писали:
DST>Есть вопрос. Кто ещё знает достойные codereview tool? Обязательно чтоб web based. Сервер можно усебя поднять. Бесплатный или лекарство можно найти.
Расскажу как устроено у нас.
Правило: каждый коммит постфактум должен просмотреть ещё один человек (своеобразная постмодерация).
Есть более менее постоянная схема кто за кем инспектирует. Она периодически меняется, но каждый человек в каждый момент времени знает, кого он инспектирует.
Исходники в SVN. О каждом коммите оповещение приходит всей группе.
Если закоммитил тот, кого я инспектирую, я должен просмотреть его коммит (черепашка, diff, либо прямо открыть код в студии) и если замечаний нет, то дописать к сообщению в логе префикс "OK-pe". (pe — это мой username в SVN). В идеале в логе коммитов все сообщения должны начинаться с "OK-ктоНибудь" — это означает, что коду в репозитории можно доверять. Если есть замечания — префикс будет не OK, а "!-pe", а в конец сообщения в лог я допишу свои замечания.
В SVN-е настроен хук, который реагирует на смену сообщения лога и шлет оповещение об этом тому, кто делал этот коммит. Так автор узнает, что я проинспектировал его коммит и увидит сделанные мной замечания.
Есть ещё некоторое количество договоренностей и даже маленький самописный тул-напоминалка, но главную суть я изложил.
Работает на ура. С завидной периодичностью отлавливаются всякие баги, неточности, корявости. Не 100%, конечно, но довольно много.
Команда — 6 человек. На сколько я знаю похожая схема работает и ещё в паре команд.
D>вы реально выделяете час времени в неделю,
Унас можно потратить максимум 10% времени. Т.е. 4 часа в неделю. Обычно это достаточно. Щас посмотрел по отчётам, примерно 2ч в неделю реально тратится (на ревьюв чужого кода и исправления в своём после ревьюва)
D>садитесь с командой и начинаете стебаться друг над другом???
Собрать всех вместе это наверное малореально. Та и базара будет больше. Каждый делает ревьюв когда есть время. Я обычно делаю ревьювы между задачами. Это помогает немного переключится. Даже можно сказать, даю отдохнуть мозгам. Единственное правило, ревьювы не должны устаревать. Их надо постоянно делать, нельзя сделать ревьюв раз в месяц. Иначе после этого ревьюва уже могли быть комиты и ревьюв не актуален (мы разрешаем комитить, ревьювим после).
Нельзя ревьювить больше 3х часов. Вобщем много всяких мелочей.
D>Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Как уже писали, они видят код, только если проект маленький. А так уних нет времени смотреть. Уних есть контракты между модулями. Их палкой не заставишь сидеть рассматривать что там внутри. Своих тасков хватает.
Но самое главное в ревьюве это тулза. Программисты ленивые. Ревьюв должен создаваться "одной кнопкой" (как и билд). Пару лет назад я начинал внедрять ревьюв. Пробывал смотреть дифы и писать письма\баги. Это столько оверхеда, что быстро сдают нервы. Самые оптимальные Crucible и Code Collaborator. Уних разные воркфлоу. Мне больше нравится Code Collaborator (хоть там и проблема с лицензией).
Есть вопрос. Кто ещё знает достойные codereview tool? Обязательно чтоб web based. Сервер можно усебя поднять. Бесплатный или лекарство можно найти.
-- Всего хорошего. Дмитрий Студинский --
ICQ: 175465366
Skype: DimitrySTD
Здравствуйте, SE, Вы писали:
SE>>>>Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован. VGn>>>Жестоко. Бранчеваться не пробовали? B>>да чет жестковато. некий вариант парного программирования. B>>интересно. сам в таком режиме пока не работал. ...и чет не хочу. во
SE>Инспекция кода занимает у меня не более получаса в день, да и то, не каждый день.
не-не... вы возможно неправильно поняли.
я не против того подхода, который у вас там есть. мне просто он не нравится.
вы один занимаетесь код-ревью что-ли? а если ревьюер занят — я сижу и жду, когда мой код попадет в сырцы?
просто странно. мутно как-то. понятно, что повышается коллективная ответственность, но... мутно. во
Здравствуйте, SEDEGOFF, Вы писали: SED>Поставьте эксперемент на двух сотрудниках — слабом и сильном. Замерьте — что измениться.
вот тут я хотел бы заметить, что не проверка "сильным" — "слабого" (а кто их определяет?!..), а проверка "любым — любого".
1) просто проникнитесь, что ваш код (мой код) может открыть и прочитать любой. (я представляю, как передернуло сейчас некоторых "сильных").
2) и представте, что вы вынуждены писать код, который поймет любой. фишка в том, что если "сильного" завтра трамвай... гм... ок. он просто с похмелья на работу не пришел. и вот "слабый" должен до деплоймента закончить его кусок.
это просто первые и понятные всем 2 довода для вычитывания кода "не взирая на лица".
p.s. я не являюсь упертым сторонником код-ревью. но признаю полезность самого процесса "имения". во
Здравствуйте, DimitrySTD, Вы писали:
G>>Code Collaborator — великолепный тул. Дорогой, да. Дешевая версия — от 200 USD за место. Кроме того, если брать плавающие лицензии — то будет дешевле, чем количество мест. Для данного тула — плавающие лицензии это скорее правильно. Так как железобетонно ограничивают время, потраченное на code review. DST>Да, цена очень кусучая. Увы мы так и не купили. И наверное не смогли бы пользоваться, если бы не глюк в ихнем триале (сервер ccollab_server_2_1_725_windows.exe). Он работает бесконечно. Каждый день пишет что завтра закончится. Мы ничё не крутили, оно само . Вобщем так и живём. DST>Конечно в новой версии много вкусностей. Но лекарство нереально найти ни для новой ни для старой. Хотя скоро прижмёт. Старый клиент не умеет работать с svn 1.5 Так что пока не апгрейдим репозитарий.
Хех, а не вы ли лично полтора года назад просили ключ на руборде? Обрадую вас: вам ответили (и довольно давно).
СУВ, Aikin
P.S. ccollab_server_4_0_856_windows.exe, выкачанный только сегодня, с радостью съел ключик
Здравствуйте, Donz, Вы писали:
D>Здравствуйте, SE, Вы писали:
SE>>Перед тем, как заливать код в TFS проводится ревью кода одним из сениор девелоперов. Важно, что код сениоров тоже подвергается ревью. Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован.
D>То есть, после коммита, код сначала попадает во временное хранилище. Потом инспектируется лидом, и уже он решает, отправить ли код назад или закоммитить в VCS?
Инспектируется не только лидом. Хотя обычно это сениор-девелопер. Последнее время стараемся отдавать код на ревью тому девелоперу, который имеет наибольний опыт в рассматриваемой части проекта.
D>Какие утилиты используются для этого процесса, не подскажешь?
Все обеспечивается стандартными средствами TFS и VisualStudio А, ну, еще и скайп, чтобы кинуть в обсуждение вопрос: "Кто меня отревьювит?"
1. Девелопер шелвит код в TFS (shelve) — это и есть временное хранилище.
2. Ревьювер аншелвит (unshelve) код. Тут важно предварительно зашелвить свой, чтобы изменения не накладывались.
3. Ревьювер пересматривает код и составляет список рекоммендаций. Иногда что-то уточняет у девелопера.
4. Ревьювер передает список девелоперу, либо шелвит изменения на TFS, если он вносил изменения (не парное программирование, конечно, но бывает что и вместе сидят, правят код)
5. Девелопер вносит изменения, если согласен с ними, или не вносит, если в достаточной мере сумее аргументировать свою точку зрения
6. Изменения либо снова идут на ревью (см. п. 1), либо уходят в TFS.
Здравствуйте, DimitrySTD, Вы писали:
DST>Ну а всем могу заявить, что пользоваться такими замечательными тулами как crucible и codecolaborator могут даже бедные. Так что не ленитесь, и добавляйте такую активность в ваши процессы.
Согласен, crucible — отличный тул, вот только интеграции с VS2008 ему не хватает. Я спросил про это на их форуме, оказывается, реквест уже был создан — если кто-то заинтересован, проголосуйте за него.
D>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???
Поделюсь своим опытом.
Раньше я клемил кодеревью на чём свет стоит. Раньше я и работал в проектах 7-10 человек и Agile работал за глаза. Ревью не нужно было, так как совместное проектирование, использование Simple Design, юнит тестирование и другое делали своё черное дело. В общем я был убежденный анти-ревьюер.
Сейчас я работаю в проекте. Которые и проектами не назовёшь. Много заказов, много мелких и крупных исполнений. Много вещей передаётся во вне из компании. Помимо этого я и сам веду разработку. В этой повышенной многообразием проектов, людей и мнений ловине информации существуют управляющие гайдлайны, руководства и т.п. с целью стандартизации работы. Но так как людей очень много и каждый раз они перегруппируются под различные проекты. То выдерживать какой-то не то чтобы стиль оформления кода, а некоторый общий подход к разработке очень сложно.
Поэтому фаза ревью стала обязательной, и она может занимать от 30% до 100% времени на разработку. А так как все меняются, ротируются как в плане разработки, так и в плане peer review, то это становится очень мощным механизмом "не задокумментированного стандарта", некоторого общего по больнице.
И самое мощное, мы проводим ревью не стиля оформления (это не очень важно, поэтому разные Code&Style-конвенции отдыхают), а именно смысла вносимых изменений и предлагаемых решений.
Для себя я нашёл в этом следующие положительные моменты:
1. Я контролирую куда в общем приложение двигается на уровне кода и фич, это позволяет развить экспертизу в тех областях приложения, где я тум-тум
2. Повод поворить с людьми. Часто узнаешь трики, либо решения, до которых сам бы не дошёл, а иногда возникают противоречия — а решение их способствует формированию "командной интуиции к стандарту" взамен спущенной сверху уродливой кодеИнэйминг конвенции
3. Действительно исключаются ошибки и код становится проще после ревью. Так как мы проводим ревью не стиля, а смысла.
Вывод такой:
1. Если проект не большой — эта фаза не нужна, достаточно общего владения кодом
2. Если проект большой (в моём ядро проекта за сотни человек) — это хорошее дополнение к таким практикам, как юнит тестирование, коллективное владение и т.п. Так как цена ошибки в таких проектах оооооооочень дорогая.
Привет всем,
кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???
Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии. Есть ли смысл проводить Codу review? Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Здравствуйте, VGn, Вы писали:
SE>>Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован. VGn>Жестоко. Бранчеваться не пробовали?
Как по мне, бранчи идеологически предназначены для крупных частей проекта, которые по тем или иным причинам должны разрабатываться независимо. Т.е. бранчи, имхо, не для того, чтоб на каждый чих их заводить.
А вот на каждый день очень подходят шелвсеты, которые именно и предназначены для временного хранения слепков кода во время разработки до тех пор, пока разработчик не решит свою часть работы залить в TFS. Их же (шелвсеты) очень удобно использовать и для ревью.
Но на вкус и цвет, как говориться, все фломастеры разные.
Здравствуйте, bastrakov, Вы писали:
SE>>>Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован. VGn>>Жестоко. Бранчеваться не пробовали? B>да чет жестковато. некий вариант парного программирования. B>интересно. сам в таком режиме пока не работал. ...и чет не хочу. во
Инспекция кода занимает у меня не более получаса в день, да и то, не каждый день.
А вот если б я на каждый бзик бранч создавал, представляю сколько б я возился c тормознутым TFS туда сюда сливая и создавая различные ветки и постоянно между ними переключаясь.
Ведь такого, чтоб девелопер крутил только свою гайку не бывает. Часто надо помогать другим их гайки докручивать. Или свои гайки кому-то отдавать. А гаек-то ого-го.
Да, еще. Во время активной разработки я делаю три — четыре чекина в день. И это я считаю очень мало — изменения должны быть атомарные и затрагивать только одну функциональную единицу максимум.
A>Хех, а не вы ли лично полтора года назад просили ключ на руборде? Обрадую вас: вам ответили (и довольно давно).
От блин . Я давал мессагу. Уже и забыл, а смотрю через пол года нашёлся добрый человек. Пасибо что ткнули носом.
Ну а всем могу заявить, что пользоваться такими замечательными тулами как crucible и codecolaborator могут даже бедные. Так что не ленитесь, и добавляйте такую активность в ваши процессы.
-- Всего хорошего. Дмитрий Студинский --
ICQ: 175465366
Skype: DimitrySTD
Я как-то давненько спорил с AndrewVK о данном вопросе...
Вот он считает что не надо, за исключением.
А я наоборот считаю что надо, за исключением. И с каждым новым проектом убеждаюсь в этом.
Процесс разработки должен быть поставлен правильно.
Здравствуйте, debugx, Вы писали:
D>Привет всем, D>кто-нибудь использует такую процедуру как Code review?
У меня на одном из прошлых проектах такое было. Надо сказать, не бесполезно.
D>Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???
На том проекте — да, именно так.
D>Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии. Есть ли смысл проводить Codу review?
Определённо, да. Хотя и не обязательно именно в таком виде
D>Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Тут есть два ответа:
1. А зачем им смотреть код друг друга? Если проект маленький — то да, все видят всё. А если человек на 50?
2. А если они-таки смотрят. то это и есть одна из форм code review
Здравствуйте, debugx, Вы писали:
D>Привет всем, D>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???
после выполнения задачи другой человек (не команда, выбирается соответствующего уровня) проверяет, правильно ли реализовано то что требовалось, в достаточном ли объеме, иногда даже не в лишнем ли объеме. проверяется как код (соответствие стандарту, соглашениям, корректность, отсутствие багов), так и логика.
никакого стёба, если все в порядке, ревью прошел, если что-то не так, отправляется на доработку, с объяснением почему, что доделать.
D>Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии. Есть ли смысл проводить Codу review? Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
это формальная проверка правильности реализации задачи. если у тебя программа оперирует миллионами где-то или должна работать постоянно и часто перегружать невозможно — такие проверки нужны.
Здравствуйте, debugx, Вы писали:
D>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???
3 дня назад мне делали. общий обьем — что-то около 3к строк (всего).
человек затратил около 2-х недель, что бы вычитать весь мой код.
сидели 2 часа в компании с еще одним, в митингруме с проектором — отвечал на вопросы. вроде отбился.
стебатся не стебались. рисовал на доске варианты рампределения нагрузки и оптимизации запросов, работу индексов и схему данных.
...только отказался отвечать на 1 вопрос. меня попросили "коротенько" рассказать про аналитические функции оракла.
потупил 2 минуты, и попросил почитать доку.
D>Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии. Есть ли смысл проводить Codу review? Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
"процесс" проверки кода вынуждает их "оглашать публично" то, что они себе там думают по поводу чужого кода.
и оппонировать им можно тоже публично. и если по итогам code review я отбился, то мне пофиг, что кто-то считает, что так писать нельзя — мне уже можно.
ровно то же самое в другом направлении. если мой оппонент отбился — я заткнулся по его коду. во
Здравствуйте, VGn, Вы писали:
SE>>Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован. VGn>Жестоко. Бранчеваться не пробовали?
да чет жестковато. некий вариант парного программирования.
интересно. сам в таком режиме пока не работал. ...и чет не хочу. во
SE>Как по мне, бранчи идеологически предназначены для крупных частей проекта, которые по тем или иным причинам должны разрабатываться независимо. Т.е. бранчи, имхо, не для того, чтоб на каждый чих их заводить. SE>А вот на каждый день очень подходят шелвсеты, которые именно и предназначены для временного хранения слепков кода во время разработки до тех пор, пока разработчик не решит свою часть работы залить в TFS. Их же (шелвсеты) очень удобно использовать и для ревью.
Идеалогия — это конечно хорошо. Но версионность, она просто тупо удобна при разработке независимо от командных целей. (у меня на ноуте локально стоит SVN. Активно пользуюсь. Ни у кого разрешения на чекин не спрашиваю )
Вообще везде, где мне приходилось работать, более удобными считались короткие чекины. Притом их банально проще мержить. Непрерывная интеграция и всё такое.
А для стабилизации как раз используются бранчи.
Шелвсеты — личный велосипед Мелкософта. У других средств я аналогии им не знаю и, честно говоря, не очень и пользуюсь. На мой вкус они сильно фрагментируют код и удлиняют периоды интеграции, внося бардак в контроль конфигураций. Хотя конечно всё зависит от процесса.
Здравствуйте, DimitrySTD, Вы писали:
DST>Есть вопрос. Кто ещё знает достойные codereview tool? Обязательно чтоб web based. Сервер можно усебя поднять. Бесплатный или лекарство можно найти.
DST>>Есть вопрос. Кто ещё знает достойные codereview tool? Обязательно чтоб web based. Сервер можно усебя поднять. Бесплатный или лекарство можно найти. L>http://www.review-board.org/ смотрели?
Красивый интерфейс. Но суть примерно как в crucible. Можно написать замечания к diff. Но потом тяжело контролировать, что они исправлены. В колабораторе я могу создать коментраии\баги. После исправлений, мои коменты\баги мапятся на новый diff. Т.е. я вижу исправления и текст бага. Закрываю если надо, открываю новый (да-да, такое бывает. Исправляют и делают новый баг в исправлении). Ревьюв сам закроется когда багов нет или я их все закрыл.
Такая схема удобна когда ревьювишь несколько проектов. Когда программисты новички и делают много ошибок. Пока такой воркфлоу только в колабораторе видел
-- Всего хорошего. Дмитрий Студинский --
ICQ: 175465366
Skype: DimitrySTD
Здравствуйте, DimitrySTD, Вы писали:
DST>Но самое главное в ревьюве это тулза. Программисты ленивые. Ревьюв должен создаваться "одной кнопкой" (как и билд). Пару лет назад я начинал внедрять ревьюв. Пробывал смотреть дифы и писать письма\баги. Это столько оверхеда, что быстро сдают нервы. Самые оптимальные Crucible и Code Collaborator. Уних разные воркфлоу. Мне больше нравится Code Collaborator (хоть там и проблема с лицензией). DST>Есть вопрос. Кто ещё знает достойные codereview tool? Обязательно чтоб web based. Сервер можно усебя поднять. Бесплатный или лекарство можно найти.
Code Collaborator — великолепный тул. Дорогой, да. Дешевая версия — от 200 USD за место. Кроме того, если брать плавающие лицензии — то будет дешевле, чем количество мест. Для данного тула — плавающие лицензии это скорее правильно. Так как железобетонно ограничивают время, потраченное на code review.
Вероятно, это единственный тул из всех платных процессных тулов, который имеет прямой и очевидный эффект на продуктивность и качество. Этот тул окупается. Надо обязательно брать. Musthave.
Собственно, спасибо за ссылку на такой классный, годный тул. Такие тулы — редкость.
G>Code Collaborator — великолепный тул. Дорогой, да. Дешевая версия — от 200 USD за место. Кроме того, если брать плавающие лицензии — то будет дешевле, чем количество мест. Для данного тула — плавающие лицензии это скорее правильно. Так как железобетонно ограничивают время, потраченное на code review.
Да, цена очень кусучая. Увы мы так и не купили. И наверное не смогли бы пользоваться, если бы не глюк в ихнем триале (сервер ccollab_server_2_1_725_windows.exe). Он работает бесконечно. Каждый день пишет что завтра закончится. Мы ничё не крутили, оно само . Вобщем так и живём.
Конечно в новой версии много вкусностей. Но лекарство нереально найти ни для новой ни для старой. Хотя скоро прижмёт. Старый клиент не умеет работать с svn 1.5 Так что пока не апгрейдим репозитарий.
-- Всего хорошего. Дмитрий Студинский --
ICQ: 175465366
Skype: DimitrySTD
Re[7]: Правилен ли ход мыслей? (Async & Multithread)
Здравствуйте, Ocenochka, Вы писали:
O>Стало быть это выглядит так: O>1. мой код просит ядро сделать асинхронное чтение; O>2. ядро передает команду драйверу; O>3. драйвер говорит железу читать, мой поток выходит; O>4. железо само читает очередную порцию в буфер и по окончанию операции сообщает драйверу, O> тем самым совершив настоящий "обратный вызов"; O>5. драйвер через ядро передает моему коду "обратный вызов", поток стандартного пула выходит.
Совершенно верно. O>А есть ли некий универсальный подход к "асинхронизации" операций ввода/вывода? Например, что все операции ввода/вывода лучше выполнять асинхронно?
Дело в том, что синхронные операции ввода-вывода гораздо удобнее программировать. Пока что не так уж много существует в природе наработок, которые бы довели async programming до уровня, доступного простым смертным.
А практиковаться в них имеет смысл тогда, когда выигрыш в производительности окупает рост сложности софта.
В простом примере — обычное GUI приложение читает порцию данных из файла. Характерное время чтения этой порции — 500мс.
В синхронном случае это означает, что основной поток затормозился на полсекунды, а потом продолжил. Если мы сделаем операцию чтения асинхронной, основной поток всё равно никуда не денется. Просто он будет спать в ожидании на GetMessage, а не на ReadFile. Потому, что ему всё равно нечего делать в эти 500мс. Вот если бы ему было что делать — тогда другое дело. Если ему, к примеру, нужно в это же время играть анимацию на экране, то лучше выделить чтение в независимый поток.
И вот тут возникает тот момент, который уже обсуждали: синхронное чтение в отдельном потоке отличается от асинхронного чтения через I/O Completion Ports (так эта технология называется по-научному) тем, что не держит занятым один лишний поток. Экономия 1 мегабайта адресного пространства в типичном настольном приложении — фигня, не стоящая усилий.
O>Вот например, если читать из файла асинхронно, то O>1. если будет быстро читаться, то будет выделено примерно столько же потоков как и при параллельной синхронной работе.
Такого "быстрого чтения" добиться крайне тяжело. Характерное время обращения к диску настолько велико по сравнению со скорострельностью пары процессор/память, что всего один поток из пула успеет обслужить весьма большое количество "одновременных" обращений. А если речь идет O>По идее, оба варианта подходят, если я не ошибаюсь с первым пунктом, сюда же, наверно, надо отнести поблему выбора размера буфера ддя чтения.
Размер буфера выбрать очень легко: диски работают в блочном режиме. Чтобы буфер использовался оптимально, нужно делать его не меньше, чем размер "внутреннего блока". Контроллер всё равно прочитает (к примеру) 64 килобайта; если ты дашь буфер размером в 10к, то 54 будут просто выброшены и их придется читать заново.
Лучше делать буфер "с запасом". Ничего страшного, если контроллеру придется "сбегать" на диск два раза: всё равно это происходит помимо CPU. Зато более современный контроллер, пересылающий большими блоками, будет использоваться эффективнее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Правилен ли ход мыслей? (Async & Multithread)
Здравствуйте, Sinclair, Вы писали:
S>В простом примере — обычное GUI приложение читает порцию данных из файла. Характерное время чтения этой порции — 500мс. S>В синхронном случае это означает, что основной поток затормозился на полсекунды, а потом продолжил. Если мы сделаем операцию чтения асинхронной, основной поток всё равно никуда не денется. Просто он будет спать в ожидании на GetMessage, а не на ReadFile. Потому, что ему всё равно нечего делать в эти 500мс. Вот если бы ему было что делать — тогда другое дело. Если ему, к примеру, нужно в это же время играть анимацию на экране, то лучше выделить чтение в независимый поток. S>И вот тут возникает тот момент, который уже обсуждали: синхронное чтение в отдельном потоке отличается от асинхронного чтения через I/O Completion Ports (так эта технология называется по-научному) тем, что не держит занятым один лишний поток. Экономия 1 мегабайта адресного пространства в типичном настольном приложении — фигня, не стоящая усилий.
Плохой пример. Именно для обычного GUI существуют шаблоны MVC, которые в полпинка делают Model асинхронной. Рассуждения понятны, но пример выбран неудачно.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Команда — 6 человек. На сколько я знаю похожая схема работает и ещё в паре команд.
Весьма себе ничего схемка. Ее плюс — она не требует мегатулов, и неплохо работает.
От себя скажу — подобное легко изображается штатнами средствами jira или любого трекера с конфигурируемым воркфлоу. Вводится состояние reviewpending из которого есть возврат автору.
Плюс такого подхода — он делает процесс проще и прозрачнее. Минус (или плюс, это как посмотреть) — всю работу надо проводить через трекер.
Здравствуйте, debugx, Вы писали:
D>Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии.
У нас практикуется peer review. То есть, изменения просматриваются кем-то из сослуживцев. Как правило, с бОльшим опытом.
D>Есть ли смысл проводить Codу review?
Есть. Очень и очень нередко находятся косяки, которые автор кода просто не видит в силу "замыленности" своего глаза.
И это касается обсолютно всех, вне зависимости от опыта.
D>Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Не совсем так. Одно дело быстро посмотреть, как привязаться к фунционалу, который был заимплеменчен кем-то другим. Другое дело — более плотно (и критически) просмотреть реализацию этого функционала. Одним движением убивается пара зайцев: и косяки отлавливаются и у ревьювера остается хоть какое-то представление о коде, в разработке которого он не участвовал.
ЗЫ. Пользуемся ClearCase в конфигурации один стрим на девелопера.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, Gaperton, Вы писали:
B>>3 дня назад мне делали. общий обьем — что-то около 3к строк (всего). B>>человек затратил около 2-х недель, что бы вычитать весь мой код.
... G>Медленно и неэффективно оно может быть по разным причинам. Например:
все 3 пункта присутствуют. и есть еще один — он тратил на это примерно 1-2 часа в день рабочего времени.
честно говоря, я вообще был удивлен, что кого-то нагрузили вычитывать мой код. во
хмм.. если вы так ставите вопрос — то вам точно не надо. Делать это потому, что делают други и не понимать зачем — неблагодарное дело. Поэтому сначала поймите зачем. Именно поймите и после осознания этого вы без проблем объясните это другим и это будет приносить пользу. Поставьте эксперемент на двух сотрудниках — слабом и сильном. Замерьте — что измениться. И вот когда у вас будет вера в этот "шаманский обычай" — вы без лишних сомнений начнете им пользоваться. Это то же относится и ко всем остальным технолгиям и подходам
Здравствуйте, bastrakov, Вы писали:
B>вот тут я хотел бы заметить, что не проверка "сильным" — "слабого" (а кто их определяет?!..), а проверка "любым — любого".
вы правы — так тоже можно, но только одно но. Тот кто проверяет, должен как минимум знать на зубок соглашение о коде в компании. Иначе можно молучить несколько суб-культур. А сильного определяет время и отношение других участников. Если все правильно (на мой взгляд) налажено — то члены команды сами выбирают сильного и ходят к нему за советом
Смысл понятен, всем спасибо.
Но вот другай проблема. У нас этим никто не хочет заниматься. Пока директор у нас сказал: по средам нужно уделять час времени на Code Review. Не прокатило, все на это дружно забили.
А у вас чем мотивируется\стимулируется проведение Code Review?
И с чего вообще начать внедрение такого процесса в компании?
А есть ли у вас в компании руководитель, облеченный административными полномочиями, который понимает, как должен быть организован процесс разработки и зачем нужен code review? Если да — то ему и карты в руки. Если нет, и все разработчики "равны" и никому оно не надо, и по этой причине "все на это дружно забили" — то пинай директора, чтобы такой руководитель был. В идеальном случае, становись им сам — требуй от дира соответствующих полномочий, и не на бумаге, а в реалиях.
Здравствуйте, debugx, Вы писали:
D>Смысл понятен, всем спасибо. D>Но вот другаz проблема. У нас этим никто не хочет заниматься.
Люди, это все таки корыстные создания. И заставить их что то делать... ну в общем на мой взгляд гораздо эффективнее что бы человек сам захотел это делать. А почему человек чего то хочет (и именно программист)? Потому что ему что то лень делать и именно в том, что он хочет — есть инструмент как что то не делать. Вот и надо играть на этой лени. Вы попробуйте сами для себя разрисовать долгосрочную перспективу использования этого инструмента. В чем выгода? Где вы будете трудится меньше — где можно ленится больше? В результате вы получите что то вроде целей, в которых будет сказано в чем каждый сотрудник лично приоритет. И вот когда программисты это переварят — когда поймут в чем можно экономить свои силы и в чем каждый из них выиграет — вот тогда им не нужен будет ни директор, ни палка — ничего — они сами начнут это использоваться и через какое то время вспоминать — ой как было ужасно без этого. Итого: найдите выгоду для себя и каждого программиста в частности — после этого все станет проще и понятнее.
Я так внедрял бактрекинг в маленькой команде. Люди напрочь отказывались им пользоваться — лень было писать! Зато теперь заставляют писать всех и сами с радостью пишут — зауши не оттащишь
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, debugx, Вы писали:
D>>И с чего вообще начать внедрение такого процесса в компании?
G>Запретить все коммиты в репозиторий, к комменте к которому не указан ревьювер.
у нас subversion черепашка. Там вроде такое можно настроить, да?
Здравствуйте, SEDEGOFF, Вы писали:
SED>Люди, это все таки корыстные создания. И заставить их что то делать... ну в общем на мой взгляд гораздо эффективнее что бы человек сам захотел это делать. А почему человек чего то хочет (и именно программист)? Потому что ему что то лень делать и именно в том, что он хочет — есть инструмент как что то не делать. Вот и надо играть на этой лени. Вы попробуйте сами для себя разрисовать долгосрочную перспективу использования этого инструмента. В чем выгода? Где вы будете трудится меньше — где можно ленится больше? В результате вы получите что то вроде целей, в которых будет сказано в чем каждый сотрудник лично приоритет. И вот когда программисты это переварят — когда поймут в чем можно экономить свои силы и в чем каждый из них выиграет — вот тогда им не нужен будет ни директор, ни палка — ничего — они сами начнут это использоваться и через какое то время вспоминать — ой как было ужасно без этого. Итого: найдите выгоду для себя и каждого программиста в частности — после этого все станет проще и понятнее.
Боюсь перед русским менталитетом такой подход бессилен, хотя допускаю что в западных странах он отлично срабатывает. Нашему кодеру можно объяснить все выгоды от данной процедуры, можно растолковать, как это будет экономить время в будущем, и кодер всё поймет... Но делать всё-равно ничего не станет, если не будет четких изподпалочных указаний.
Так что вариант запретить комит без review кода на мой взгляд должен быть эффективным.
Здравствуйте, debugx, Вы писали:
D>Боюсь перед русским менталитетом такой подход бессилен, хотя допускаю что в западных странах он отлично срабатывает. Нашему кодеру можно объяснить все выгоды от данной процедуры, можно растолковать, как это будет экономить время в будущем, и кодер всё поймет... Но делать всё-равно ничего не станет, если не будет четких изподпалочных указаний. D>Так что вариант запретить комит без review кода на мой взгляд должен быть эффективным. С западным менталитетом не работал никогда. С русскими получается прекрасно! Дело не в менталитете, а лени каждого из нас. Обещать абстрактное что то — бессмыслено. Дайте руками потрогать! Если надо — Первый раз из под палки. А когда у человека в голове появится картина: путь номер один — 10 попугаев, путь номер два — 20 попугаев... но попугаев не может быть мало! Поэтому однозначно путь номер два! Вот тогда и начнут использовать.
А жесткие ограничения всегда имеют темную сторону силы... ну если есть светлая, то почему бы и не попробывать? Нет, конечно — есть места, где без ограничений не обойтись (государство например). Но это не значит что нужно все делать через ограничения. Вспомните свою реакцию на какие либо ограничения? Положительная только там, где есть выгода для вас лично
Здравствуйте, SE, Вы писали:
SE>Перед тем, как заливать код в TFS проводится ревью кода одним из сениор девелоперов. Важно, что код сениоров тоже подвергается ревью. Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован.
То есть, после коммита, код сначала попадает во временное хранилище. Потом инспектируется лидом, и уже он решает, отправить ли код назад или закоммитить в VCS?
Какие утилиты используются для этого процесса, не подскажешь?
Здравствуйте, debugx, Вы писали:
D>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, debugx, Вы писали:
D>>>И с чего вообще начать внедрение такого процесса в компании?
G>>Запретить все коммиты в репозиторий, к комменте к которому не указан ревьювер.
D>у нас subversion черепашка. Там вроде такое можно настроить, да?
. Как и по крупному налажать. Кроме того, при данной схеме мы контроллируем обучение сотрудника.
Так что пока не апгрейдим репозитарий.
во
