Доработки и обновления 1С — какие бывают, почему ломаются и как минимизировать ошибки

Чтобы система была стабильной и всегда работала, важно вовремя её обновлять. Но часто после обновлений что-то перестает работать. Доходит до того, что пользователи панически боятся обновлений и стараются обновляться как можно реже. Эта практика не лишена здравого смысла, но имеет существенные недостатки.

Поломанные функции раздражают: однажды сделали доработку, проверили её со всех сторон, а после обновления она перестаёт работать. Почему так происходит, даже если обновлениями занимается хороший квалифицированный специалист?

Текст объемный, потому что мы рассматриваем проблему с разных сторон. Со статьёй можно погрузиться в тему и сделать управленческие выводы. В статье много терминов, но мы постарались всё перевести на понятный язык.

Три основных типа доработок в 1С

На вопрос «зачем вообще делать доработки в 1С» нужен большой развёрнутый ответ. Если коротко — доработки помогают улучшить систему и получить преимущество по сравнению с другими компаниями.

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

Сделать доработку так, чтобы она гарантированно не слетала после обновлений — невозможно.

Доработки 1С могут быть такими:
• Внешние доработки: печатные формы. отчеты и т.д.
• Расширения
• Изменения кода типовой конфигурации

Внешние доработки: внешние обработки, отчеты и т.д.

1С — сильная система, в которой многие процессы автоматизированы, но часто пользователи просят доработать программы чуть-чуть, по мелочи:

• разработать специфические отчёты, которых не хватает
• доработать или написать новые печатные формы с нужной информацией и оформлением

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

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

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

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

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

Что на самом деле делает программист при обновлении?
Обычно, программисты выбирают вариант ничего не проверять. Этот вариант и является оптимальным. Ошибки исправляются по обращениям пользователей (да, получается, что тестируют конечные пользователи). Но искать ошибку не надо, она уже найдена, обычно довольно понятна и может быть быстро исправлена.

Как снизить затраты на поддержку доработок?
Как раз для снижения затрат обычно и выбирается вариант — делать все без проверки. Если реально все проверять каждое обновление (и делать его раз в месяц), то затраты получатся большими, а проблемы встречаются нечасто.

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

Для проверки таких критичных доработок можно выделить опытного пользователя, который будет тестировать всё. Ещё один вариант — договориться об этом с вашей обслуживающей компанией.

Расширения: новое слово в доработках 1С

Расширения позволяют точечно дорабатывать 1С: делать заплатки в отдельных документах, добавлять нужные кнопки или писать целые подсистемы — новые функциональные блоки у программы. Доработки выполняются менее «инвазивным» способом и позволяют контролировать изменения основной конфигурации. Если изменение произойдет, разработчику будет выдано соответствующее предупреждение.

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

Расширения появились достаточно давно, но не все программисты их используют. Мы советуем присмотреться к этому механизму: он прост в использовании, не меняет основную конфигурацию 1С и помогает быстро добавлять нужные функции.

Почему могут не работать после обновлений?
Причина все та же (она будет всегда одинаковой) — код вашей конфигурации поменяли разработчики типовой конфигурации 1С, а доработки на него опирались, поэтому перестали работать.

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

Когда возникают проблемы?
В двух основных ситуациях:

• доработки в расширениях сделаны неправильно (про это позже)

• у вас установлено много расширений

Можно создать стандарты доработки расширений, мы работаем именно так. Стандарты помогают сократить частоту поломок после обновлений, но не избежать их на 100%.

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

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

Получается, не нужно проверять множество разных доработанных внешних программных модулей, а можно проверить всё в одном месте.

Спасает ли это на 100%? Нет, без «пользовательского тестирования» все равно не обойтись. Несмотря на то, что грамотно написанные расширения гораздо стабильнее, чем исправление внутри самой конфигурации, и много проблем позволяют выявить в автоматическом режиме.

Как снизить затраты на поддержку доработок?
Для сокращения издержек разработчик и в этом варианте не проверяет «пользовательскую» работоспособность. Иначе поддержка выходит опять же слишком дорогой.
Исправляются проблемы автоматической проверки совместимости, а остальное — по обращениям пользователей.

Как повысить стабильность доработок?
В первую очередь нужно, чтобы разработчики создавали расширения по стандартам и грамотно их использовали.
Если простой для вашей компании критичен, а в программах 1С много расширений, можно обновлять не рабочую базу, а её копию. После обновления копии ваш пользователь или подрядчик тестируют критичный функционал. Если всё в порядке, обновляете рабочую базу с обновлёнными расширениями.

Изменения кода типовой конфигурации

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

