Ситуация, когда программист становится «16-м исполнителем» в базе с длинной историей доработок, является классической для экосистемы 1С. Основная сложность заключается не в самой платформе, а в накопленном техническом долге, конфликтах расширений и отсутствии единого стандарта кодирования. Рассмотрим подробно, как минимизировать риски «обрушения» системы и грамотно выстроить отношения с заказчиком в таких условиях.
Когда в базе поработали десятки специалистов, она превращается в «карточный домик». Основная опасность заключается в том, что очередное, даже незначительное изменение (например, добавление «волшебной кнопки» через расширение) может стать критической массой, приводящей к деградации производительности или блокировке работы пользователей. Технический долг — это невидимые для бизнес-заказчика ошибки проектирования, избыточные индексы, дублирование кода и нарушение логических связей.
Проанализируем типичные признаки проблемной базы, упомянутые практикующими специалистами:
MSSQL сервера при простых операциях.Процедура Огонь()).Прежде чем приступать к реализации задачи («хотелки») заказчика, необходимо провести диагностику. Никогда не обещайте результат, не оценив состояние «фундамента». Разберем, что должен включать минимальный аудит:
Error, Warning).Если аудит показал наличие проблем, работу следует выстраивать по строгому регламенту. Рассмотрим пошагово безопасный алгоритм внесения изменений:
PEP-8 в 1С, мы можем использовать современные средства разработки.Для проверки качества кода рекомендуется использовать 1C:Enterprise Development Tools (EDT) или специализированные линтеры. Они позволяют на лету обнаруживать мертвый код и неоптимальные обращения к серверу. Пример проверки безопасности кода может выглядеть как поиск прямых запросов к таблицам в обход объектной модели, что часто ломает базу:
// Пример неоптимального обращения, которое может привести к блокировкам
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ * ИЗ Справочник.Контрагенты"; // Плохая практика для больших баз
Результат = Запрос.Выполнить();
Зачастую заказчик не понимает, почему он должен платить за анализ, если ему «нужна просто кнопка». Разберем, как аргументировать свою позицию:
Использование повышающих коэффициентов: Если конфигурация сильно изменена и нетиповая, установите коэффициент 1.5–2.0 к стоимости работ. Это покроет дополнительные трудозатраты на изучение чужого кода.
Договор и акты: В договоре необходимо четко прописать ответственность сторон. Важный пункт — фиксация состояния базы на момент начала работ. Если в базе уже есть «битые» ссылки и ошибки формата потока, это должно быть задокументировано, чтобы 16-й исполнитель не стал виноватым в старых грехах.
Рассмотрим ситуацию, когда заказчик считает, что раз база «еще работает», то всё в порядке. В этом случае объяснение «на языке программиста» не поможет. Попробуем использовать аналогии из бизнеса или техники:
«Ваша база сейчас напоминает автомобиль, который проехал 500 000 км без капремонта, и в нем 15 разных механиков меняли детали на проволочки. Моя задача — поставить новую мощную аудиосистему (вашу кнопку). Но если я её включу, может сгореть вся старая проводка. Поэтому я сначала должен проверить состояние проводов».
Для успешной работы в условиях высокой сложности 1С придерживаемся следующих правил:
1С:ИТС.ПриСозданииНаСервере. Это снижает вероятность конфликтов при обновлении конфигурации.Помните, что ответственность за работоспособность системы после внесения изменений всегда лежит на последнем исполнителе. Ваша задача — либо убедить заказчика в необходимости исправления критического технического долга, либо зафиксировать отказ от ответственности за стабильность системы в условиях накопленных ранее ошибок.