Теория поиска ошибок 🙂
Преамбула
Ошибки есть всегда. Если ошибок нет — это значит, что их еще не нашли. Если в программе не найдено ни одной ошибки – значит эта программа никому не нужна, и никто ей не пользуется :).
Ошибаться не стыдно и не плохо (если мы, конечно, не говорим о сознательном вредительстве 🙂 ). Плохо не пытаться их исправить. Совсем грустно, если исправить их нельзя. Но тут уж остается только смириться и «учесть-на-будушее», если оно (будущее) есть.
Попытаюсь изложить тут свои соображения о том, как бороться с ошибками. Это всего лишь мои мысли, и не настаиваю что они совсем уж правильные. Возможно, я где-то у кого-то что-то слямзил на этот счет, но, честное слово сделал, это подсознательно и не надо меня обвинять в плагиате (по крайней мере, осознанном). Достаточно просто указать где, у кого и что (исправлюсь 🙂 ).
Сразу хочется сказать, что есть такие не хорошие «плавающие» ошибки (они то есть, то их нет, при видимых одинаковых условиях). Печально, когда на них нарываешься и бороться с ними очень сложно – тут нужен имеющийся опыт, интуиция и бубен. Но и то, эта ошибка не берется из ни откуда, и у нее есть своя причина, только до причины этой очень сложно докопаться.
И еще, очень важно: прежде чем что-то исправлять в базе (программе) всегда делайте копию. Не важно, в каком состоянии сейчас база – копия должна быть всегда перед любым изменением (Не поверите, но ситуацию всегда можно ухудшить).
1. А был ли мальчик?
Первое о чем нужно подумать, если говорят что есть ошибка, а есть ли она? Не нужно сразу открывать конфигуратор (исходный код программы) и анализировать запрос. Нужно попросить пользователя показать эту ошибку. Если, по некой причине, показать он ее не может – досконально опросить в какой момент возникает ошибка, и попытаться ее воспроизвести (предположим, на тестовой базе).
В общем, главное любым способом увидеть эту ошибку своими глазами, или свято поверить, что она есть.
2. Разделяй и властвуй
Ошибка есть (увидели, убедились, поверили). Она стабильная (повторяется из раза в раз). Теперь мы пытаемся ее «упростить». В разных ситуациях делаем по разному, но суть одна – уменьшить пространство поиска.
2.1 К примеру оборотносальдавая ведомость за год показывает неправильные цифры. Начинаем уменьшать период, к примеру, по методу дихотомии золотого сечения (режем пополам и смотрим есть ли ошибка). Берем первое полугодие и смотрим, есть в нем ошибка. Если нет, значит ошибка во втором полугодии (лучше проверить это). Потом второе полугодие делим на квартала и т.д. и т.п. – старый проверенный способ.
2.2 Другой пример при обмене данными через WEB-сервер в конечную программу попадают неправильные данные. Тут режем по алгоритму:
- Запрос формируется в исходной базе
- Данные перегоняются по сетке в базу приемник
- База приемник получает данные и записывает их
Считаем что каждый этап «Черный ящик» со своим входом и выходом. Вот и проверяем эти входы и выходы (в последовательности кому как нравится).
- Смотрим в исходной базе, что выдает запрос. Для этого пользуемся отладчиком, консолью запросов, всем чем угодно, но именно в этой базе (что бы отсечь все другие этапы)
- Смотрим, как работает web-сервис (сравниваем что ему отдает запрос, как он эти данные преобразовывает, и получаем ли мы на входе в базу приемник то самое что отправилось из базы источника)
- Смотрим, как база приемник разбирает полученные данные. Для этого можно создать (сохранить) отдельный файл обмена, и подавать ее раз за разом в качестве исходных данных (тем самым мы опять таки исключаем два других этапа)
2.3 Если у нас сложный многотабличный запрос – беспощадно его режем. Любой самый сложный запрос всегда состоит из конечного количества маленьких и легких запросиков, которые очень легко анализировать. Убедившись, что отдельные запросики возвращают «правильные» данные, начинаем потихонечку их склеивать в большой и сложный (аккуратно, поочередно), и каждый раз смотрим – правильный ли результат мы получаем.
2.4 Если неправильно работает процедура документа (например проведение), тот тут используем отладчик. Все знают, что к любой конфигурации можно подключится отладчиком. Для этого
- пользовательском режиме у конфигурации должна стоять опция «Параметры / Системные / Отладка разрешена».
- запустить ту же самую конфигурацию в режиме конфигурирования и через «Отладка / Подключение» подключится к нужному пользовательскому сеансу.
Отдельно скажу, что для отладки процедур выполняемых на сервере необходимо запустить сервер с параметром «-debug».
Подключившись отладчиком, используем точки останова, трассировку, табло, стек вызова, «вычисление выражения» и т.д. и т.п., опять таки «режа» код на возможно мелкие кусочки, содержащие ошибку. Мне кажется, найти ошибку при помощи отладчика гораздо проще, чем теоретически анализируя код.
Не думаю, что нужно расписывать все возможности отладчика, поскольку в руководствах пользователя и прочей «официальной литературе» это сделано куда как лучше 🙂
Наверно, бывают ситуации, когда отладчиком пользоваться невозможно. Тогда предлагаю менять код (только всегда предварительно делайте копии). Используйте сообщения, запись в какие-нибудь регистры, файлы. Да и просто убирайте куски кода. Благо мы не врачи – мы можем себе позволить отрезать «руку» и посмотреть «не перестанет ли болеть голова».
В общем, главное локализовать ошибку (упростить ее).
3. Спасение утопающих
Нашли ошибку. При ее решении исходим из того, что в 99.9% это ошибка разработчика конфигурации, а не платформы, и исправить ее можно. Более того, решение этой ошибки есть
- в синтакс-помощнике (среди описания операторов)
- в пресловутых «желтых книгах»
- в других конфигурациях (по принципу «как там так и у меня должно быть»)
- в интернете.
Очень редко встречаются «новые ошибки». В большинстве случаев это старые ошибки на новый (или не очень) лад. Наверняка кто-то уже сталкивался с этим. Поэтому долго и нудно ищите везде где можете ответ, прежде чем отчаиваться и задавать вопрос кому-нибудь, и вот почему:
- Чем дольше вы ищите, тем лучше запомните этот случай и лучше научитесь работать с источниками.
- В процессе поиска вы найдете что-то другое, не относящееся к этому вопросу, но тоже очень полезное.
Если уж вы отчаялись и решили спросить, то вопрос должен быть информативным. Бессмысленно спрашивать «Почему у меня в СКД не выводится группировка?». Поясните, что из себя представляет схема, какая группировка у вас не выводится. Если программа выдает ошибку – напишите какую ошибку (прямо тот текст, который выдает программа). Ясно формулируйте, что у вас есть и что вы хотите. Чем понятней будет вопрос – тем больше шансов, что на него будет адекватный ответ. Но тут нужно чувствовать меру: вряд ли кто-то будет читать сообщение, состоящее из 1000 строк с описанием всей ситуации «от сотворения мира».
Вопрос должен быть кратким (читаемым) и конкретным, а иначе получится просто заспаменную тему с ехидными замечаниями «о жизни».
В общем, прежде чем обратиться за помощью, до последнего старайтесь решить ошибку сами.
А тем кто отвечает очень хочется напомнить фразу «Мы все одинаково невежественные, но в разных областях» (Феликс Райчак не помню автора). Если спрашивают – это не значит что тот кто спрашивает глупее, он может быть просто менее опытный в этом вопросе. Хорошо что он пытается учится, и мерзко его за это гнобить. Если не можешь ответить по теме (более чем пустой фразой «гугл найдет все») – лучше промолчать.
Заключение.
Много букв получилось (расчувствовался 🙂 ). Не оригинально, достаточно банально и очевидно. Даже, немного стыдно публиковать 🙂 Но как ни странно очень часто сталкиваешься с тем, что эти всем известные истины люди упорно игнорируют.
Или я в чем-то ошибаюсь?
ЗЫ. Если текст бесполезный – можно снять публикацию. Во вложении, тот же текст но виде файла WORD (на всякий случай)
ЗЫЗЫ. Исправил обнаруженые ошибки
Дополню с вашего позволения п.1 касательно платформы 8.2
Полезно выяснить так же наблюдается ли ошибка у пользователя, если тоже самое действие выполняется на другой станции, если нет, то вычищаем содержимое папок в профиле пользователя Windows «Application Data1C1C82» и «Local settings1C1C82» и с 90% вероятностью побеждаем ошибку.
Если ошибка не зависит от того где пользователь выполняет проблемное действие, то выясняем наблюдается ли она у других пользователей с такими же правами. Если нет, то скорее всего спасет создание для пользователя другой учетной записи. Если да, проверяем тоже самое действие, но с полными правами. Все равно не проходит — у нас действительно ошибка, получилось с полными правами — ищем куда программа завела пользователя и расставляем недостающие права доступа.
(плюсанул) Доступный язык изложения, четкий алгоритм действий. Начинающим разработчика в печать и на стену.
Не всегда правильно. Если выгоднее обратиться за помощью(деньги/время <-> время/деньги), то очевидно это надо делать. Хотя могут быть и исключения. Обучение например.
(3) delwish, ну конечно все относительно и упирается в ресурсы (поэтому и написал «до последнего», т.е. пока обстаятельства позволяют) 🙂
Опять же, иногда приходится вообще не искать причину ошибки (нет времени) а просто поставить «костыль». Все зависит от ситуации
(0) Я бы ещё добавил «Убедиться, что ошибка связанна с текущей базой»
Пример: Стали удалятся товары с сайта. Вскрытие не дало результатов (как и гугление и логирование и т.д.). Выяснилось (случайно), что имеется на сервере тестовая база (копия рабочей) с пустыми товарами, из которой запускается регламентное задание обмена с сайтом.
(5) Ibrogim,
вы там это… посмотрите, может она (тестовая) сама и напродавала уже чего 🙂
наверное, правильнее так:
При ее решении исходим из того, что
— ошибки платформы можно во внимание не брать вообще — если они и есть, они зафиксированы и всегда можно этот список освежить (берем во внимание более-менее стабильную по сравнению с другими 8.1; 8.2 — если только с натяжкой, и вообще не рассматриваем не-пойми-какую 8.3).
— в 80% это ошибка доработчика конфигурации, а не разработчиков типовых (я бы написал 95% — но, судя сколько ошибок регистрируется, их море разливанное в типовых 🙂 ; однако, не все сталкиваются с ними, и они не все сразу мешают работаь)..
— есть 5% плавающих ошибок (типа использования «мутабельных» значений илип «в данной транзакции уже происходили ошибки»), которые в 1С зафиксировать в принципе невозможно или крайне сложно (проще заглушку поставить).
Я позволю себе немного побрюзжать в стиле граммар-наци.
Если уж речь идет о золотом сечении, то пропорции там явно не 1 к 1.
Приведенный метод поиска ошибка в ОСВ — дихотомия.
Но это досадное обстоятельство нисколько не преуменьшает ценность статьи.
(8) kazkaz, согласен, может ошибся в названии 🙂
(9)
это опять вы вместо «плюсика» в спам мое сообщение отослали? 🙂
Верю, даже очень.
вот вам и пример 🙂
(12) babys, да, виноват 🙂 Но глаз уже «намылился» — не замечаю. Подкоплю немного ошибок — потом все сразу исправлю 🙂
Один из самых главных принципов, как я считаю. К сожалению, пользователям зачастую не хватает умения внятно, четко и конкретно изложить проблему. Хорошо, если ошибка элементарная, типа «комп не включен» или часто встречающаяся. Ее легко узнать по симптомам. А в более сложных случаях надо начинать с того, чтобы самому воочию увидеть ошибку. И зафиксировать способ ее воспроизведения.
Хотя, многое зависит от опыта )) Чем он выше, тем быстрее мы способны решать проблемы, так как в голове уже есть список т.н. «узких мест», где может быть ошибка.
(15) artbear, да, наверно так рациональнее. Но просто подумалось о неких «комбинированных» ошибках (конечно не случай ОСВ), когда предположим отсекая «первую половину кода», у нас пропадает ошибка и во второй части кода. А тогда можно потратить очень много времени на поиск того, чего уже нет.
Статья отличная. Иногда было такое что я пол дня искал решение ошибки которую нашел один пользователь, потом как оказалось ошибки и не было.
Автор а почему у тебя везде слово «Неправильно» пишется «Не правильно»? Тема про ошибки с ошибками 😀
(17) OVladius, Если честно WORD не ругается, а я ему верил 🙂
По этому поводу я уже винился — вот и решил подкапить ошибки, потом сразу все исправить 🙂
Только что было просмотров — 404 =) символично=)
Такие вещи становятся очевидны, только когда все шишки собраны собственным темечком, а все минные поля проползены собственным брюхом. А для новичков — что ж, если кому поможет, будет здорово, но опыт моих наблюдений говорит, что хоть новичку в рамочку такие дела напиши и перед носом повесь, а всё одно игнорирует. Авось не у всех так…
Хорошая статья, спасибо.
(20) Yashazz, Именно, читаешь и видишь, что каждый разумный программист доходит до этого в основном сам
(21) 1cmax, если честно, я вообще сомневаюсь что можно учится на чужих ошибках (хотя пытаться стоит).
Хорошо, если хоть на своих получается
Вот это не помешало бы втолковать и пользователям.
(0) Очень мне нравиться фраза:
Ученого ценят за удачи, а инженера за отсутствие неудач
К сожалению автора не помню (возможно, Гурам Панджикидзе)
Что совсем не согласуется с вашим 1-м абзацем.
(15) artbear,
В народе: «Квадратно-гнездовой метод«
(24) AnryMc, по моему ошибка это еше не неудача. Вот если ошибку не можешь исправить — вот это уже неудача 🙂
Опять же: если панически бояться ошибок, просто остановишся в развитии.
(22) Можно, например, читая Инфостарт ))
норм..ко всему этому сам дошел… интуитивно это понимал и осознавал.. а ты вот взял и по полочкам всё разложил и разжевал.+
(22) ну да, и на своих ошибках учится можно, конечно, но, смотря чему )
свои ошибки у всех бывают в разном количестве )
а поначалу при обучении можно ведь завернуть и не за тот угол … )
Хорошая статья! Автору респект.
Хорошая статья
(0)
Феликс Райчак «Все мы невежды, но в разных специальностях.»,источник (найден через яндекс-поиск) .
Насколько я знаю, «невозможно» пишется слитно. раздельно пишется «Не представляется возможным».
(32) DrAku1a, учту, исправлю 🙂
Текст вовсе не бесполезен. Наоборот — это азы, которые надо знать!
Еще один момент:
Тут Вы путаете понятия «Золотое сечение » и «Дихотомия «.
К слову, описанный алгоритм разделения — это по сути дедуктивный метод Шерлока Холмса.
Вообще-то, задача локализации ошибки не всегда решается фиксацией времени ошибки.
Ошибки то разные бывают!
Есть варианты локализации по номенклатуре… Например при анализе прибыльности.
Возможно в некоторых случаях удобнее будет локализовать по Контрагентам, Организациям и т.д.
Главное, что бы с минимумом трудозатрат вычислить место появления!
И если удаётся локализовать Документ приводящий к ошибке, то 60-70% случаев, это не полностью заполненные данные, в т.ч. реквизиты использованных элементов справочников.
Хотя фантазия Юзеров безгранична! Они почти всегда умудряются найти «обходы системы защиты от дурака».
Очень грамотная и полезная статья! Автору респект
(35) V.Nikonov, конечно не только во время все упирается — это я как пример приводил.
(38) Я думаю, что с учетом обсуждения (и замечаний), есть смысл опубликовать новую редакцию…?
(39) V.Nikonov, ошибки и замечания я исправил.
Описать все случаи и нюансы — это будут «тома», и, опять же, для этого есть комментарии. Возможно, какие-то отдельные моменты требуют отдельных статей (если это будет интересно). Я, думаю, оставлю пока как есть — основные мысли донесены, и уже хорошо. 🙂
Слово УПРОСТИТЬ не совсем корректно. Точнее было бы «максимально конкретизировать». Ведь ошибка от вычисления места образования не становится проще или сложнее…
(40) Я не вижу особой необходимости оформлять правки (зачеркнутые фразы и т.п.).
Подробности поиска разумеется не стоит расписывать слишком подробно (вариантов ту бесконечное число), но намёки на самые распространенные направления движения… очень даже полезно описать.
(41) V.Nikonov, как мне кажется (если есть желание покапаться 🙂 ), «сложнее» или «проще» (в том числе «УПРОСТИТЬ») — это оценочные понятия. «Больщое и страшное» (то что нельзя окинуть одним взглядом) — обычно воспринимается как более сложное, чем «маленькое и симпотичное». Поэтому, думаю, чем меньше будет «область проблемы», тем проше нам будет казаться сама возможность ее решит. Мы будем воспринимать ее как более «простую». Сразу скажу: изменится не проблема, изменится ее восприятие. Отсюда и слово «УПРОСТИТЬ».
Кроме того, «УПРОСТИТЬ», сдается мне, звучит (с сохранением смысла) несколько лучше и понятнее, чем «максимально конкретизировать» 🙂
(43) В таком случае я предпочел бы добавить слово «решение». т.е. (упростить её решение)
или вариант упростить ее устранение
(44) V.Nikonov, хорошо, я буду знать ваши предпочтения 🙂
Поставил плюс. Автору спасибо. Для меня новой информации меньше 1%, но прочитал с интересом.
.Всех с Новым годом и Новой эрой! Странно что ничего не сказано про ошибки отображаемых данных которые решаются путем тестирования базы как в конфигураторе так и встроенной утилитой от 1С. У меня бывали случаи что в отчете показываются остатки на начало, а в базе нет проведенных документов. путем вашей дихотомии я тогда потратил пол дня излазив всю базу и перепроведя и проверив все что можно было, а оказалось база повредилась
(14) Zerkon,
Хотел поставить минус. Не дали. Ну и ладно.
К сожалению, это не «пользователям зачастую не хватает умения внятно, четко и конкретно изложить проблему».
В моей практике гораздо чаще встречалась ситуация, что «программист» не в состаянии ничего понимать окромя оператора «if». Ну, понятно, что виноват не он а «тупой пользователь», который этого оператора не знает.
————-
Из моей практики: до 50% ошибок таковыми не являются, а обусловлены крайне низкой квалификацией внедренца в области внедрения и просто низкой квалификацией пользователя. Ни тот, ни другой, не имеют представления, что и почему делает конфигурация.
(а разработчики типовых конфигураций у 1с, как показала практика, очень любят следовать «букве законодательства»)
(15) artbear,
Ага. А потом выясняется, что у вас 7.7; слетели индексные файлы; и бинарные итоги по каждому полугодию идут, а сбой в непереданных из одного квартала в другой остатках.
Нет.
Автор прав.
Прежде чем резать второе полугодие, убедитесь, что ошибка внутри него, а не на границе с одним из первых.
Такое, к сожалению, тоже случается.
——————————-
Статья немного сумбурная, но в качестве черновика инструкции подойдёт.
(48) Bazyon,
Все зависит от точки зрения )) Я сужу со своей, что, в приницпе, достаточно логично. Заметьте, я ни слова не сказал о низкой квалификации пользователей. У человека может быть огромный опыт практической работы и он может решать большую часть проблем сам. Но, столкнувшись с проблемой, он может не суметь ее четко изложить. Хотя да, с ростом опыта использования программы (в которой случилась ошибка) такое явление обычно сходит на нет.
К сожалению, это не «пользователям зачастую не хватает умения внятно, четко и конкретно изложить проблему».
В моей практике гораздо чаще встречалась ситуация, что «программист» не в состаянии ничего понимать окромя оператора «if». Ну, понятно, что виноват не он а «тупой пользователь», который этого оператора не знает.
Исходя из этого, мне стоит беспокоиться, что Вы считаете мою квалификацию крайне низкой? )
Кстати, здесь
Вы сами себе противоречите. Ошибка она ошибка и есть. Просто причины ее крайне разные.
Инструментом для реализации пункта 2.1 данной статьи может быть отчет«Компаратор оборотов в информационных базах» .
(2) Бубузяка, так и сделаю)))
От себя добавлю вот что:
Когда ищешь что-то в интернете по этой ошибке, то всегда сохранять в онлайновом хранилище (или любым другим способом, который выживет после форс-мажора) вообще всю хоть сколько-нибудь осмысленную и толковую информацию, даже не обязательно имеющую отношение к этой конкретной ошибке. Я для хранения использую свой гугл-аккаунт, еще один хороший вариант — Evernote, но мне он не слишком подходит.
Обязательно правильно (понятно для себя) подписывать закладки.
В дальнейшем, скажем раз в месяц, нужно разгребать накопленные закладки по категориям, которые тоже сугубо индивидуальны, у меня, к примеру, это «1С общая», «1С язык 8.2», «1С язык 8.1», «1С запросы», «1С — SQL», «1С — внешние данные» и т.д.
Несколько раз такая импровизированная база знаний меня очень выручала, сэкономив в итоге кучу времени.
Не повредит и плагин для чистки битых ссылок.
Норм статья.
Трудность работы с программистом заключается в том, что вы не можете понять что он делает до тех пор пока не стало слишком поздно.
— Seymour Cray
— Seymour Cray
Да, это сложно.