Вопрос соблюдения стандартов разработки и глубокого владения Библиотекой стандартных подсистем (БСП) становится критическим при переходе из небольших франчайзи в крупные проекты или продуктовые компании. Разберем детально, как превратить «хаотичный» код в профессиональную разработку, соответствующую канонам фирмы «1С».
Метод глубокого погружения через анализ типовых решений
Один из самых быстрых способов понять, как должен выглядеть качественный код — это метод «подражания». Разберем, на что именно нужно обращать внимание при изучении типовых конфигураций (например, ЕРП или Бухгалтерия предприятия 3.0):
Именование переменных и методов. Забудьте о коротких названиях типа ВыбДок или ТЗ. По стандартам каждое имя должно быть максимально информативным: ВыбранныйДокументРеализация, ТаблицаЗначенийСоставаТоваров.
Оформление модулей. Обратим внимание на отступы (использование табуляции) и группировку кода. Каждая процедура должна иметь четкое документирование в заголовке, где описаны параметры (входные/выходные) и их типы.
Защита от ошибок («защита от дурака»). Проанализируем, как в типовых проверяются условия перед обращением к свойствам объектов. Никогда не обращайтесь к реквизиту через точку, не убедившись, что ссылка не пустая и объект существует.
Системный подход к изучению стандартов
Просто прочитать портал ИТС недостаточно. Разберем пошаговый алгоритм освоения стандартов:
Изучение по разделам. Выберем один раздел стандартов (например, «Работа с запросами») и изучим его.
Ретроспективный анализ. Вспомним свои прошлые задачи и проанализируем, как их можно было решить согласно новому знанию.
Практическое внедрение. В течение следующей недели при решении текущих задач фокусируемся именно на этом правиле. Если проверка практикой прошла успешно — добавляем конструкцию в свои шаблоны кода.
Инструменты автоматизации контроля качества кода
Чтобы не держать все правила в голове, воспользуемся специализированным программным обеспечением. Это позволит автоматизировать процесс проверки и быстро выучить типичные ошибки.
Рассмотрим основные инструменты:
1С:Автоматизированная проверка конфигураций (АПК). Официальный инструмент от «1С», который выполняет глубокий статический анализ кода на соответствие стандартам.
Phoenix BSL. Отличный инструмент для быстрой проверки кода, который можно интегрировать в процесс разработки. Он подсвечивает проблемные места в реальном времени.
1C:EDT (Enterprise Development Tools). Современная среда разработки на базе Eclipse, в которую встроены механизмы проверки кода «на лету». Использование EDT само по себе приучает писать код чище.
БСП огромна, и выучить её всю невозможно. Однако важно понимать архитектурную логику библиотеки. Проанализируем, как правильно подходить к её изучению:
Демонстрационная база. Установим «Демонстрационную конфигурацию БСП». В ней наглядно показано использование каждой подсистемы. Если нужно внедрить, например, «Присоединенные файлы», сначала смотрим, как это реализовано в демо-базе.
Помощник внедрения БСП. Это специальная обработка, входящая в состав дистрибутива. Разберем процесс внедрения новой подсистемой именно через неё — она покажет все необходимые связи и настройки.
Переопределяемые модули. Это ключ к профессиональному владению БСП. Поймем принцип: мы не правим основной код подсистемы, а вносим свои изменения в специально предназначенные для этого модули с постфиксом Переопределяемый. Это гарантирует беспроблемное обновление в будущем.
Работа с СКД и интерфейсные стандарты
Разработка отчетов — это лицо программиста. Посмотрим, что отличает отчет по стандартам:
Использование только управляемых форм.
Добавление отборов на все значимые поля в шапку отчета.
Возможность расшифровки до регистраторов.
Наличие нескольких вариантов отчета в одной схеме.
Рассмотрим пример правильной структуры запроса в СКД, избегая обращений через точку в условиях, что критично для производительности:
ВЫБРАТЬ
Продажи.Номенклатура КАК Номенклатура,
Продажи.КоличествоОборот КАК Количество
ИЗ
РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, , ) КАК Продажи
ГДЕ
Продажи.Номенклатура В (&СписокТоваров)
Контроль через код-ревью
Если вы работаете в команде, лучшим способом обучения станет код-ревью. Когда старший разработчик (Team Lead) проверяет ваш код перед помещением в хранилище, он указывает на «велосипеды» — те случаи, когда вы написали свой алгоритм там, где уже есть готовая функция в БСП. Например, вместо написания своего цикла для поиска значения в массиве, используем:
ОбщегоНазначения.НайтиЗначениеВМассиве()
Заключение
Соблюдение стандартов — это не формальность для вакансии, а способ снизить технический долг проекта. Начните с малого: настройте автоматическую проверку кода и при каждом удобном случае заглядывайте в модуль ОбщегоНазначения БСП, чтобы не изобретать то, что уже написано до вас.