Количество багов в нашей коллекции перевалило за отметку 15000. Именно такое количество ошибок обнаружила команда PVS-Studio в различных открытых проектах. Особенно интересно, что это всего лишь побочный результат от написания статей.
20 причин проводить обзоры кода
Перевод
(прим. перев. Перевод немного вольный, но я попытался максимально точно сохранить смысл текста, в то же время отыгравшись на некоторых некритичных моментах, просьба не судить строго :)
Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)
Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.
Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.
Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)
Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.
Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.
5 советов по проведению хорошего обзора кода
Перевод
Обзор кода является одной из самых ценных инженерных практик.
1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.
Как вы могли заметить, в этом списке я не упомянул, что проведение обзоров кода помогает находить ошибки и соблюдать стандарты кодирования, и вот почему:
1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.
10 лет назад эти два пункта имели бы смысл в обзорах кода. Однако сейчас вы должны использовать автоматические средства тестирования и инструменты, следящие за оформлением кода. Это не значит, что во время проведения обзора вы не должны замечать ошибок кодирования и оформления, это значит, что их нахождение не является целью проведения обзора кода.
Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.
1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.
Как вы могли заметить, в этом списке я не упомянул, что проведение обзоров кода помогает находить ошибки и соблюдать стандарты кодирования, и вот почему:
1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.
10 лет назад эти два пункта имели бы смысл в обзорах кода. Однако сейчас вы должны использовать автоматические средства тестирования и инструменты, следящие за оформлением кода. Это не значит, что во время проведения обзора вы не должны замечать ошибок кодирования и оформления, это значит, что их нахождение не является целью проведения обзора кода.
Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.
Ревью кода в mercurial
hg review — полезная плюшка для mercurial'а
У git'а есть GitHub, а у Mercurial'а есть hg review. На самом деле я сравнил козу с бояном.
Ревью кода.
Если вы занимались поиском открытой, свободной, быстрой, маленькой, удобной и красивой системой, для проведения ревью кода, то скорее всего вы потерпели неудачу. Из существующих проектов, я смотрел ReviewBoard, но, как и все созданное крутыми компаниями, оно сложно в установке, настройке и подразумевает не совсем привычный нам сценарий поведения.
И вот появился проект, который дает нам инструмент, а как его использовать — решать нам.
Intel IPP Samples for Windows — работа над ошибками

Это моя очередная заметка о том, как PVS-Studio делает программы более надёжными. То есть где, и какие ошибки он обнаруживает. На этот раз под молоток попали примеры, демонстрирующие работу с библиотекой IPP 7.0 (Intel Performance Primitives Library). Хотел, вначале, этот пост поместить в блог Intel, но потом решил, что это будет совсем уже...
По колено в г… коде

Я по роду своей деятельности много и часто медитирую над разнообразнейшим C++ кодом. И, как говорится, у меня накопилось. Не могу больше нести это в себе. Извините, сейчас и с вами поделюсь.
Скринкаст: статический анализ Си++ кода

На конференции ADD 2011 я выступал с докладом «Статический анализ Си++ кода». Благодаря старанию Стаса Фомина belonesox появился замечательный скринкаст (видео + презентация), который я предлагаю вашему вниманию.
В докладе показано много примеров интересных ошибок, найденных мною в open source проектах. Я расскажу, как можно найти многие подобные ошибки еще на этапе написания кода с помощью методологии статического анализа.
PVS-Studio vs Chromium

В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium — один из лучших проектов, который мы проверяли с помощью PVS-Studio.
Разработчики Intel тоже говнокодят

В последнее время, рассказывая о проверке очередного проекта, я всё время повторял, что это очень качественный код и ошибок в нём практически не найдено. Примером может служить анализ таких проектов, как Apache, MySQL, Chromium. Почему мы выбираем такие приложения, я думаю понятно. Про них всех знают и никому не интересно, какие ужасы можно найти в дипломной работе студента Васи. Однако иногда мы поверяем и те проекты, которые просто случайно попали под руку. Некоторые такие проекты оставляют тяжёлые впечатления в моей тонкой и ранимой душе. В этот раз мы проверили Intel® Energy Checker SDK (IEC SDK).
Проверка Intel IPP Samples for Windows — продолжение

