metrica
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

Вебинар: Трудности при интеграции SAST, как с ними справляться - 04.04

>
>
Пять дней на исправление ошибки в два с…

Пять дней на исправление ошибки в два символа, или миф о всемогущих технологиях при разработке программ

30 Авг 2010

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

Однажды после выпуска новой версии статического анализатора кода PVS-Studio, к нам обратился пользователь, жалующийся на то, что наш инструмент не работает на его сложном проекте. Кстати хороший способ для разработчиков оценить полезность программы – если после очередного релиза вам приходит несколько писем с сообщением что что-то не работает и сломалось, то значит ваша программа нужна. Вернемся к программе. Итак, не работает – это значит не находит файлы для анализа. Сначала были вопросы про тип проекта, про установленные дополнительные плагины к Visual Studio. Выяснилось, что у пользователя установлен компилятор Intel C++ Compiler, но дело не в нем. Также у пользователя была установлена CUDA, но и это оказалось не причем. Кстати, проверка простенького демонстрационного проекта работала, хотя проверка вновь созданной пустой болванки проекта – уже не работала.

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

Под конец пятого дня после неоднократного запуска специальной отладочной версии с расставленными printf (ага, это к вопросу о printf vs новомодные крутые инструменты) выяснилось следующее. Наш анализатор для анализа файлов генерирует специальные cmd-скрипы, в которых есть строка вида:

cd e:\projects\mylib

то есть переход в папку проекта. А как раз в этой версии (предыдущая работала у пользователя нормально) мы сильно переписывали механизм генерации этих скриптов. У команды cd есть особенность – она не переходит в папку на другом диске, если не указать опцию "/d". То есть правильно должно быть так:

cd /d e:\projects\mylib

Этот ключ "/d" был в прошлой версии программы, но по ошибке и недосмотру был потерян в новой версии при переписывании. К сожалению, все тесты у нас запускались с того же системного диска, поэтому команда cd без опции "/d" отрабатывала нормально.

Причем для того, чтобы ошибка проявилась надо обязательно открыть проверяемый проект через Visual Studio (File->Open...). Если же открыть проект, выбрав sln-файл, то ошибка не проявлялась, так как при таком открытии рабочая папка совпадала с папкой, указываемой в команде cd скрипта. Поэтому повторить ошибку не удавалось довольно долго.

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

Какие можно выводы сделать из этой истории? Банальные, но начинающим программистам от этого они менее полезными не станут:

  • Если ваша программа не работает у пользователя, то не стоит винить установленные у него на компьютере программы типа CUDA или Intel C++ Compiler. Хотя и они бывают виноваты.
  • Даже если у вас приложение проходит пять разных типов тестов, то это не значит, что оно работает всегда и везде.
  • Никакой программный инструмент не сможет полностью заменить человеческий мозг. Увы.
  • Если пользователи вашей программы сами программисты, то вам повезло! Ну какие еще пользователи знают слова отладочная версия, дамп и прочее?

Популярные статьи по теме


Комментарии (0)

Следующие комментарии next comments
close comment form