1с область программный интерфейс что это
Статья продолжает цикл статей «Первые шаги в разработке на 1С».
Начиная с версии 8.2 в платформе 1С, параллельно к классическому обычному многооконному интерфесу, был разработан совершенно новый интерфейс, который получил название Управляемый интерфейс. Именно он позволил организовать работу с информационной базой в веб-браузере.
В данной статье представлено знакомство с управляемым интерфейсом со стороны пользователя.
Применимость
В этой статье рассматривается Управляемый интерфейс конфигурации, разработанной на платформе 1C 8.3.4.482. Следует отметить, что сегодня Управляемый интерфейс, разработанный на платформе «1С:Предприятие» редакции 8.2, считается устаревшим и рекомендуется использовать его следующую версию, которая получила название «Такси». Но старый вариант управляемого интерфейса никуда не делся, и чтобы в дальнейшем не возникло путаницы с терминологией, платформа редакции 8.3 стала классифицировать интерфейсы по вариантам: вариант «Версия 8.2» (старый) и вариант «Такси» (новый).
Интерфейс «Такси» является более удобным и эргономичным, он гораздо проще в освоении начинающим пользователям. С точки зрения разработки прикладных решений управляемый интерфейс «Версии 8.2» и «Такси» практически не отличаются друг от друга. Главное отличие наблюдается в пользовательском режиме, но и оно не столь кардинально, как может показаться на первый взгляд. Поэтому рекомендуем ознакомиться с этой информацией.
Управляемый интерфейс
Для начала опишем, как в общем виде выглядит конфигурация с использованием управляемого интерфейса:
- доступ к главному меню и ряд служебных сервисных команд выведены в Верхнюю командную панель и располагаются там же, где выводится заголовок приложения;
- чуть ниже располагается Панель разделов, которая имеет различные варианты отображения (картинки, надписи или картинки и надписи). Каждому разделу в конфигурации соответствует свой объект Подсистема и, кроме того, обязательным элементом в панели разделов является Рабочий стол;
- слева в каждом разделе может располагаться Панель навигации с ссылками для открытия определенных окон (в том числе форм списков различных документов и справочников). Команды панели навигации можно сортировать по группам;
- под Панелью разделов располагается Панель действий, которая содержит команды по созданию объектов (элементов справочников, документов), а также запуску отчетов, обработок, открытию каких-то служебных окон (например, для записи констант);
- в основной части приложения, которая называется Рабочей областью, отображается окно текущего выбранного элемента. Вызываемое окно занимает всю эту область. При смене окон они замещают друг друга. Открытие отдельных независимых окон (которые можно двигать как угодно) возможно при удержании клавиши Shift. Такие окна открываются как еще один элемент панели задач операционной системы.
Создание новых элементов справочников и документов рекомендуется без использования списков (из Панели действий).
Это связано с тем, что при работе на тонких каналах связи для открытия списка потребуется какое-то дополнительное время.
Для оптимизации передаваемых данных любое редактирование объекта (элемента справочника) также осуществляется в отдельном диалоговом окне.
При создании новых объектов появляется соответствующее оповещение (Область оповещения – в правом нижнем углу экрана).
Внизу имеется Панель истории, в которой отображаются последние созданные элементы. При необходимости, с помощью мышки можно вернуться к какому-либо из этих элементов и внести изменения.
Главное меню в командном интерфейсе не горизонтальное, а вертикальное. Оно вызывается по нажатию специальной кнопки слева в Верхней панели. В том числе есть меню Все функции.
Меню Все функции отображается, если установлена специальная галочка Отображать команду все функции в окне Параметры.
В этом же окне можно изменить вид интерфейса, выбрав внешний вид Формы в закладках или Формы в отдельных окнах.
Окно Параметры вызывается из главного меню. Для этого следует последовательно выбрать пункт Сервис, а потом Параметры.
В меню Все функции можно выбрать любой объект, к которому у пользователя есть право просмотра, а также есть доступ к набору стандартных функций.
Хотя перечень объектов, которые можно отобразить на рабочем столе, определяется в конфигураторе, существуют некоторые возможности по индивидуализации Рабочего стола в пользовательском режиме:
- во-первых, отображаемые на Рабочем столе формы зависят от наличия к ним прав доступа;
- во-вторых, есть некоторые возможности по настройке Рабочего стола.
Переключитесь на Рабочий стол и в контекстном меню панели разделов выберите пункт Настройка рабочего стола.
Появится окно настройки Рабочего стола. Доступные формы, определенные в конфигураторе, можно распределить по колонкам (всего две колонки), можно часть форм не отображать.
Настройки Рабочего стола хранятся индивидуально для каждого пользователя.
Аналогичные возможности по настройке есть для Панели разделов, Панели навигации и Панели действий. Требуемые окна для настройки вызываются с помощью выбора соответствующего пункта контекстного меню. Вызов самого контекстного меню осуществляется в любой из перечисленных панелей.
В окне настройки Панели разделов можно изменять порядок следования разделов, включать и отключать видимость этих разделов (кнопками добавления и удаления) и управлять режимом отображения (Картинка, Текст или Картинка и текст).
В окне настройки Панели навигации пользователь может перемещать элементы между группами и внутри групп, удалять и добавлять элементы на Панели навигации. Все сделанные настройки также запоминаются для текущего пользователя.
Настройка Панели действий производится аналогично. Следует еще раз отметить, что пользователь может отобразить на той или иной панели только те элементы конфигурации, к которым у него есть доступ.
Ранее мы уже говорили о существовании Области оповещения (при создании новых объектов) и Панели истории (размеры которой ограниченны).
Кроме того, историю действий с объектами можно посмотреть в специальном окне, которое вызывается нажатием одноименной кнопки слева внизу.
История сохраняется также между сеансами, но количество хранимых записей не более 200. Новые записи вытесняют старые.
Еще одна интересная интерфейсная возможность – навигация по действиям, которые выполнялись в рабочей области. Существуют специальные кнопки, которые позволяют перемещаться вперед и назад по принципу браузера.
Данная навигация работает не только в рамках одного раздела. Справа расположена кнопка, с помощью которой можно вернуться к разным действиям, которые выполнялись ранее.
Данная навигация работает только по формам, которые открывались в рабочей области.
Кроме того, имеется возможность передавать ссылки на определенные элементы. Пользователь, принявший ссылку (например, по почте) может ее открыть.
Если это была ссылка на документ, то пользователь может, например, внести в него какие-то изменения. В форме элемента (например, документа) существует специальная кнопка.
При нажатии на эту кнопку появляется ссылка.
Другой пользователь, получивший ссылку, нажимает на кнопку Перейти по ссылке.
В появившемся окне “Переход по ссылке” вставляет полученную ссылку и нажимает кнопку Перейти. После чего открывается нужный документ.
Существует еще такой сервис, как Область избранного, в которой могут располагаться любые формы и любые ссылки.
Например, можно настроить шаблонные документы и обеспечить быстрый доступ к ним. Чтобы добавить, например, документ в Избранное нужно в командной панели формы документа нажать на соответствующую кнопку.
Откроется меню, в котором нужно выбрать пункт Добавить в избранное.
Удалить элемент из Области избранного можно удалив его из окна “Настройка избранного”.
Как открыть данное окно показано на рисунке.
Ну что ж, теперь, когда мы познакомились с Управляемом интерфейсом глазами пользователя, есть смысл вернуться в Конфигуратор и взглянуть на его настройку глазами программиста. В следующей статье именно этим и займемся.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
Комментарии / обсуждение (5):
А как отключить контекстное меню по настройке панелей навигации, разделов и прочее ?
Концепция пользовательского интерфейса системы 1С:Предприятие 8 ориентирована на комфортную эффективную работу и соответствует современным тенденциям.
Основное окно
При запуске системы в режиме 1С:Предприятие открывается основное окно программы.
Функции, необходимые для удобной навигации по прикладному решению, реализованы в главной панели и в нескольких вспомогательных панелях: в панели разделов и в панели функций текущего раздела. Разработчик прикладного решения может задать некоторый стандартный состав и расположение этих панелей в соответствии с назначением и особенностями приложения.
Конструирование рабочего пространства
Пользователь может самостоятельно конструировать своё рабочее пространство, располагая панели в разных областях экрана.
Можно создать минималистичное рабочее место, оставив на экране лишь главную панель. При этом все функции навигации по прикладному решению будут доступны с её помощью.
Можно разместить на экране сразу несколько панелей, обеспечив себе разнообразные и быстрые возможности перехода к различным частям прикладного решения.
Начальная страница
Начальная страница — это стандартный раздел программы, содержащий часто используемые документы, отчеты, справочники и т. п. Это своеобразный «помощник» пользователя. Каждый рабочий день начинается с «общения» с ним. Начальная страница вводит пользователя в курс дел, отвечает на его вопросы — подробнее.
Панель разделов
Панель разделов — это наиболее крупное разделение функциональности прикладного решения. Она расположена в верхней части основного окна и соответствует верхнему уровню подсистем, добавленных в конфигурацию. С ее помощью осуществляется переход к другим разделам программы. Подробнее…
Раздел
При активизации раздела вся функциональность соответствующей подсистемы, включая вложенные подсистемы, представляется пользователю в виде команд в панели функций текущего раздела. Подробнее…
Команды
Команды — это действия, которые может выполнить пользователь. Программа может содержать разнообразные команды. Часть из них, стандартные команды, предоставляется самой платформой. Другая часть создается разработчиком прикладного решения. Подробнее…
Панель функций текущего раздела
Панель функций текущего раздела содержит самые востребованные и часто используемые команды, позволяющие просматривать информацию в списках, быстро создавать новые объекты, выполнять типовые обработки или строить популярные отчеты — подробнее.
Главная панель
Главная панель предназначена для быстрого доступа к основным функциям прикладного решения: меню функций, глобальному поиску, центру оповещений, истории, избранному, к текущему пользователю и главному меню — подробнее.
Меню функций
Меню функций предоставляет удобный доступ ко всем командам прикладного решения. Перемещаясь по разделам можно видеть на экране все команды раздела и выполнять поиск по ним. Подробнее…
Глобальный поиск
Избранное
Любой раздел, список, объект базы данных, отчет или обработку, а также команду можно добавить в избранное, чтобы потом быстро вернуться к ней, при необходимости — подробнее.
История
История содержит все действия пользователя, связанные с добавлением, изменением данных, или просто с открытием форм элементов справочников, документов и т. д. Она позволяет быстро перейти к тем объектам, которые пользователь недавно изменял или открывал — подробнее.
Центр оповещений
В центре оповещений отображаются важные оповещения, на которые пользователь еще не отреагировал — не закрыл или не выполнил связанное с оповещением действие. Оповещения располагаются в порядке их появления, самые новые сверху. О том, что есть новые важные оповещения, сигнализирует колокольчик на зеленом фоне. Таким образом, даже если пользователь отходил от компьютера, он не пропустит важные оповещения — подробнее.
Текущий пользователь
Гиперссылка с именем текущего пользователя открывает окно, в котором можно завершить работу, отменив при этом аутентификацию, если она выполнялась с помощью OpenID.
Кроме этого, если прикладное решение подключено к системе взаимодействия, в этом окне отображается аватар пользователя, телефон, адрес электронной почты и статус, которые можно изменить в этом же окне.
Главное меню
Главное меню содержит набор команд, относящихся к прикладному решению в целом и не зависящих от прикладной специфики конфигурации.
Например, команды пользовательской настройки интерфейса и команды установки параметров системы в целом — подробнее.
Вспомогательные окна
При вызове некоторых команд ввода новых и редактирования существующих объектов, а также при открытии некоторых отчетов и обработок открываются вспомогательные окна приложения.
Меню формы
Каждая форма имеет собственное меню, которое позволяет сохранять и печатать файлы, вносить правки в текстовые и табличные документы, а также управлять открытыми окнами — подробнее.
Ссылки на данные
На любой раздел, список, объект базы данных, отчет или обработку можно получить ссылку в виде строки текста. Такую ссылку можно, например, передать коллеге, чтобы тот мог быстро перейти к этим же данным и внести изменения. Подробнее…
Панель открытых
Панель открытых предназначена для частого переключения между открытыми формами. Каждой открытой форме соответствует отдельная закладка. Подробнее…
Информационная панель
В нижней части основного окна приложения может существовать информационная панель. Она предназначена для отображения показателей производительности и индикации того, что включён режим имитации задержек при вызовах сервера. Подробнее…
Поддержка корпоративного стиля
Платформа 1С:Предприятия содержит ряд инструментов, позволяющих подстроить внешний вид прикладного решения под корпоративные требования заказчика, под тот стиль, который используется в большинстве его программных продуктов — подробнее.
Во всех вакансиях есть требование - умение читать чужой код. Но ни на одних курсах специально этому не учат. Чтобы устранить это противоречие, пишу данную статью. Рассмотрю случаи, в которых нам необходимо разбирать чужой код, поймём, чей код мы пытаемся разобрать, зачем и, главное, как. В статье описан личный опыт длиною в 18 лет начиная с версии платформы 7.7. Статья будет большой, набираемся терпения). Статья содержит в себе описание сценариев разбора кода, т.е. набор шагов. В статье не получится показать это на практике. Для этого планирую сделать онлайн или оффлайн курс, где на примерах будет показан разбор незнакомого кода. Статья разбита на 4 публикации для удобства изучения.
Сразу напишу вопросы, которые в статье не будут рассматриваться:
1. Разбор и отладка правил конвертации
2. Отладка фоновых заданий.
3. Отладка асинхронных вызовов.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают. А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.
Кейс 6. Как разобратьcя и использовать программный интерфейс.
Наверняка часто встречаются разработчики, которые считают, что написать самому запрос к какому-то регистру гораздо проще, чем разбираться в существующих модулях типовых конфигураций. На первый взгляд - ДА! НО! Любой программный интерфейс генерирует с десяток, а иногда и больше временных таблиц. Часто оказывается, что данные одной из временных таблиц ну просто специально для меня написали, чётко под мою задачу! Конечно, не все это знают, не все знают, что вообще есть какой-то программный интерфейс, как его искать и т.д. Вот и разберёмся со следующими вопросами:
1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?
2. Что такое БСП (кратко)?
3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?
4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?
5. Он же изменится. Зачем его использовать, если 1С перепишет его?
Раскроем каждый пункт подробно:
1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?
На самом деле элементарно! Давайте рассмотрим на примере ЗУПа. В ЗУП есть часто используемые разделы:
-- Учет страховых взносов
Остановимся на таком списке. Конечно, разделов гораздо больше. На что надо обратить внимание: На то, что каждый раздел имеет свои Общие модули, и они называются так же, как и раздел учета. Т.е. в любой конфигурации названия общих модулей сделаны очень понятными и соответствуют разделам учета/решаемым задачам.
Здесь необходимо напомнить о стандартах разработки! Согласно стандартов по оформлению общих модулей, секция "Программный интерфейс" должна всегда располагаться вверху общего модуля. Далее следует секция "Служебный программный интерфейс".
Берем штатное расписание. Заходим в основной серверный модуль "УправлениеШтатнымРасписанием". Видим процедуры:
если посмотреть в служебный программный интерфейс, можем найти там довольно полезную функцию:
полезные процедуры можно найти даже в секции "Служебные процедуры и функции". Например, в этом модуле много функций, для построения запросов по штатному расписанию:
или процедуры, которые позволяют получать какие-то данные по позициям штатного расписания:
Если таким образом проанализировать каждый раздел учета, можно обнаружить невероятное количество полезных процедур и функций. Расчет ФОТ - это довольно сложная задача в ЗУП. Написать самому это не получится от слова НИКАК! Она даже запускает "страшный и ужасный" менеджер расчета зарплаты. А здесь всего лишь надо на вход дать правильные данные и система рассчитает ФОТ позиций штатного расписания сама!
Окунувшись в стандарты разработки чуть глубже, станет понятно, что программный интерфейс есть не только в общих модулях. Эта область в коде может присутствовать в модуле менеджера или модуле объекта абсолютно любого объекта метаданных.
Опять же на примере ЗУП обратимся к модулю объекта обработки "Менеджер данных учета времени сотрудников". Здесь есть вот такие полезные процедуры:
Если посмотреть модуль менеджера документа "Больничный лист", можно найти функцию:
На этом перестану переписывать названия процедур и функций в текст статьи. Главное понять принцип, что общие модули, модули объекта и менеджера могут содержать программный интерфейс, который Вам требуется.
Настоятельно рекомендую изучать программный интерфейс того раздела учета, в котором Вам предстоит вести разработку по Вашей задаче. Наверняка много полезного найдёте для себя.
БСП - Библиотека стандартных подсистем. Описывать её функционал, конечно, не стану. Функционал в каком-то виде описан и на сайте ИТС, и на данном ресурсе.
Что важно отметить в этом пункте: Если Вам нужно что-то сделать с таблицей, массивом, файлом, хранилищем значений или ещё с каким-то универсальным механизмом, которым "оборудованы" все конфигурации. ОБЯЗАТЕЛЬНО смотрите в описание БСП. Наверняка Ваша задача уже решена. Осталось с ней разобраться ниже описанными способами, и использовать программный интерфейс в своём коде.
С точки зрения качества кода при использовании как программного интерфейса как типового (имею в виду учетные задачи), так и БСП, Вы шагнёте на новую высоту (это больше, чем на ступень вверх!). На собеседованиях Вам наверняка зададут вопрос о том, знаете ли Вы, что такое БСП, используете программный интерфейс в своём коде или нет?
По себе могу сказать, что половину своих задач решаю именно с помощью программного интерфейса! Лучше я потрачу время на изучение этой темы, чем буду писать никому ненужный код с так себе качеством.
3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?
Опишу способы которыми пользуюсь сам:
-- Первое, что я делаю - читаю описание процедуры/функции, которое, согласно стандартам разработки, является обязательным для экспортных процедур/функций программного интерфейса модулей. Обычно в нём сухо, коротко описано назначение и тип значения/назначение входящих параметров. Часто уже это описание на 30% даёт понимание, как использовать этот программный интерфейс.
-- Программный интерфейс БСП описан на сайте ИТС и в большом количестве статей. Нужно не полениться воспользоваться поиском и почитать статьи.
-- Следующий шаг - посмотреть, как вызывается программный интерфейс в типовой конфигурации. Бывало, сталкивался с неиспользуемым программным интерфейсом. Таким пользоваться сразу не рекомендую, т.к. наверняка его забыли стереть и скоро это обязательно сделают. На этапе анализа примеров вызова программного интерфейса необходимо обратить внимание на заполнение параметров программного интерфейса.
-- Главное, что помогает мне и обязательно поможет Вам, - отладчик! Найдя место вызова нужного Вам программного интерфейса, нужно изучить, что у него на входе и на выходе. Для этого необходимо:
а. Поставить точку останова в месте вызова программного интерфейса в типовом коде. Конечно, необходимо найти хотя бы одно место, откуда он вызывается. Т.е. какое пользовательское действие приводит к запуску программного интерфейса. Зачастую таких мест много и найти их нетрудно, часто даже можно догадаться.
б. Скопировать весь текст вызова программного интерфейса в свой код, и постепенно адаптировать свой код под параметры интерфейса, чтобы он сработал без ошибок. Данный путь, во-первых, сложней, во-вторых, Вам его всё равно придётся пройти, т.к. адаптация своего кода под программный интерфейс неизбежна, если Вы его хотите использовать. Поэтому обязательно идём по этому пути.
-- В отладчике Вам необходимо посмотреть параметры на вход, тип значения, чем заполнены. Часто необходимо, чтобы в Менеджере временных таблиц уже была временная таблица с определёнными колонками, которая станет "фильтром" для получаемых данных. Отладчик позволяет увидеть, какие данные в этой временной таблице.
ВАЖНО: Опять же напишу - не пытайтесь фантазировать, как выглядит заполненная таблица. Надо найти такой вызов программного интерфейса, чтоб в нём было как можно больше данных и на входе, и на выходе. Иногда полезно несколько мест посмотреть отладчиком.
-- Последним действием необходимо изучить все временные таблицы, которые создал программный интерфейс, и посмотреть на результат его работы. В моей практике нередко бывает, что использую не результирующую таблицу, а несколько промежуточных! Поэтому и надо посмотреть их все. Вдруг наилучшим образом под Вашу задачу подойдёт промежуточная таблица!?
-- После того, как программный интерфейс сработал, не забывайте удалять из менеджера временных таблиц ненужные данные. Особенно если какие-то временные таблицы огромных размеров, т.е. >= 100 тыс. записей.
4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?
Для ответа на этот вопрос нужно обратиться к стандарту разработки под названием "Структура модуля". В нём указано вот какое описание:
а. Раздел "Программный интерфейс" содержит экспортные процедуры/функции, которые можно вызывать из любых объектов метаданных, в т.ч. через внешнее соединение. Т.е. не важно какую задачу решаете, если есть потребность в использовании процедур/функций этого раздела смело пользуйтесь!
б. Раздел "Служебный программный интерфейс" содержит экспортные процедуры/функции, которые являются частью какой-то подсистемы. Их использование, согласно стандарту, допускается только внутри подсистемы, в которую входит общий модуль или объект конфигурации. Т.е. если мы смотрим служебный программный интерфейс штатного расписания, то эти процедуры не следует использовать в расчете налогов или зарплаты) Да и вряд ли они туда подойдут!
в. Раздел "Служебные процедуры и функции" содержит процедуры/функции, которые используются для реализации программного интерфейса (в т.ч. служебного) данного модуля. Не рекомендуется их использование за рамками модуля, а тем более за рамками подсистемы. Но "не рекомендуется" не означает, что в модуле не могут быть экспортные процедуры/функции. Их необходимо также использовать в рамках подсистемы, в которую входит общий модуль.
Как видно, знание стандартов разработки помогает лучше понимать подходы и принципы, которыми руководствуются разработчики типовых конфигураций и тиражных решений.
5. Он же изменится. Зачем его использовать, если 1С перепишет его?
Помните, мы раньше ТиС 7.7 дорабатывали? А как ЗУП 2.5 или УПП 1.3 в хлам переписывали? Никто ведь не думал в тот момент, что 1С придумает УТ11, ЗУП3, ЕРП2? Всё меняется со временем, поэтому не стоит рассчитывать, что программный интерфейс 1С никогда не поменяет! Но вопрос тут, конечно, не в психологии, а в том, что делать, если программный интерфейс перестал работать!?
Необходимо попробовать следующие действия:
-- Чаще всего меняется состав, назначение или тип значения у переменных, передаваемых в программный интерфейс. Как это понять? Найти место, где этот программный интерфейс используется в типовой конфигурации, и изучить обновлённый состав параметров.
-- Необходимо зайти в модуль, в котором располагается программный интерфейс, и изучить описание самого интерфейса и параметров. Также рекомендую остановиться в общем модуле отладчиком и посмотреть, как теперь он работает, какие данные в нём.
-- Иногда меняются временные таблицы, которые создает программный интерфейс, или убираются/добавляются колонки в основной таблице. Опять же увидеть можно все эти изменения в отладчике. По сути надо повторить путь разбора программного интерфейса, описанный выше.
-- Бывает, что процедура/функция переносится в другой общий модуль. Здесь поможет поиск по всем текстам той, которая перестала работать. Меняем название модуля - опять всё работает.
Делаем вывод: Волка бояться - в лес не ходить! Каждая проблема имеет своё решение. Главное не паниковать, а подумать над этим решением. Варианты постарался описать.
Наверняка многие сталкивались с ситуацией, когда есть сложная задача, её поручили кому-то. А он взял и не справился! И самое приятное в этом - поиск нового исполнителя, того кто справится.
Так вот, если Вы тот самый бедолага, кому прилетела такая задача - этот кейс для Вас!
Сразу напишу, что самое главное, что Вы должны выяснить, - сценарии работы по прилетевшей Вам задаче. Т.е. Вам необходимо найти хотя бы один из источников информации:
1. Техническое задание
2. Список сценариев работы. В грамотных командах этот список составляется ДО начала разработки. Сценарий работы пользователя - это основа для проектирования любого процесса.
3. Консультанта, который выяснял детали и писал какую-то документацию по этой доработке.
4. Можно дать задание консультанту набить тестовых примеров в базу, где Вы планируете вести доработку. По себе знаю, что для программиста вводить тестовые примеры - каторга! Для консультанта - ничего необычного, это его работа. Поэтому для ускорения процесса нужно получить тестовые примеры.
5. Пообщаться с архитектором (если такая опция есть в проекте). Необходимо выяснить максимум того, что не так в выполненной кем-то работе и каковы ожидания.
6. Всё, что удалось выяснить, необходимо ОБЯЗАТЕЛЬНО ЗАПИСАТЬ! Не надо надеяться на свою память. Она Вас точно подведёт!
Как только выяснили постановку, сценарии, ошибки и как должно быть. Срочно начинаем доработку. Какие действия Вам помогут ускориться:
1. Попробуйте выяснить у архитектора правильный путь решения задачи. Как бы он сам делал? Может, даже подскажут, в какие модули надо залезть, и пояснят подход к решению задачи.
3. Если в процессе кодирования столкнулись с непониманием кода. Уже в этой статье много способов в нём разобраться описано. Не стесняйтесь просить более опытных коллег пояснить кусок кода, который непонятен. Не нужно полдня тратить на разбор 10 строк кода.
Итак, коллеги, те, кто дочитал до этого места, начав с первой части, Вы, как и я, проделали огромную работу. Да, это всё теория. Практика всегда менее радужная и занимает время. Прочитав мою статью, Вы не сможете за 5 минут прочесть чужой код. НО! Уверен, мои подходы позволят Вам сократить время на изучение чужого кода. Если кто-то вдруг не обладает такой компетенцией, то статья - хороший старт. Надеюсь, что даже профи с многолетним опытом работы найдут в этой статье для себя что-то новое.
Остальные части доступны по ссылкам:
Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!
Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:
Описывается структура областей модулей, которую я использую при разработке на своих проектах. Обсуждаются недостатки стандарта 1С "Структура модуля". Предложен улучшенный подход к работе со структурой модуля.
В этой небольшой статье я попытаюсь продемонстрировать более удачное применение областей модуля. Как мне представляется, на самом деле, требуется не повысить читаемость кода, а структурировать его, улучшить его понимаемость, и облегчить внесение изменений.
На мой взгляд, даже названия разделов неудачны, например:
- "ПрограммныйИнтерфейс" - интересно, а какой еще как не "Программный" он может быть в данном случае,
- "СлужебныеПроцедурыИФункции" - слишком длинно, к тому же в эту область можно включить вообще любую процедуру и функцию. Критерии считать функциональную единицу "служебной" или "не служебной", как правило, размыты.
- "ОбработчикиСобытийТаблицыФормы" - уснешь, пока дочитаешь до конца, проще и компактнее просто "События".
Предложенный подход не использует в полной мере возможности областей кода. Ведь можно создавать вложенные области. Более того, вложенные области могут иметь одинаковые имена, т.е. например мы можем создать область
Вот какие разделы рекомендуется использовать.
Для модуля формы:
В разделе "Форма" собираются все обработчики событий формы.
В разделе "Элементы" собираются все обработчики событий элементов формы (кроме таблиц и табличных полей).
В разделе "Таблицы" собираются обработчики событий всех таблиц формы. При необходимости в область таблицы можно добавить вложенную область "Команды" и включить в нее все команды относящиеся к таблице.
В разделе "Оповещения" собираются все оповещения о событиях формы.
В разделе "Подключаемые" указываются все подключаемые процедуры и функции формы.
Исходный замысел был в том чтобы разделить логику модуля на клиентскую и серверную части соответственно, однако, естественно, при увеличении объема кода, принятый набор областей перестанет справляться со сложностью. В этом случае, я переразбиваю функции, добавляя область "Пакеты", и уже в ней указываю вложенные области, группируя функции. Например:
Хотя появление этой области, скорее говорит о том что функционал формы перегружен. Впрочем, для каких-то сложных обработок, это может быть применимо.
Для модуля объекта:
Для общего модуля (и для модуля менеджера):
Специальные предложения
Если вы укоротили имена областей, это еще не значит, что повысили читаемость кода.
Вот смотрите, например, область " ОбработчикиСобытийФормы ". Любому разработчику понятно, ЧТО в этой области должно храниться. Вы же предлагаете назвать эту область расплывчато " Форма ". Да это название короче, но поставьте себя на место разработчика, который не знаком с вашим стандартом. Сможет ли он без ваших объяснений догадаться, что писать в эту область? Вы уверены, что он впишет туда только обработчики событий формы? То же самое и с другими областями ( Элементы , Таблицы , Интерфейс и т.д.).
По поводу дополнительных областей, которых нет в стандарте, тоже не согласен. Все дополнительные области следует помещать в " СлужебныеПроцедурыИФункции ". Именно поэтому у нее такое общее и расплывчатое название. Внутри нее можно поместить области " Подключаемые ", " Оповещения " и др.
Вообще, гораздо проще освоить общий стандарт, чем придумывать свой. Ведь если придешь в новую команду и начнешь всем объяснять, что вы пишете неправильно, а я правильно, то встретишь непонимание и недоумение со стороны коллег.
Лично я давно уже привык к стандартным областям, и могу с уверенностью заявить, что в них лаконично укладывается 99.9% всех решаемых задач, и был бы сильно против, если бы мне кто-нибудь начал навязывать подобные улучшения.
ShiningPhoenix; shalimski; kaliuzhnyi; Agapov_Stas; AnderWonder; RailMen; TreeDogNight; NeviD; Vladimir Litvinenko; hydro2588_2015; unichkin; alest; Solovyeff; sorb; Бубузяка; kuzyara; dour-dead; JohnyDeath; CSiER; klinval; binex; TODD22; DenisCh; корум; kolya_tlt; h00k; charushkin; Makushimo; + 28 – Ответить
:-) исходя из каких предпосылок вы пришли к умозаключению что я собираюсь
:-)? Пусть это останется загадкой.
Даже в самой 1С точность "стандарта" соблюдается, скажем так, "с доработками". Достаточно посмотреть на исходные коды конфигураций УП, УНФ и Документооборот. Разные команды даже внутри самой 1С изменяют его под себя.
(2) открыл Документооборот 2.0.14.4. Увидел там, что стандартные области соблюдаются. Просмотрел несколько форм, модулей менеджеров, модулей объектов. В чем именно вы заметили несоблюдение? Приведите конкретный пример.
Других конфигураций под рукой нет.
Про вложенные области я не упомянул, т.к. они не регламентированы. Во вложенных областях каждый может писать, что считает правильным.
Скажу вам по своему опыту, что очень трудно приучить разработчиков соблюдать даже типовой стандарт. А уж тем более предлагать кому-нибудь свой стандарт - дело совсем неблагодарное. Но желаю вам удачи в этом начинании)
Функция ПолучитьПолноеИмяПользователя()
Функция СоздатьПараметрыЗаполненияЦенПоставщика()
Функция ОпределитьДатуНачалаСеанса()
Функция ПолноеИмяПользователя()
Функция НовыеПараметрыЗаполненияЦенПоставщика()
Функция ДатаНачалаСеанса()
Не в обиду, но данная статья - велосипед, с квадратными колесами. Желаю автору не тратить время на эти изыскания, а изучать стандарты вендора. Чтобы ваять что-то значимое на 1С - необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми. Чем больше 1С-негов это осознает, тем проще всем нам будет жить.
слова "Форма" и "Элементы" - это служебные слова, их нельзя использовать в качестве именований переменных.
Но имена областей кода не являются переменными.
:-) там тоже есть ошибки и недочеты, как и в любом творении рук человеческих.
Данная статья, это изложение моего "оценочного суждения" основанного на опыте. Эту информацию я опубликовал для того чтобы поделиться с сообществом, на мой взгляд, полезной идеей. Возможно, кому-то она понравится и кто-то из коллег воспользуется ей.
:-) "Что позволено Юпитеру, то не позволено быку". Я делаю второе, но никогда не буду делать первого :-)
Чтобы ваять что-то значимое на 1С - необходим обязательный упор на групповую разработку, а там важны конвенции, которые жестко соблюдаются всеми
С этим не поспоришь. Но, увы, практика показывает что императив "жестко соблюдаются всеми" является таки мечтой. В реальности обычно "более или менее соблюдаются всеми".
А кто такие 1С-неги?
Все эти попытки группировок модулей с помощью областей - от Лукавого. Как и автор статьи, одно время пытался навести порядок в своих алгоритмах с помощью областей. Придумывал имена, менял порядок следования, ломал голову куда-что перебросить с риском развалить всю хатку. И что? Я стал быстрее программировать? Нахожу быстрее требуемые процедуры-функции? Быстрее переключаюсь? Логика понятней? Не знаю как у вас, Господа, но мне эти группировки никак жизнь не облегчают. Всегда пляшу от формы. И все наши с вами попытки навести красоту и сделать нашу программистскую жизнь легче, - потеря времени, пока сама фирма 1С не обратит свои взоры в эту сторону. Как по мне, боковая навигационная панель к программному модулю, в которой перечислялись бы применительно к текущему модулю все вызывающие и вызываемые модули была бы куда интересней. На ней же события-команды не помешали бы. Ну, может быть, еще чего, - можно пофантазировать. Мне не нужна структура всея конфигурации. мне нужна подсказка по структуре здесь и сейчас, в текущем модуле. А автору за попытку улучшения стиля таки спасибо. Думал. мечтал. фантазировал. решал. предлагал. Ну что с того, что пошел против общего течения? Зато дал повод и нам помечтать. :)
(5)Раззадорился я малость.. :) Ну сами подумайте! С какой стати мы сами должны группировать? Что, при создании нового события не ясно, что это событие и нужно его включить в область событий в модуле формы для конкретного реквизита формы? Нееет, бросим это событие в конец модуля формы, - так думает фирма 1С. Полагает, что нам доставляет удовольствие после создания нового события, выщемить его, найти в модуле формы область событий для реквизита формы и туда его перекинуть, - чтобы красиво было и всем все понятно! :)
Я не в претензии к фирме 1С. Я снимаю перед разработчиками 1С-Предприятие шляпу за труд, который еще никому не удавался. Но. некоторые моменты вызывают улыбку. То же создание стандарта, указанное автором статьи. Не читал, но по контексту уже догадался о чем. Вместо того, чтобы при создании новых событий реквизитов формы бросать их в соответствующие области модуля (ведь понятно какие, можно создать на автомате), опубликуем стандарт! Пусть программисты 1С отдохнут на легком труде. :)
(6) Ну по поводу удобства использования Конфигуратора было написано уже довольно много. Скажем так, в этом плане Конфигуратору есть куда расти. Лично я очень большие надежды возлагаю на новую среду разработки на базе Eclipse.
Вот как минимум процитированное должно соблюдаться, при правильном использовании областей. Так-как точно не надо "шерстить" весь модуль для поиска нужной функции, достаточно развернуть нужную область.
С быстрым переключением та же история - развернул область, нашёл нужную функцию.
С логикой чуть сложнее, больше зависит от образа мышления того разработчика чей код смотришь.
И ещё, стоит учесть, что имена областей в стандарте полностью соответствуют устоявшимся именам областей модулей. Просто раньше приходилось их выделять при помощи комментариев, а сейчас появился более удобный инструмент.
(7) "На безрыбье - и рак рыба!" И есть очевидная польза от областей многим из нас. Равно, как некоторым из нас это лишь дополнительная головная боль при наведении порядка, который в массе можно было бы поддерживать автоматически. Да, области нужны для выделения крупномасштабной структуры. А в плане поиска требуемого. еще ни разу они не ускорили мне работу. Замедлили - да! - в попытке вспомнить что и в какой области. в каком месте находится. Играл я как-то с "свернуть-развернуть" область пытаясь найти что-то, - удовольствия не получил. :) Наверное, от привычек многое зависит, отработанных подходов. Каждый выбирает, что ему удобней.
Можно. И разработчики платформы ведут работы в этом направление. Но, у них есть масса более важных и приоритетных задач, ради ускоренной реализации которых лично я готов мирится с "неинтеллектуальной" вставкой процедур обработчиков в модули.
П.С.: Было уже схожее обсуждение на партнёрском форуме. Лично я тогда голосовал за "отложить" на потом работы по "юзабилити конфигуратора". И сейчас моё мнение не изменилось.
(5) Ну, как говорится, "доброе слово и кошке приятно" :-) Области кода используются во многих средах разработки, та же VS Microsoft например. Лично я нахожу их очень удобными и полезными, но тут, конечно, это вопрос личных предпочтений.
Я не иду против течения, скорее я пытаюсь сделать движение по течению более комфортным и эффективным. :-)
Страсти отшумели, я поздно увидел публикацию. Мне приятно видеть, что автор
1) озабочен качеством кода,
2) при этом не следует слепо чужим правилам. Хочешь сделать жизнь краше-делай!
По моему опыту, и как видно из обсуждения, мотивация некоторых программистов на вопрос "а зачем украшать код (т.е. страдать ерундой)" строится на постулатах:
* "быстрее я писать не стану. А мне и так удобно". " Всегда пляшу от формы" - как написано выше. (5) Короче, жалко времени.
* "Я же это для себя писал". Второй вариант: под индивидуального заказчика, третий вариант: для нормального решения, но для меня это была разовая работа. Вот так происходит трансформация мышления. А в жизни так: если ты в лесу поворот не показываешь, то и везде так-же ездишь.
Только собственник конечного продукта понимает ценность красивого и понятного кода. Это и надежность, и реальные трудозатраты в сопровождении, которые могут превышать первоначальный труд на создание.
А что касается отношения к строгости стандартов, то должна быть некоторая незашоренность. Нравятся тебе более короткие названия - реши и пиши так.
По поводу областей спорят: нужны - не нужны. Обалденно нужны! Но правило должно не быть: "а этот блок обязательно в область". У меня так: размер модуля до 2-3 экранов - можно не разбивать по областям. Больше - обязательно.
Автору - плюс.
(21)Здесь немного упомянули мое имя всуе. :) Хочу дать некоторое дополнительное уточнение (назову так) к свои комментариям. Я, вообще-то, не против областей как это может показаться, и стандартов по их использованию. Напротив, я зА использование областей. И если бы участвовал в разработке типовых решений, непременно следовал бы им для поддержания единообразия в программировании и еще потому, что иначе решение не было бы принято как типовое. Но. я против дурной работы в тех случаях, когда я являюсь единственным постановщиком и исполнителем всех работ, связанных с программированием. В условиях, когда платформа в нынешнем состоянии никак не поддерживает программистов в эффективном использовании этих самых областей. А в большинстве своем эти области могут поддерживаться платформой на автомате (что скорее всего будет реализовано в будущем). А что получается? Я навел порядок в программном коде, разложил все по областям, а потом (спустя длительное время, когда все уже давно забыто) добавил еще пару-тройку событий и. "наша песня хороша - начинай сначала" с наведения порядка, тупого перетаскивания событий по областям. Мы что, обезьяны, чтобы тупо перекладывать все с места на место? Ничего более умного нельзя реализовать? Понятное дело, разработчикам пока что не до таких мелочей. А нам остается ждать. И тогда уж, мы будем поддерживать области собственными усилиями только там, где платформа в принципе не способна разделить процедуры-функции по областям, ибо все "правила" в голове программиста.
(21) Спасибо, Игорь. Divide et impera - разделяй и властвуй. Но как разделить правильно? Как разделить лучше? Статья - размышление на тему как точнее разделять код на ясные блоки, с помощью имеющегося в наличии инструмента - областей кода. Мнения коллег разнятся, конечно, все люди разные. :-)
Поставил плюс, так как затронута важная тема.
В целом со статьей не согласен - нужно следовать стандартам уже имеющимся.
(10) Безусловно, профессиональный подход к командной разработке любого сложного продукта требует чтобы все участники следовали уже имеющимся стандартам. Но разве это утверждение запрещает рассматривать предложения по улучшению действующего стандарта?
"практика показывает что императив "жестко соблюдаются всеми" является таки мечтой" - как-раз из-за того что все хотят "хорошо", но каждый по-своему. Я тоже сперва велся на подчеркивание в областях, пробовал как-то под себя это все подогнать. А потом подумал что в 1С наверное не дураки сидят, не просто так это все. И начал оформляться так, как это сказано на ИТС. Сейчас не представляю зачем изобретать что-то иное - видимо привык. Имхо - разработка стандартов не то, чем надо заниматься на работе. Хотя бы потому что все уже придумано, и это реально удобно)) Только к этому надо придти.
Ваше высказывание, кстати, нарушает 6-ой стандарт 1С :-)
"Ваше высказывание, кстати, нарушает 6-ой стандарт 1С :-) "
- Мы теперь всю прессу стандартом считать будем?) Или только прессу от 1С? Это еще одна ваша идея?
з.ы. Ничего не имею против "изучать чужой опыт, но думать своей головой". Только я не вижу смысла воровать колизей)) Есть правила, вполне удобная база которой надо следовать. А не заниматься фигней, вводя в заблуждение неопытную публику. За публикацию - минус.
Программные модули в "1С:Предприятии 8"
Программный модуль представляет собой текст на встроенном языке "1С:Предприятия 8", расположенный в определенном месте конфигурации.
В соответствии с этим различают следующие виды программных модулей:
На следующем рисунке показано расположение всех этих модулей:
Разделы программного модуля
Любой программный модуль, за исключением общих модулей, состоит из следующих разделов:
- раздел объявления переменных,
- раздел процедур и функций,
- раздел основной программы.
Внимание! У общих модулей есть только раздел процедур и функций.
Контекст
Контекст — очень важное понятие при программировании на любом языке. В "1С:Предприятии 8" контекст обозначает окружение модуля, т. е. какие ему будут доступны переменные, объекты, свойства, методы и события.
Можно выделить следующие виды контекстов, существующих в "1С:Предприятии 8":
Глобальный контекст , доступный во всех остальных контекстах, состоит из следующих частей:
- свойства, методы и события глобального контекста (например, свойство РабочаяДата ),
- системные перечисления и системные наборы значений (например, КодВозвратаДиалога и Символы ).
В контексте модуля приложения (или модуля внешнего соединения) доступны экспортируемые процедуры и функции общих модулей.
В контексте общего модуля доступны экспортируемые процедуры и функции других общих модулей. В этом контексте недоступны экспортируемые переменные, процедуры и функции модуля приложения.
В контексте модуля прикладного объекта есть доступ к реквизитам и табличным частям объекта, а также его методам и событиям. Например, в модуле документа РасходнаяНакладная доступны реквизиты документа и его табличные части, можно вызывать методы документа и обрабатывать события.
В контексте модуля формы доступны реквизиты формы, а также ее свойства, методы и события. Если у формы назначен основной реквизит, то в модуле формы становятся доступны свойства и методы прикладного объекта, используемого в качестве основного реквизита, а также экспортируемые переменные, процедуры и функции модуля этого прикладного объекта.
Необходимо помнить правила видимости экспортируемых переменных, процедур и функций различных модулей:
- В общем модуле недоступны экспортируемые переменные, процедуры и функции модуля приложения (модуля внешнего соединения).
- В модуле приложения (модуле внешнего соединения) доступны экспортируемые процедуры и функции общих модулей.
- В общих модулях доступны экспортируемые процедуры и функции других общих модулей.
- В модулях прикладных объектов и модулях форм доступны экспортируемые переменные, процедуры и функции модуля приложения (модуля внешнего соединения), а также экспортируемые процедуры и функции общих модулей.
- Если у формы назначен основной реквизит, то контекст модуля формы содержит дополнительные свойства и методы, связанные с основным реквизитом. Например, в модуле формы элемента справочника Номенклатура доступны свойства и методы объекта СправочникОбъект.Номенклатура .
Проиллюстрируем применение первых четырех правил на следующей схеме:
Стрелки на схеме обозначают, что модуль предоставляет другим модулям возможность обращаться к своим экспортируемым переменным, процедурам и функциям. Напомним, что в общих модулях не может быть объявления переменных.
Читайте также: