Теория поиска ошибок :)

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

Автор: Слава Кирлан

Преамбула

Ошибки есть всегда. Если ошибок нет - это значит, что их еще не нашли. Если в программе не найдено ни одной ошибки – значит эта программа никому не нужна, и никто ей не пользуется :).

Ошибаться не стыдно и не плохо (если мы, конечно, не говорим о сознательном вредительстве :) ). Плохо не пытаться их исправить. Совсем грустно, если исправить их нельзя. Но тут уж остается только смириться и «учесть-на-будушее», если оно (будущее) есть.

Попытаюсь изложить тут свои соображения о том, как бороться с ошибками. Это всего лишь мои мысли, и не настаиваю что они совсем уж правильные. Возможно, я где-то у кого-то что-то слямзил на этот счет, но, честное слово сделал, это подсознательно и не надо меня обвинять в плагиате (по крайней мере, осознанном). Достаточно просто указать  где,  у кого и что (исправлюсь :) ).

Сразу хочется сказать, что есть такие не хорошие «плавающие» ошибки (они то есть, то их нет, при видимых одинаковых условиях). Печально, когда на них нарываешься и бороться с ними очень сложно – тут нужен имеющийся опыт, интуиция и бубен. Но и то, эта ошибка не берется из ни откуда, и у нее есть своя причина, только до причины этой очень сложно докопаться.

И еще, очень важно: прежде чем что-то исправлять в базе (программе) всегда делайте копию.  Не важно, в каком состоянии сейчас база – копия должна быть всегда перед любым изменением (Не поверите, но ситуацию всегда можно ухудшить).

1.     А был ли мальчик?

Первое о чем нужно подумать, если говорят что есть ошибка, а есть ли она? Не нужно сразу открывать конфигуратор (исходный код программы) и анализировать запрос. Нужно попросить пользователя показать эту ошибку. Если, по некой причине, показать он ее не может – досконально опросить в какой момент возникает ошибка, и попытаться ее воспроизвести (предположим, на тестовой базе).

В общем, главное любым способом увидеть эту ошибку своими глазами, или свято поверить, что она есть.

2.     Разделяй и властвуй

Ошибка есть (увидели, убедились, поверили). Она стабильная (повторяется из раза в раз). Теперь мы пытаемся ее «упростить». В разных ситуациях делаем по разному, но суть одна – уменьшить пространство поиска.

2.1 К примеру оборотно-сальдовая ведомость за год показывает неправильные цифры. Начинаем уменьшать период, к примеру, по методу дихотомии золотого сечения (режем пополам и смотрим есть ли ошибка). Берем первое полугодие и смотрим, есть в нем ошибка. Если нет, значит ошибка во втором полугодии (лучше проверить это). Потом второе полугодие делим на кварталы и т.д. и т.п. – старый проверенный способ.

2.2 Другой пример при обмене данными через WEB-сервер в конечную программу попадают неправильные данные. Тут режем по алгоритму:

  1. Запрос формируется в исходной базе
  2. Данные перегоняются по сетке в базу приемник
  3. База приемник получает данные и записывает их

Считаем что каждый этап «Черный ящик» со своим входом и выходом. Вот и проверяем эти входы и выходы (в последовательности кому как нравится).

  1. Смотрим в исходной базе, что выдает запрос. Для этого пользуемся отладчиком, консолью запросов, всем чем угодно, но именно в этой базе (что бы отсечь все другие этапы)
  2. Смотрим, как работает web-сервис (сравниваем что ему отдает запрос, как он эти данные преобразовывает, и получаем ли мы на входе в базу приемник то самое что отправилось из базы источника)
  3. Смотрим, как база приемник разбирает полученные данные. Для этого можно создать (сохранить) отдельный файл обмена, и подавать ее раз за разом в качестве исходных данных (тем самым мы опять таки исключаем два других этапа)

2.3 Если у нас сложный многотабличный запрос – беспощадно его режем. Любой самый сложный запрос всегда состоит из конечного количества маленьких и легких запросиков, которые очень легко анализировать. Убедившись, что отдельные запросики возвращают «правильные» данные, начинаем потихонечку их склеивать в большой и сложный (аккуратно, поочередно), и каждый раз смотрим – правильный ли результат мы получаем

