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

G>Вообще, дизайн ревью необходимы для того, чтобы сделать code review более эффективными на практике. Почему:

И 5-е. Пожалуй, самое существенное. Введение design review имеет радикальный положительный эффект на сроки разработки и их предсказуемость в условиях наличия новых, неопытных сотрудников, в условиях присутствия значительной базы существующего кода. Проверено.

Подобные сотрудники тратят достаточно много времени на то, чтобы разобраться с существующим кодом, и найти правильный способ решения своих задач. Часто выясняется, что их подходы неверны, что приводит к затягиванию сроков из-за того, что они сами постоянно переделывают свою работу, или молча тупят, либо — к потоку дефектов в соседнем коде, индуцированным их действиями. Они повышают хрупкость кода и вносят баги со странными симптомами, которые потом ловятся опытными сотрудниками.

Введя обязательное design review, вы бьете подход к проблеме на два этапа, проскочить которые нельзя. 1 — "я понимаю, что и как я собираюсь сделать", и 2 — "я делаю". Делая это, вы выносите источник неопределенности в первый этап, который строго ограничиваете временными рамками, и сотрудник делает доклад о выбранном подходе к решению проблемы. Он должен описать изменения с точностью до класса. Его доклад слушают 1-2 опытных разработчика, и ищут ошибки. По показаниям — проводя ликбез в виде кратких лекций по архитектуре и принципам устройства системы, если это необходимо (правильное решение задачи проектирования является как бы практическим заданием к лекции — так автоматически само собой получается).

После того, как предлагаемое решение прошло design review, у сотрудника уже практически не остается шансов дать большую вариацию в сроке выполнения работы — вся неопределенность снята . Как и по крупному налажать. Кроме того, при данной схеме мы контроллируем обучение сотрудника.

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

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

Здравствуйте, 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. Зато более современный контроллер, пересылающий большими блоками, будет использоваться эффективнее.

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

DST>Есть вопрос. Кто ещё знает достойные codereview tool? Обязательно чтоб web based. Сервер можно усебя поднять. Бесплатный или лекарство можно найти.

Расскажу как устроено у нас.
Правило: каждый коммит постфактум должен просмотреть ещё один человек (своеобразная постмодерация).
Есть более менее постоянная схема кто за кем инспектирует. Она периодически меняется, но каждый человек в каждый момент времени знает, кого он инспектирует.

Исходники в SVN. О каждом коммите оповещение приходит всей группе.
Если закоммитил тот, кого я инспектирую, я должен просмотреть его коммит (черепашка, diff, либо прямо открыть код в студии) и если замечаний нет, то дописать к сообщению в логе префикс "OK-pe". (pe — это мой username в SVN). В идеале в логе коммитов все сообщения должны начинаться с "OK-ктоНибудь" — это означает, что коду в репозитории можно доверять. Если есть замечания — префикс будет не OK, а "!-pe", а в конец сообщения в лог я допишу свои замечания.

В SVN-е настроен хук, который реагирует на смену сообщения лога и шлет оповещение об этом тому, кто делал этот коммит. Так автор узнает, что я проинспектировал его коммит и увидит сделанные мной замечания.

Есть ещё некоторое количество договоренностей и даже маленький самописный тул-напоминалка, но главную суть я изложил.
Работает на ура. С завидной периодичностью отлавливаются всякие баги, неточности, корявости. Не 100%, конечно, но довольно много.

Команда — 6 человек. На сколько я знаю похожая схема работает и ещё в паре команд.

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

S>В простом примере — обычное GUI приложение читает порцию данных из файла. Характерное время чтения этой порции — 500мс.
S>В синхронном случае это означает, что основной поток затормозился на полсекунды, а потом продолжил. Если мы сделаем операцию чтения асинхронной, основной поток всё равно никуда не денется. Просто он будет спать в ожидании на GetMessage, а не на ReadFile. Потому, что ему всё равно нечего делать в эти 500мс. Вот если бы ему было что делать — тогда другое дело. Если ему, к примеру, нужно в это же время играть анимацию на экране, то лучше выделить чтение в независимый поток.
S>И вот тут возникает тот момент, который уже обсуждали: синхронное чтение в отдельном потоке отличается от асинхронного чтения через I/O Completion Ports (так эта технология называется по-научному) тем, что не держит занятым один лишний поток. Экономия 1 мегабайта адресного пространства в типичном настольном приложении — фигня, не стоящая усилий.

Плохой пример. Именно для обычного GUI существуют шаблоны MVC, которые в полпинка делают Model асинхронной. Рассуждения понятны, но пример выбран неудачно.

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

XSH>Команда — 6 человек. На сколько я знаю похожая схема работает и ещё в паре команд.

Весьма себе ничего схемка. Ее плюс — она не требует мегатулов, и неплохо работает.

От себя скажу — подобное легко изображается штатнами средствами jira или любого трекера с конфигурируемым воркфлоу. Вводится состояние reviewpending из которого есть возврат автору.