Прогресс не стоит на месте. Развивается и мой любимый статический анализатор кода PVS-Studio. И недавно я понял, что те проекты, которые мы уже проверяли, можно вполне проверять заново. Писать про это новые статьи как-то странно и вряд ли они получатся интересными. Однако одну такую статью я всё-таки думаю надо сделать. Она станет еще одним аргументом в пользу утверждения, что настоящую пользу от статического анализа можно получить только при его регулярном использовании, а не при проверках от случая к случаю. Итак, посмотрим, что же удалось найти нового интересного в проекте Intel IPP Samples.
Почему Code Review в smartnut.ru?
Привет, Хабр! Я — один из команды разработчиков SmartNut, web-сервиса для небольших компаний, занимающихся поддержкой и it-аутсорсингом. Мы гордимся тем, что мы делаем и ничуть не меньше тем, как мы это делаем. Хочу поделиться с вами историей из реальной жизни на тему code review.
Все люди внутри перфекционисты. Если Вы не видите этого в человеке, то это совсем не означает, что этого в человеке нет. Возможно, у себя дома у него идеальный порядок, хотя код он пишет и не очень. Другой же наоборот, может держать порядок в коде или в машине, но где-то попустительствовать в отношении себя.
Однако, проще всего найти перфекциониста в отношении к окружающим. Очень просто требовать идеального выполнения работы, конечно, если ты сам знаешь как её хорошо делать.
Все люди внутри перфекционисты. Если Вы не видите этого в человеке, то это совсем не означает, что этого в человеке нет. Возможно, у себя дома у него идеальный порядок, хотя код он пишет и не очень. Другой же наоборот, может держать порядок в коде или в машине, но где-то попустительствовать в отношении себя.
Однако, проще всего найти перфекциониста в отношении к окружающим. Очень просто требовать идеального выполнения работы, конечно, если ты сам знаешь как её хорошо делать.
Code Review и теория вероятностей

Повторная проверка проекта Notepad++

Прошло более года, как мы проверили Notepad++ с помощью PVS-Studio. Интересно посмотреть, насколько анализатор PVS-Studio стал лучше, и что было исправлено в Notepad++ из прежних ошибок.
Еще одна статья о code review
Что такое code review
Code review - инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявить ошибки, недочеты, расхождения в стиле написания кода, в соответствии написанного кода и поставленной задачи.
К очевидным плюсам этой практики можно отнести:
- Улучшается качество кода
- Находятся «глупые» ошибки (опечатки) в реализации
- Повышается степень совместного владения кодом
- Код приводится к единому стилю написания
- Хорошо подходит для обучения «новичков», быстро набирается навык, происходит выравнивание опыта, обмен знаниями.
Code Review Open Source проектов
Анонсирую собственный эксперимент — сборник обзоров исходного кода Open Source проектов. В первом приближении, проекты ограничиваются JVM платформой. Формат обзоров — цикл сухих статей, объединенных рассматриваемым проектом. В обзор попадают архитектурные особенности, ошибки разработчиков и другие интересные детали реализации.
«Gerrit Code Review»: краткое руководство с картинками

Red and Blue Chair by Gerrit Rietveld (1918)
В компании Badoo есть отдел C/C++-программистов. Отдел довольно небольшой, и потому его сотрудники обычно работают над разными проектами, которые между собой пересекаются только в исключительных случаях.
Одним из негативных последствий такой ситуации является bus factor, который стремится к единице. Для решения этой и других проблем было решено в порядке эксперимента внедрить систему ревизии кода (англ. code review): назначить одного разработчика ревизором у другого и таким образом познакомить его с кодом, а заодно и повысить качество последнего.