Хорошие разработчики всячески стремятся снизить количество ошибок в коде и для этого изобретают различные подходы, которые позволяют эти ошибки найти до того, как продукт попадет к пользователям. Тут можно выделить следующие подходы, некоторые из которых могут отсутствовать в вашем производственном цикле:
1. Компиляция.
К счастью, это обязательный шаг и он блокирует дальнейшее движение к пользователю. Однако тут стоит отметить, что различные компиляторы допускают поблажки касаемо строгости следования стандарту C++. Отход от стандарта приводит к проблемам при смене компилятора, платформы или даже версии — особенно больших вложений требовал переход от Visual С++ 2008 к следующей, более стандартной версии. Поэтому стоит рекомендовать настроить сборку так, чтобы проводилась максимальная проверка стандартности кода. Также не лишним будет выставить максимальный уровень предупреждений и хотя бы не допускать роста их количества. Примеры настроек для различных компиляторов можно найти тут.
2. Статический анализ кода.
Компиляторы не ищут проблемы в коде, а лишь проверяют корректность синтаксиса. Чтобы поискать потенциальные проблемы еще до запуска кода, можно попровать синтаксические анализаторы кода. Самый известный в этом плане — cppcheck. Это очень мощное средство позволяет найти довольно много типичных ошибок, к тому же оно бесплатно и поддерживает различные платформы. Тут же стоит отметить существование довольно известных средств pclint и PVS-Studio, но они платные и Windows ориентированы, что может вызывать определенные сложности. Не лишним будет также упомянуть про проект с открытым исходным кодом: SonarQube, в нем поддерживается несколько основных языков, что может оказаться очень удобным.
3. Ревью кода.
Когда статические анализаторы уже отработали, то код уже не стыдно будет показать коллегам. На этом этапе наиболее очевидные ошибки уже исправлены, но могут оставаться не такие заметные и поэтому более опасные проблемы. К тому же никакой универсальный анализатор не проверит, что код выполняет именно то, что было задумано изначально.
Есть несколько способов проводить ревью кода. Один из них — пригласить коллег к своему рабочему месту и показать код параллельно рассказывая что он должен делать. Другой способ — использовать автоматизированные системы. Из различных вариантов я бы выделил бесплатный ReviewBoard с открытым исходным кодом. Это удобное средство не требует устанавливать клиентов на компьютеры разработчиков, т.к. все действие происходит в браузере. Также его легко подогнать под свои нужды интегрировав с репозитарием и баг-трекером.
Не могу не отметить довольно популярное и дорогое решение — Code Collaborator. Мне лично эта штука не нравится, т.к. имеет неприятные ошибки в клиентской части и из-за предлагаемого сценария ревью, однако довольно много и любителей этого средства. Просмотр кода также производится в браузере.
Для команд, которые пользуются только Visual Studio, можно попробовать встроенные в него средства проведения ревью. Появилась эта возможность сравнительно недавно и на семинарах Microsoft почему-то ее не афиширует. При этом через московский офис Микрософт стало известно, что в команде разработчиков TFS существует нехватка в обратной связи от пользователей данного функционала. Ревью можно проводить как в Visual Studio так и в браузере. Очевидно, что присутствует удобная интеграция с TFS.
4. Автоматические модульные тесты.
После того как код уже был проанализирован автоматическими средствами и просмотрен коллегами, его можно уже запускать. Но не весь. Стоит сразу после сборки запускать модульные тесты. И чем больше эти тесты покрывают, тем лучше. Даже само написание тестов уже делает код лучше, т.к. приходится его разбивать на маленькие понятные модули. Помогают писать тесты различные фреймворки. Есть несколько популярных, но я бы выделил Google Test как наиболее универсальный и межплатформенный (тут кто-то может возразить). Фанатам Boost стоит обратить внимание на Boost Unit Test Framework. Также с недавних пор появилась и в Visual Studio поддержка модульных тестов для native кода, хотя native тут надо читать в понимании Микрософта.
5. Автоматические функциональные тесты.
После того как модульные тесты отработали, можно сказать, что модули работают скорее всего корректно. Однако это не дает никаких гарантий по поводу работы продукта в целом. Для проверки его работы нужно проверять сам продукт и его соответствие поставленным задачам. Рутинные операции стоит автоматизировать и для этого существует довольно много средств. Часто они просто запоминают ручную последовательность действий и потом позволяют ее воспроизводить, но существуют и более сложные решения. Чтобы далеко не ходить, можно посмотреть на довольно мощный инструмент в Visual Studio.
6. Ручное тестирование.
После прочтения предыдущих пунктов не торопитесь увольнять своих тестировщиков. В процессе ручного тестирование могут находится самые изощренные и сложновоспроизводимые ошибки. Особенно, если инженер по тестированию подходит к работе с интересом и проявляет чудеса изобретательности. Талантливого тестировщика найти сложно, но если он у вас есть, то не обижайте его и исправляйте найденные ошибки.
Хорошие тестировщики тестируют не только руками, но и головой и используют различные средства поиска утечек памяти, проверяют загрузку процессора, сети и анализируют прочие активности на компьютере и могут увидеть корреляцию между этими показателями и каким-то необычным поведением продукта. В этом еще здорово помогают такие простые бесплатные средства как Process Monitor и Process Explorer. В общем, хороший тестировщик может сильно сократить время выявления причин ошибок в продукте.
Такой вот очень краткий обзор, но, надеюсь, поможет взглянуть на свои процессы свежим взглядом. Удачной охоты за ошибками.