Почему могут перестать работать после обновлений?
Причина одна: что-то поменялось в конфигурации поставщика. И последствия тут могут быть сложнее, чем в случае с внешними доработками.

Если в каких-то местах ваш программист изменил код, то изменения от разработчиков 1С могут войти в конфликт с этими изменениями. В этом случае изменения вашего программиста стираются — код заменяется на типовой. Поэтому программисту, который обновляет доработанные конфигурации, нужно вручную отследить изменения и перенести их в новую конфигурацию. При этом важно не потерять изменение: человеческий фактор влияет максимально.
Хорошая практика — комментировать любое именение типового кода, описывать места изменений. Но и это спасает не всегда.

Как избежать ошибок?
Главное — не менять конфигурацию, если доработку можно сделать без этого. Если без изменений никак не обойтись, и это подтверждает грамотный программист, нужно доработать программу аккуратно, добавить пометки об изменении кода прямо в нём.

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

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

Когда возникают проблемы?
В общем случае всегда. Практически любое изменение стандартного кода влечет повышенную сложность сопровождения вашей 1С. Дальше все зависит от квалификации и внимательности программистов, которые вносят изменения в программу и (в большей степени) обновляют её.

Что на самом деле делает программист при обновлении?

Основная задача программиста при обновлении такой 1С — постараться не потерять изменения:
• отметить места, которые слетели
• вручную перенести затертый код
• проверить, не выдает ли программа ошибку при запуске

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

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

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

Если пришлось дорабатывать «по живому», то опять же самый простой и дешевый сценарий — это давать обновленную базу пользователям и в случае ошибок стараться оперативно исправлять. Однако частота возникновения ошибок уже довольно существенная.

Как повысить стабильность доработок?

Тут много направлений:
1. Работать над качеством разработки и комментирования кода.
2. Если доработки ведутся несколькими программистами, налаживать коммуникацию и правила доработок.
3. Вести документацию по обновлениям, фиксировать места, которые точно нужно проверить после обновления.
4. Обязательно обновлять вначале копию, а потом уже рабочую базу.
5. Составить чек-лист проверок критичного функционала и договориться, кто его будет проверять. В идеале нужно на копии базы подготовить примеры (тест-кейсы) по которым кто-то будет обязательно проходить и только после теста разрешать обновлять рабочую базу.
6. Следить, чтобы тест-кейсы были не просто составлены, но и полностью проверялись. Если пользователи не проверяют обновлённую копию или просто делают там пару кликов, проверка не сработает.

Часто ли так делают? К сожалению, не очень. Чаще работает способ — обновить, а потом поправить, если вылезут ошибки. Большая часть обновлений у нас тоже проходит именно по этому сценарию. Почему? Такой подход все равно чаще всего более оптимальный с точки зрения результата и затрачиваемых сил (и денег).

Подытожим

1. Дорабатывать 1С можно тремя основными способами: внешними доработками, расширениями и изменениями типовой конфигурации.
2. Важно выбирать способ доработки исходя из целей, сложности поддержки и затрат.
3. Нужно стараться использовать расширения, они не меняют типовую конфигурацию и создают меньше сложностей при обновлении.
4. Разработчики проверяют работоспособность кода, синтаксические ошибки в нём. Но программисты не отратабатывают пользовательские сценарии.
5. «Проверить, чтобы все работало», к сожалению, невозможно и нецелесообразно, но можно составить чек-лист критических проверок.
6. Сама проверка функционала в «пользовательском режиме» — очень непростая задача, затратная, иногда, кажется, что бессмысленная: если проверяем уже 3-е обновление подряд, ничего не ломается, а времени тратится много.
7. Нужно писать тест-кейсы, по которым реально проверить работу критического функционала.
8. Важно следить, чтобы ответственные пользователи проверяли критический функционал: это снижает количество ошибок в дальнейшем.

Надеемся, стало понятнее, почему доработанная 1С ломается после обновлений. В основном, из-за оптимального использования ресурсов программистов и денег заказчиков. Исправить ошибку, которую выявил пользователь и корректно описал аналитик, намного проще, чем выявить самому разработчику после обновления. Можно сказать, что доработанная 1С ломается из-за заботы о бюджете клиентов.

А что делать, если хочешь дорабатывать 1С и испытывать меньше головной боли?

Автоматическое тестирование — инструмент, кторый помогает дорабатывать 1С. Автоматическое тестирование позволяет с одной стороны получать новые нужные функции, а с другой — не сталкиваться с постоянной поломкой критического функционала на рабочей базе.

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

Автотесты мы используем на собственных разработках и планируем внедрять автоматические тесты клиентам, чтобы повысить качество сопровождения программ 1С.