Comments 29
Можно обыграть как отдельную «причину» также обоснование включения рефакторинга в беклог итерации (Пример в подходе Скрам).
Если продукт долго растет, в нем накапливаются косяки, в том числе архитектурные. Наступает момент конфликта, когда программисты понимают, что следующий прирост функционала нельзя строить на плохом фундаменте, но Владелец продукта (Product Owner) требует все время итерации потратить на новые функциональные фичи.
Здесь очень кстати сделать обзор кода и соорудить хорошо оформленный документ, описать драматичные моменты… Помогает договориться.
Если продукт долго растет, в нем накапливаются косяки, в том числе архитектурные. Наступает момент конфликта, когда программисты понимают, что следующий прирост функционала нельзя строить на плохом фундаменте, но Владелец продукта (Product Owner) требует все время итерации потратить на новые функциональные фичи.
Здесь очень кстати сделать обзор кода и соорудить хорошо оформленный документ, описать драматичные моменты… Помогает договориться.
Все-таки здесь немного о другом. Вы говорите о рефакторинге всей системы в целом, т.е. все собираются и думают, что мы такого написали и как с этим жить дальше. В обзоре же кода есть автор кода и аудиторы, которые проверяют его код и делают ценные замечания, т.е. здесь все расписано по ролям.
В любом случае, спасибо за комментарий.
В любом случае, спасибо за комментарий.
Не знаю, насколько вам будет интересна следующая история: в компании, где я работаю, процесса code review не было. Когда я начинал его вводить, дела шли с ужасными тормозами — все, включая начальство, то ли боялись, то ли стеснялись.
А рядовые разработчики и вовсе воспринимали код как что-то личное или интимное — не давали никому туда лазать, даже смотреть на него, а за то, что я делал code review и указывал на баги, и вовсе ругались и хотели сломать лицо. Пришлось, правда, слегка автоматизировать этот процесс — мы используем TFS, так что я написал плагин к нему, который по каждому коммиту создает еще один таск типа «make code review, you bastard!», связанный с коммитом, и отправляет его ревьюерам проекта; так что разработчики теперь просто не могут закоммититься, не подав коммит на ревью. Получилось неплохо :)
Счас, правда, все гладко; однако плохо то, что я уверен, что они смирились, а не пошли навстречу и признали пользу :/
А рядовые разработчики и вовсе воспринимали код как что-то личное или интимное — не давали никому туда лазать, даже смотреть на него, а за то, что я делал code review и указывал на баги, и вовсе ругались и хотели сломать лицо. Пришлось, правда, слегка автоматизировать этот процесс — мы используем TFS, так что я написал плагин к нему, который по каждому коммиту создает еще один таск типа «make code review, you bastard!», связанный с коммитом, и отправляет его ревьюерам проекта; так что разработчики теперь просто не могут закоммититься, не подав коммит на ревью. Получилось неплохо :)
Счас, правда, все гладко; однако плохо то, что я уверен, что они смирились, а не пошли навстречу и признали пользу :/
Да уж, тяжелый случай :)
А с какими-нибудь программами из списка в статье пробовали работать?
В моей компании, к сожалению (или к счастью?), всего 2 разработчика, включая меня, так что обзор кода идет спонтанно и довольно часто :)
а за то, что я делал code review и указывал на баги, и вовсе ругались и хотели сломать лицоэто и вовсе говорит о непрофессионализме.
А с какими-нибудь программами из списка в статье пробовали работать?
В моей компании, к сожалению (или к счастью?), всего 2 разработчика, включая меня, так что обзор кода идет спонтанно и довольно часто :)
>№14… Вы становитесь лучше.
как же без этого -)
как же без этого -)
Тут еще есть определенная война авторитетов. Все мужики — лидеры. Если кто-то не лидер в душе — это лузер. Соответственно, есть люди, которые в себе самоуверены настолько что чужое мнение слушают только чтобы «не зудел под ухом», но на самом деле просто продумывают как сказать ответ. Здесь начинаются холивары. У меня и был в команде и есть такой разработчик, с ними очень сложно.
Хех, я, к сожалению, пока не могу себя заставить целенаправленно делать ревью кода, это все-таки утомительно. Да и делая ревью какого-то определенного участка, часто не замечаю каких-то вещей.
Ревью обычно получается спонтанно, когда еще раз по каким-либо причинам просматриваешь свой код, пытаясь исправить баг №какой-то, и находишь еще десяток ошибок, опечаток и возможностей к оптимизации.
не всегда это так эффективно, как тут написано. ревью само по себе занимает много времени. а уже отловленный кем-то баг — это практически указатель, где ошибка. воспроизводим баг, смотрим бектрейс, делаем микроревью — и все, вот она, ошибка. то есть исправление несложного бага быстрее, чем ревью кучи кода.
хотя конечно, в каждом конкретном случае — свое.
Ревью обычно получается спонтанно, когда еще раз по каким-либо причинам просматриваешь свой код, пытаясь исправить баг №какой-то, и находишь еще десяток ошибок, опечаток и возможностей к оптимизации.
Найди и уничтожь ошибки там, где они живут, вместо поиска гнезда по ихдерьмуэкскрементам.
не всегда это так эффективно, как тут написано. ревью само по себе занимает много времени. а уже отловленный кем-то баг — это практически указатель, где ошибка. воспроизводим баг, смотрим бектрейс, делаем микроревью — и все, вот она, ошибка. то есть исправление несложного бага быстрее, чем ревью кучи кода.
хотя конечно, в каждом конкретном случае — свое.
то есть исправление несложного бага быстрее, чем ревью кучи кода.
Здесь вы, разумеется, правы, автор скорее имел в виду что ошибки, сообщаемые аудиторами при обзоре кода, будут описаны точнее и исправить их будет проще, чем ошибки сообщаемые пользователями. Понятно, что даже затраты по времени на исправление несложного бага будут меньше, чем проведение полноценного обзора. С другой стороны, вы исправите только этот баг, тогда как обзор возможно найдет и другие.
В общем то ещё хорошо помогает натаскивание компилятора, чтобы он на любые потенциальные ошибки лаял, а чтобы их исправляли быстрее делаем так, чтобы при возникновении предупреждения он прекращал компиляцию.
Во-первых, хочу сказать переводчику — пользуйтесь общепринятой терминологией, не выдумывайте свою. «Обзоры» в среде программистов не говорят. Говорят «ревью кода» или «ревизии кода».
Во-вторых, причины какие-то надуманные. Скорее, это всё возможные следствия хорошо организованного ревью. Основное, что получаем от ревью — повышение качества кода.
Во-вторых, причины какие-то надуманные. Скорее, это всё возможные следствия хорошо организованного ревью. Основное, что получаем от ревью — повышение качества кода.
Вы угадали, я долго думал над этим термином и не мог найти «официального» устоявшегося перевода, ваши варианты меня также не устроили: «ревью кода» это уж слишком банальная калька с английского, а «ревизия кода» больше пересекается с отдельной ревизией кода в системе контроля версий (VCS). Также, вроде бы, термин «обзоры кода» я встречал в «Совершенном коде» Макконнелла, но точно сказать не могу, т.к. книги сейчас под рукой нет. Скорее всего, «рецензирование кода» будет наиболее подходящим вариантом, в следующий раз буду использовать его :)
На счет причин, такое ощущение, что автор выжимал из себя максимум, чтобы набрать 20 причин для круглого числа. Действительно хороши где-то первые 10, остальные уже поскольку постольку.
На счет причин, такое ощущение, что автор выжимал из себя максимум, чтобы набрать 20 причин для круглого числа. Действительно хороши где-то первые 10, остальные уже поскольку постольку.
У меня создалось впечатление, что меня хотят «заболтать».
ИМХО, слишком много воды, за которой иногда теряется суть:
Ревью необходим для
1. Обучения «молодых»
2. Универсализации стиля
3. Нахождение «мелких» ошибок в коде
4. В идеале — нахождение архитектурных проблем в момент, когда они ещё не успели «пустить корни»
Причём, именно в таком порядке по убыванию вероятности обнаружения.
Всё остальное — следствия, причём, очень часто, повторяющиеся.
ИМХО, слишком много воды, за которой иногда теряется суть:
Ревью необходим для
1. Обучения «молодых»
2. Универсализации стиля
3. Нахождение «мелких» ошибок в коде
4. В идеале — нахождение архитектурных проблем в момент, когда они ещё не успели «пустить корни»
Причём, именно в таком порядке по убыванию вероятности обнаружения.
Всё остальное — следствия, причём, очень часто, повторяющиеся.
Один момент у нас в компании (компания большая и неповоротливая) у некоторых людей появилась мысль проводить обзор кода. Но т.к. не было специалистов, которые бы обладали знаниями по этой теме, а начальство не очень приветствовало идеи снизу, которые ломают привычные процедуры, то идея умерла не дойдя до реализации. Код до сих пор поставляем отвратный — с тучей ошибок.
Может кто-нибудь поделится ссылкой, типа «Ревью кода для чайников», чтобы понять с чего начать и как этот процесс провести.
Может кто-нибудь поделится ссылкой, типа «Ревью кода для чайников», чтобы понять с чего начать и как этот процесс провести.
Присмотритесь к Code Collaborator, он указан в статье. Хоть это и платный продукт, им можно пользоваться бесплатно в течение 30 дней. По ссылке есть довольно много материала и даже 2 достаточно наглядных демо.
Также они бесплатно высылают книгу «Best Kept Secrets of Peer Code Review», но, к сожалению, для очень ограниченного числа стран, России там нет.
Для более полного погружения в тему, почитайте главу «Совершенного кода» Макконнелла (я уже раз в 5 его рекомендую наверное в этом топике :)), посвященную обзорам, а также обратите внимание на список литературы по теме в конце главы. Взять книгу можно, например, здесь. На stackoverflow.com рекомендуют также вот эту книгу.
Также они бесплатно высылают книгу «Best Kept Secrets of Peer Code Review», но, к сожалению, для очень ограниченного числа стран, России там нет.
Для более полного погружения в тему, почитайте главу «Совершенного кода» Макконнелла (я уже раз в 5 его рекомендую наверное в этом топике :)), посвященную обзорам, а также обратите внимание на список литературы по теме в конце главы. Взять книгу можно, например, здесь. На stackoverflow.com рекомендуют также вот эту книгу.
Большое спасибо! Обязательно ознакомлюсь и постараюсь протолкнуть процесс ещё раз.
Шутите? Вы цены видели: smartbear.com/codecollab-buy.php? Это неадекватно дорого. ReviewBoard при таком раскладе куда оправданнее.
макконел писал, что формальные инспекции кода предоставляют 55% эффективность в нахождении дефектов, что очень круто.
по своим годам опыта вот что могу сказать — если есть возможность зачекинить код, пропустив этап инспекции, разработчик будет пользоваться этой возможностью. особенно у нас в сраной рашке(тм)
очень хотелось бы заполучить тулзу, обеспечивающую следующий процесс — «разработчик комитит код»-«код попадает на инспекцию»-«код возвращается на доработку»-«код попадает на инспекцию»-«инспекция завершена»-«код попадает в хранилище».
по своим годам опыта вот что могу сказать — если есть возможность зачекинить код, пропустив этап инспекции, разработчик будет пользоваться этой возможностью. особенно у нас в сраной рашке(тм)
очень хотелось бы заполучить тулзу, обеспечивающую следующий процесс — «разработчик комитит код»-«код попадает на инспекцию»-«код возвращается на доработку»-«код попадает на инспекцию»-«инспекция завершена»-«код попадает в хранилище».
А почему кстати до сих пор нет облачного сервиса для код ревью? Например я написал свой первый код на Haskell и хочу чтобы меня потыкали знатоки, за $ например. Нет такого?
Sign up to leave a comment.
20 причин проводить обзоры кода