Количество багов в нашей коллекции перевалило за отметку 15000. Именно такое количество ошибок обнаружила команда PVS-Studio в различных открытых проектах. Особенно интересно, что это всего лишь побочный результат от написания статей.
(прим. перев. Перевод немного вольный, но я попытался максимально точно сохранить смысл текста, в то же время отыгравшись на некоторых некритичных моментах, просьба не судить строго :)
Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)
Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.
Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.
Обзор кода является одной из самых ценных инженерных практик.
1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.
Как вы могли заметить, в этом списке я не упомянул, что проведение обзоров кода помогает находить ошибки и соблюдать стандарты кодирования, и вот почему:
1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.
10 лет назад эти два пункта имели бы смысл в обзорах кода. Однако сейчас вы должны использовать автоматические средства тестирования и инструменты, следящие за оформлением кода. Это не значит, что во время проведения обзора вы не должны замечать ошибок кодирования и оформления, это значит, что их нахождение не является целью проведения обзора кода.
Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.
У git'а есть GitHub, а у Mercurial'а есть hg review. На самом деле я сравнил козу с бояном.
Ревью кода.
Если вы занимались поиском открытой, свободной, быстрой, маленькой, удобной и красивой системой, для проведения ревью кода, то скорее всего вы потерпели неудачу. Из существующих проектов, я смотрел ReviewBoard, но, как и все созданное крутыми компаниями, оно сложно в установке, настройке и подразумевает не совсем привычный нам сценарий поведения.
И вот появился проект, который дает нам инструмент, а как его использовать — решать нам.
Это моя очередная заметка о том, как PVS-Studio делает программы более надёжными. То есть где, и какие ошибки он обнаруживает. На этот раз под молоток попали примеры, демонстрирующие работу с библиотекой IPP 7.0 (Intel Performance Primitives Library). Хотел, вначале, этот пост поместить в блог Intel, но потом решил, что это будет совсем уже...
Я по роду своей деятельности много и часто медитирую над разнообразнейшим C++ кодом. И, как говорится, у меня накопилось. Не могу больше нести это в себе. Извините, сейчас и с вами поделюсь.
На конференции ADD 2011 я выступал с докладом «Статический анализ Си++ кода». Благодаря старанию Стаса Фомина belonesox появился замечательный скринкаст (видео + презентация), который я предлагаю вашему вниманию.
В докладе показано много примеров интересных ошибок, найденных мною в open source проектах. Я расскажу, как можно найти многие подобные ошибки еще на этапе написания кода с помощью методологии статического анализа.
В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium — один из лучших проектов, который мы проверяли с помощью PVS-Studio.
Это третья статья, где я хочу рассказать про новую пару приёмов при программировании, которые помогут сделать код более простым и надежным. С предыдущими двумя заметками можно познакомиться здесь [1] и здесь [2]. В этот раз примеры будут взяты из проекта Qt.
В последнее время, рассказывая о проверке очередного проекта, я всё время повторял, что это очень качественный код и ошибок в нём практически не найдено. Примером может служить анализ таких проектов, как Apache, MySQL, Chromium. Почему мы выбираем такие приложения, я думаю понятно. Про них всех знают и никому не интересно, какие ужасы можно найти в дипломной работе студента Васи. Однако иногда мы поверяем и те проекты, которые просто случайно попали под руку. Некоторые такие проекты оставляют тяжёлые впечатления в моей тонкой и ранимой душе. В этот раз мы проверили Intel® Energy Checker SDK (IEC SDK).
Прогресс не стоит на месте. Развивается и мой любимый статический анализатор кода PVS-Studio. И недавно я понял, что те проекты, которые мы уже проверяли, можно вполне проверять заново. Писать про это новые статьи как-то странно и вряд ли они получатся интересными. Однако одну такую статью я всё-таки думаю надо сделать. Она станет еще одним аргументом в пользу утверждения, что настоящую пользу от статического анализа можно получить только при его регулярном использовании, а не при проверках от случая к случаю. Итак, посмотрим, что же удалось найти нового интересного в проекте Intel IPP Samples.
Привет, Хабр! Я — один из команды разработчиков SmartNut, web-сервиса для небольших компаний, занимающихся поддержкой и it-аутсорсингом. Мы гордимся тем, что мы делаем и ничуть не меньше тем, как мы это делаем. Хочу поделиться с вами историей из реальной жизни на тему code review.
Все люди внутри перфекционисты. Если Вы не видите этого в человеке, то это совсем не означает, что этого в человеке нет. Возможно, у себя дома у него идеальный порядок, хотя код он пишет и не очень. Другой же наоборот, может держать порядок в коде или в машине, но где-то попустительствовать в отношении себя.
Однако, проще всего найти перфекциониста в отношении к окружающим. Очень просто требовать идеального выполнения работы, конечно, если ты сам знаешь как её хорошо делать.
Не все программисты хорошо знакомы с теорией вероятностей. Казалось бы — ну какая тут беда? Кто на что учился, гениев-универсалов не бывает. Теорвер на хорошем уровне нужно знать разве что в геймдеве, криптографии ну и может во всяком финансово-статистическом софте. Ан нет! Непонимание некоторых вещей может привести к плохим результатам даже в проектах, где его применением и не пахнет. Нет никакой магии, просто мозг человека неверно оценивает некоторые вероятности и, как результат, принимает неверные решения.
Прошло более года, как мы проверили Notepad++ с помощью PVS-Studio. Интересно посмотреть, насколько анализатор PVS-Studio стал лучше, и что было исправлено в Notepad++ из прежних ошибок.
Code review - инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявить ошибки, недочеты, расхождения в стиле написания кода, в соответствии написанного кода и поставленной задачи.
К очевидным плюсам этой практики можно отнести:
Улучшается качество кода
Находятся «глупые» ошибки (опечатки) в реализации
Повышается степень совместного владения кодом
Код приводится к единому стилю написания
Хорошо подходит для обучения «новичков», быстро набирается навык, происходит выравнивание опыта, обмен знаниями.
Анонсирую собственный эксперимент — сборник обзоров исходного кода Open Source проектов. В первом приближении, проекты ограничиваются JVM платформой. Формат обзоров — цикл сухих статей, объединенных рассматриваемым проектом. В обзор попадают архитектурные особенности, ошибки разработчиков и другие интересные детали реализации.
В компании Badoo есть отдел C/C++-программистов. Отдел довольно небольшой, и потому его сотрудники обычно работают над разными проектами, которые между собой пересекаются только в исключительных случаях.
Одним из негативных последствий такой ситуации является bus factor, который стремится к единице. Для решения этой и других проблем было решено в порядке эксперимента внедрить систему ревизии кода (англ. code review): назначить одного разработчика ревизором у другого и таким образом познакомить его с кодом, а заодно и повысить качество последнего.
Не все программисты хорошо знакомы с теорией вероятностей. Казалось бы — ну какая тут беда? Кто на что учился, гениев-универсалов не бывает. Теорвер на хорошем уровне нужно знать разве что в геймдеве, криптографии ну и может во всяком финансово-статистическом софте. Ан нет! Непонимание некоторых вещей может привести к плохим результатам даже в проектах, где его применением и не пахнет. Нет никакой магии, просто мозг человека неверно оценивает некоторые вероятности и, как результат, принимает неверные решения.