2.4 Если неправильно работает процедура документа (например проведение), тот тут используем отладчик. Все знают, что к любой конфигурации можно подключится отладчиком. Для этого

  • пользовательском режиме у конфигурации должна стоять опция «Параметры / Системные / Отладка разрешена».
  • запустить ту же самую конфигурацию в режиме конфигурирования и через «Отладка / Подключение» подключится к нужному пользовательскому сеансу.

Отдельно скажу, что для отладки процедур выполняемых на  сервере необходимо запустить сервер с параметром  «-debug».

Подключившись отладчиком, используем точки останова, трассировку, табло, стек вызова, «вычисление выражения» и т.д. и т.п., опять таки «режа» код на возможно мелкие кусочки, содержащие ошибку. Мне кажется, найти ошибку при помощи отладчика гораздо проще, чем теоретически анализируя код.

Не думаю, что нужно расписывать все возможности отладчика, поскольку в руководствах пользователя и прочей «официальной литературе» это сделано куда как лучше :)

Наверно, бывают ситуации, когда отладчиком пользоваться невозможно. Тогда предлагаю менять код (только всегда предварительно делайте копии). Используйте сообщения, запись в какие-нибудь регистры, файлы. Да и просто убирайте куски кода. Благо мы не врачи – мы можем себе позволить отрезать «руку» и посмотреть «не перестанет ли болеть голова».

В общем, главное локализовать ошибку (упростить ее).

3. Спасение утопающих

            Нашли ошибку. При ее решении исходим из того, что в 99.9% это ошибка разработчика конфигурации, а не платформы, и исправить ее можно. Более того, решение этой ошибки есть

  • в синтакс-помощнике (среди описания операторов)
  • в пресловутых «желтых книгах»
  • в других конфигурациях (по принципу «как там так и у меня должно быть»)
  • в интернете.

 Очень редко встречаются «новые ошибки». В большинстве случаев это старые ошибки на новый (или не очень) лад. Наверняка кто-то уже сталкивался с этим. Поэтому долго и нудно ищите везде где можете ответ, прежде чем отчаиваться и задавать вопрос кому-нибудь, и вот почему: 

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

 Если уж вы отчаялись и решили спросить, то вопрос должен быть информативным. Бессмысленно спрашивать «Почему у меня в СКД не выводится группировка?». Поясните, что из себя представляет схема, какая группировка у вас не выводится. Если программа выдает ошибку – напишите какую ошибку (прямо тот текст, который выдает программа). Ясно формулируйте, что у вас есть и что вы хотите. Чем понятней будет вопрос – тем больше шансов, что на него будет адекватный ответ. Но тут нужно чувствовать меру: вряд ли кто-то будет читать сообщение, состоящее из 1000 строк с описанием всей ситуации «от сотворения мира».

Вопрос должен быть кратким (читаемым) и конкретным, а иначе получится просто заспаменную тему с ехидными замечаниями «о жизни».

В общем, прежде чем обратиться за помощью, до последнего старайтесь решить ошибку сами.

А тем кто отвечает очень хочется напомнить фразу «Мы все одинаково невежественные, но в разных областях» (Феликс Райчак не помню автора). Если спрашивают – это не значит что тот кто спрашивает глупее, он может быть просто менее опытный в этом вопросе. Хорошо что он пытается учиться, и мерзко его за это гнобить. Если не можешь ответить по теме (более чем пустой фразой «гугл найдет все») – лучше промолчать.

Заключение

Много букв получилось (расчувствовался :) ). Не оригинально, достаточно банально и очевидно. Даже, немного стыдно публиковать :) Но как ни странно очень часто сталкиваешься с тем, что эти всем известные истины люди упорно игнорируют.

Или я в чем-то ошибаюсь?

ЗЫ. Если текст бесполезный – можно снять публикацию. Во вложении, тот же текст но виде файла WORD (на всякий случай)

ЗЫЗЫ. Исправил обнаруженые ошибки

Комментарии

1
  • Дмитрий
    Спасибо автору