Основная часть работы компаний-партнеров 1С заключается в постоянной доработке существующих версий программ клиентов. Главная задача здесь – оптимизировать повседневную работу с данными в соответствии с потребностями заказчика с учетом выходящих обновлений платформы и изменений в законодательстве. В программировании такая работа выполняется путем обновления конфигураций и модификаций пользователя. В большинстве случаев эти действия осуществляются по примерно одинаковым сценариям. Так постепенно выработались стандарты разработки 1С. По сути, это база знаний, которая позволяет оптимизировать работу программистов.
Большинство решений в рекомендациях по разработке 1С не подразумевают простоту и быстроту реализации. При этом следование этим инструкциям дает возможность выполнить работу грамотно и не возвращаться к ней позже. В итоге это экономит время программистов и заказчиков. Ниже собраны основные стандарты и методики разработки 1С, которые позволяют изменять и добавлять новые функции так, чтобы это не мешало дальнейшей работе.
Правило сохранения типовой конфигурации
Нередко конфигурации приходится обновлять в связи с частым выходом релизов. Согласно промышленным стандартам разработки 1С, программистам нужно каждый раз принимать меры, чтобы обновление в будущем не было затруднено из-за решения текущих задач. Соблюдение этого принципа может быть более трудоемким и занимать больше времени. Также нужно принимать во внимание степень понятности кода и уровень эффективности программы после внесенных изменений.
Комментарии при редактировании кода
Любые изменения кода в модулях должны сопровождаться комментариями. Такие уточнения имеют специальный формат. Пример показан ниже.
Обозначения:
//++ — начало комментария
//-- — конец комментария
VION — имя программиста
0001234 — номер задачи в трекере. Ставим только в открывающемся комментарии.
Доработка на старте – текст комментария. Применяется, если номер задачи есть. Если его нет, текст пишем обязательно.
Комментарии по стандартам 1С-разработки используют для выделения модификаций. Если код изменен повторно через некоторое время, текст не пишем. Но когда модификация редактируется уже другим разработчиком в другой задаче, комментировать обязательно.
Создание объектов верхнего уровня
При добавлении объектов верхнего уровня в их имени по промышленным стандартам разработки 1С предписывается указывать префиксы. Это могут быть Ваши инициалы или сокращенное название компании с нижним подчеркиванием. Например, AV_. То есть документы будут называться примерно так: AV_НовыйРегистрСведений, AV_НовыйСправочник и т. д. В синонимах таких названий префиксы заключаются в круглые скобки (AV). Такое решение, согласно стандартам и методикам разработки 1С, позволяет автоматически группировать объекты верхнего уровня в списке. Это облегчает поиск и работу с ними.
После создания объектов верхнего уровня нужно привязать их к действующей задаче. Это поможет быстро находить их через глобальный поиск. В ходе 1С-разработки по промышленным стандартам для привязки нужно создать комментарий, где указать имя программиста, дату создания задачи и ее номер.
Создание подчиненных объектов
В этом случае 1С-разработка по промышленным стандартам подразумевает разные варианты решений. Все зависит от объекта конфигурации, куда добавляем новый реквизит. Здесь все объекты разделяются на типовые (которые ни разу до этого не изменялись) и созданные в текущем проекте (которые имеют префикс).
Создание подчиненных элементов в типовых конфигурациях
Если объект конфигурации типовой, создаваемый подчиненный элемент нужно снабдить префиксом. При этом синонимы, по стандартам разработки 1С, прописываются без префиксов. В комментарии необходимо указать имя программиста, дату создания задачи и ее номер, чтобы была возможность найти ее при помощи глобального поиска.
Создание подчиненных элементов в конфигурациях, добавленных в текущем проекте
Подчиненные элементы, которые создаются в конфигурациях, разработанных в ходе проекта, добавляются без префикса. В синонимах их названий он также не нужен. Как и в предыдущем случае, в комментариях нужно указать имя программиста, дату и номер задачи. Если реквизит добавляется в ходе той же задачи, что и объект верхнего уровня, его создание по стандартам 1С-разработки можно не комментировать. В глобальном поиске задача все равно будет отображаться.
Создание предопределенных элементов
При добавлении предопределенных объектов нужно следовать рекомендациям 1С по разработке и применять те же правила, что и в случаях с подчиненными объектами. Если нужно изменить имя предопределенного элемента типового объекта, делать это следует через раздел обработки инициализации.
Структура общих модулей
В большинстве случаев для создания часто используемых элементов конфигураций нужно создавать отдельные модули, оставляя типовые неизменными. Это касается обработчиков подписок, функций, процедур, регламентных заданий и т. д. Для добавления нового модуля рекомендации 1С по разработке предписывают следовать правилам создания объектов верхнего уровня. При этом пригодятся следующие модули:
- АБ_ОбщегоНазначения (сервер, клиент, внешнее соединение) — в нем размещаются обычные функции и процедуры.
- АБ_Привилегированный — используется для процедур и функций, которые исполняются только под полными правами.
- АБ_ПовторноеИспользование — подходит для кэширования возвратных значений определенных функций.
- АБ_Серверный (только для сервера) — используется для процедур и функций, которые работают в серверной среде.
- АБ_Глобальный — применяется для функций и процедур, которые неудобно искать через имя и точку.
Некоторые модули можно использовать для переноса больших блоков кода. В других случаях действия программиста регулируются стандартами 1С-разработки. Он должен поискать другой подходящий модуль для переноса и отладки кода, прежде чем создавать новый.
Структура подписок
Когда нужно обрабатывать события, которые связаны с типовыми объектами конфигурации, не стоит создавать новые модули, если можно обойтись без этого. Для подобных случаев система стандартов и методик разработки 1С предусматривает использование подписок. Для каждого события будет достаточно одной. Для размещения кода используется общий модуль. Это помогает наладить параллельную работу программистов с информационным хранилищем. Имена общего модуля и подписки должны соответствовать событию, к которому они привязаны, и быть одинаковыми. По промышленным стандартам разработки 1С, источником подписки нужно указать все объекты, подходящие для обработки. Если в модуле изменяется код, редактирование нужно комментировать по общим правилам.
Работа с ролями
При любой возможности типовые роли не нужно редактировать. Восстановить их потом бывает сложно. Если в конфигурации создаются новые объекты, по системе стандартов и методик разработки 1С, права на них нужно прописывать в новых ролях. Для этой цели элементы создаются специально. В случае возможности нужно программно реализовывать запреты на доступ к информации. Только если этого нельзя сделать без потери качества, в 1С-разработке по промышленным стандартам можно редактировать типовые роли. При этом все изменения нужно задокументировать. Они должны быть минимально возможными. В случае редактирования весь блок типового кода обрамляют комментариями.
Опасности несоблюдения стандартов разработки 1С
Если не брать в расчет наработанные рекомендации специалистов, это приведет к большому количеству ошибок в работе платформы и нагрузке на службу поддержки. Далее решение проблем отнимет много времени на работу программистов. В итоге заказчик понесет убытки из-за простоев и ошибок в уже сформированных документах. Эффективность компании-партнера 1С также снижается из-за непрофессионализма ее сотрудников. Там, где в отчетный период она могла бы обслужить, например, трех заказчиков, специалисты тратят время на решение проблем одного клиента. Поэтому работа по системе стандартов и методик разработки 1С выгодна всем участникам.
Однако некоторые подрядчики часто предпочитают более быстрые и простые решения в обновлении конфигураций. В дальнейшем это оборачивается большими проблемами. Поэтому заказчикам лучше обращаться к профессионалам, которые соблюдают промышленные стандарты разработки 1С и несут ответственность за свою работу. Чтобы и дальше эффективно работать с внутренними данными, спросите у представителей подрядчика документ, подтверждающий, что компания является аккредитованным партнером платформы. Задайте вопросы о соблюдении стандартов и методик разработки 1С. Доверяйте только профессионалам и не экономьте на обслуживании ПО.
Комментарии ()
Написать комментарий