Плюс такого подхода — он делает процесс проще и прозрачнее. Минус (или плюс, это как посмотреть) — всю работу надо проводить через трекер.

A>Хех, а не вы ли лично полтора года назад просили ключ на руборде? Обрадую вас: вам ответили (и довольно давно).
От блин . Я давал мессагу. Уже и забыл, а смотрю через пол года нашёлся добрый человек. Пасибо что ткнули носом.

Ну а всем могу заявить, что пользоваться такими замечательными тулами как crucible и codecolaborator могут даже бедные. Так что не ленитесь, и добавляйте такую активность в ваши процессы.

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

D>Хотелось бы услышать мнение тех, кто переодически учавствует в подобном мероприятии.
У нас практикуется peer review. То есть, изменения просматриваются кем-то из сослуживцев. Как правило, с бОльшим опытом.

D>Есть ли смысл проводить Codу review?
Есть. Очень и очень нередко находятся косяки, которые автор кода просто не видит в силу "замыленности" своего глаза.
И это касается обсолютно всех, вне зависимости от опыта.

D>Ведь когда девелоперы работают на проекте, они так и так смотрят код друг друга.
Не совсем так. Одно дело быстро посмотреть, как привязаться к фунционалу, который был заимплеменчен кем-то другим. Другое дело — более плотно (и критически) просмотреть реализацию этого функционала. Одним движением убивается пара зайцев: и косяки отлавливаются и у ревьювера остается хоть какое-то представление о коде, в разработке которого он не участвовал.

ЗЫ. Пользуемся ClearCase в конфигурации один стрим на девелопера.

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

B>>3 дня назад мне делали. общий обьем — что-то около 3к строк (всего).
B>>человек затратил около 2-х недель, что бы вычитать весь мой код.
...
G>Медленно и неэффективно оно может быть по разным причинам. Например:

все 3 пункта присутствуют. и есть еще один — он тратил на это примерно 1-2 часа в день рабочего времени.
честно говоря, я вообще был удивлен, что кого-то нагрузили вычитывать мой код. во

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

хмм.. если вы так ставите вопрос — то вам точно не надо. Делать это потому, что делают други и не понимать зачем — неблагодарное дело. Поэтому сначала поймите зачем. Именно поймите и после осознания этого вы без проблем объясните это другим и это будет приносить пользу. Поставьте эксперемент на двух сотрудниках — слабом и сильном. Замерьте — что измениться. И вот когда у вас будет вера в этот "шаманский обычай" — вы без лишних сомнений начнете им пользоваться. Это то же относится и ко всем остальным технолгиям и подходам

можно я тут мелкую ремарочку?..

Здравствуйте, SEDEGOFF, Вы писали:
SED>Поставьте эксперемент на двух сотрудниках — слабом и сильном. Замерьте — что измениться.

вот тут я хотел бы заметить, что не проверка "сильным" — "слабого" (а кто их определяет?!..), а проверка "любым — любого".

1) просто проникнитесь, что ваш код (мой код) может открыть и прочитать любой. (я представляю, как передернуло сейчас некоторых "сильных").

2) и представте, что вы вынуждены писать код, который поймет любой. фишка в том, что если "сильного" завтра трамвай... гм... ок. он просто с похмелья на работу не пришел. и вот "слабый" должен до деплоймента закончить его кусок.

это просто первые и понятные всем 2 довода для вычитывания кода "не взирая на лица".

p.s. я не являюсь упертым сторонником код-ревью. но признаю полезность самого процесса "имения". во

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

B>вот тут я хотел бы заметить, что не проверка "сильным" — "слабого" (а кто их определяет?!..), а проверка "любым — любого".

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

Смысл понятен, всем спасибо.
Но вот другай проблема. У нас этим никто не хочет заниматься. Пока директор у нас сказал: по средам нужно уделять час времени на Code Review. Не прокатило, все на это дружно забили.
А у вас чем мотивируется\стимулируется проведение Code Review?
И с чего вообще начать внедрение такого процесса в компании?

Здравствуйте, debugx,

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

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

D>И с чего вообще начать внедрение такого процесса в компании?

Запретить все коммиты в репозиторий, к комменте к которому не указан ревьювер.

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

D>Смысл понятен, всем спасибо.
D>Но вот другаz проблема. У нас этим никто не хочет заниматься.
Люди, это все таки корыстные создания. И заставить их что то делать... ну в общем на мой взгляд гораздо эффективнее что бы человек сам захотел это делать. А почему человек чего то хочет (и именно программист)? Потому что ему что то лень делать и именно в том, что он хочет — есть инструмент как что то не делать. Вот и надо играть на этой лени. Вы попробуйте сами для себя разрисовать долгосрочную перспективу использования этого инструмента. В чем выгода? Где вы будете трудится меньше — где можно ленится больше? В результате вы получите что то вроде целей, в которых будет сказано в чем каждый сотрудник лично приоритет. И вот когда программисты это переварят — когда поймут в чем можно экономить свои силы и в чем каждый из них выиграет — вот тогда им не нужен будет ни директор, ни палка — ничего — они сами начнут это использоваться и через какое то время вспоминать — ой как было ужасно без этого. Итого: найдите выгоду для себя и каждого программиста в частности — после этого все станет проще и понятнее.

Я так внедрял бактрекинг в маленькой команде. Люди напрочь отказывались им пользоваться — лень было писать! Зато теперь заставляют писать всех и сами с радостью пишут — зауши не оттащишь

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

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

D>>И с чего вообще начать внедрение такого процесса в компании?

G>Запретить все коммиты в репозиторий, к комменте к которому не указан ревьювер.

у нас subversion черепашка. Там вроде такое можно настроить, да?

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

SED>Люди, это все таки корыстные создания. И заставить их что то делать... ну в общем на мой взгляд гораздо эффективнее что бы человек сам захотел это делать. А почему человек чего то хочет (и именно программист)? Потому что ему что то лень делать и именно в том, что он хочет — есть инструмент как что то не делать. Вот и надо играть на этой лени. Вы попробуйте сами для себя разрисовать долгосрочную перспективу использования этого инструмента. В чем выгода? Где вы будете трудится меньше — где можно ленится больше? В результате вы получите что то вроде целей, в которых будет сказано в чем каждый сотрудник лично приоритет. И вот когда программисты это переварят — когда поймут в чем можно экономить свои силы и в чем каждый из них выиграет — вот тогда им не нужен будет ни директор, ни палка — ничего — они сами начнут это использоваться и через какое то время вспоминать — ой как было ужасно без этого. Итого: найдите выгоду для себя и каждого программиста в частности — после этого все станет проще и понятнее.

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

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

D>Боюсь перед русским менталитетом такой подход бессилен, хотя допускаю что в западных странах он отлично срабатывает. Нашему кодеру можно объяснить все выгоды от данной процедуры, можно растолковать, как это будет экономить время в будущем, и кодер всё поймет... Но делать всё-равно ничего не станет, если не будет четких изподпалочных указаний.
D>Так что вариант запретить комит без review кода на мой взгляд должен быть эффективным.
С западным менталитетом не работал никогда. С русскими получается прекрасно! Дело не в менталитете, а лени каждого из нас. Обещать абстрактное что то — бессмыслено. Дайте руками потрогать! Если надо — Первый раз из под палки. А когда у человека в голове появится картина: путь номер один — 10 попугаев, путь номер два — 20 попугаев... но попугаев не может быть мало! Поэтому однозначно путь номер два! Вот тогда и начнут использовать.
А жесткие ограничения всегда имеют темную сторону силы... ну если есть светлая, то почему бы и не попробывать? Нет, конечно — есть места, где без ограничений не обойтись (государство например). Но это не значит что нужно все делать через ограничения. Вспомните свою реакцию на какие либо ограничения? Положительная только там, где есть выгода для вас лично

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

SE>Перед тем, как заливать код в TFS проводится ревью кода одним из сениор девелоперов. Важно, что код сениоров тоже подвергается ревью. Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован.

То есть, после коммита, код сначала попадает во временное хранилище. Потом инспектируется лидом, и уже он решает, отправить ли код назад или закоммитить в VCS?
Какие утилиты используются для этого процесса, не подскажешь?

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

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

SE>>Перед тем, как заливать код в TFS проводится ревью кода одним из сениор девелоперов. Важно, что код сениоров тоже подвергается ревью. Формально в хранилище кода TFS вообще не попадает код, который не был проинспектирован.

D>То есть, после коммита, код сначала попадает во временное хранилище. Потом инспектируется лидом, и уже он решает, отправить ли код назад или закоммитить в VCS?

Инспектируется не только лидом. Хотя обычно это сениор-девелопер. Последнее время стараемся отдавать код на ревью тому девелоперу, который имеет наибольний опыт в рассматриваемой части проекта.

D>Какие утилиты используются для этого процесса, не подскажешь?

Все обеспечивается стандартными средствами TFS и VisualStudio А, ну, еще и скайп, чтобы кинуть в обсуждение вопрос: "Кто меня отревьювит?"

1. Девелопер шелвит код в TFS (shelve) — это и есть временное хранилище.
2. Ревьювер аншелвит (unshelve) код. Тут важно предварительно зашелвить свой, чтобы изменения не накладывались.
3. Ревьювер пересматривает код и составляет список рекоммендаций. Иногда что-то уточняет у девелопера.
4. Ревьювер передает список девелоперу, либо шелвит изменения на TFS, если он вносил изменения (не парное программирование, конечно, но бывает что и вместе сидят, правят код)
5. Девелопер вносит изменения, если согласен с ними, или не вносит, если в достаточной мере сумее аргументировать свою точку зрения
6. Изменения либо снова идут на ревью (см. п. 1), либо уходят в TFS.