1с область программный интерфейс что это
В этой небольшой статье я попытаюсь продемонстрировать более удачное применение областей модуля. Как мне представляется, на самом деле, требуется не повысить читаемость кода, а структурировать его, улучшить его понимаемость, и облегчить внесение изменений.
На мой взгляд, даже названия разделов неудачны, например:
- "ПрограммныйИнтерфейс" - интересно, а какой еще как не "Программный" он может быть в данном случае,
- "СлужебныеПроцедурыИФункции" - слишком длинно, к тому же в эту область можно включить вообще любую процедуру и функцию. Критерии считать функциональную единицу "служебной" или "не служебной", как правило, размыты.
- "ОбработчикиСобытийТаблицыФормы" - уснешь, пока дочитаешь до конца, проще и компактнее просто "События".
Предложенный подход не использует в полной мере возможности областей кода. Ведь можно создавать вложенные области. Более того, вложенные области могут иметь одинаковые имена, т.е. например мы можем создать область
Вот какие разделы рекомендуется использовать.
Для модуля формы:
В разделе "Форма" собираются все обработчики событий формы.
В разделе "Элементы" собираются все обработчики событий элементов формы (кроме таблиц и табличных полей).
В разделе "Таблицы" собираются обработчики событий всех таблиц формы. При необходимости в область таблицы можно добавить вложенную область "Команды" и включить в нее все команды относящиеся к таблице.
В разделе "Оповещения" собираются все оповещения о событиях формы.
В разделе "Подключаемые" указываются все подключаемые процедуры и функции формы.
Исходный замысел был в том чтобы разделить логику модуля на клиентскую и серверную части соответственно, однако, естественно, при увеличении объема кода, принятый набор областей перестанет справляться со сложностью. В этом случае, я переразбиваю функции, добавляя область "Пакеты", и уже в ней указываю вложенные области, группируя функции. Например:
Хотя появление этой области, скорее говорит о том что функционал формы перегружен. Впрочем, для каких-то сложных обработок, это может быть применимо.
Концепция пользовательского интерфейса системы 1С:Предприятие 8 ориентирована на комфортную эффективную работу и соответствует современным тенденциям.
Основное окно
При запуске системы в режиме 1С:Предприятие открывается основное окно программы.
Функции, необходимые для удобной навигации по прикладному решению, реализованы в главной панели и в нескольких вспомогательных панелях: в панели разделов и в панели функций текущего раздела. Разработчик прикладного решения может задать некоторый стандартный состав и расположение этих панелей в соответствии с назначением и особенностями приложения.
Конструирование рабочего пространства
Пользователь может самостоятельно конструировать своё рабочее пространство, располагая панели в разных областях экрана.
Можно создать минималистичное рабочее место, оставив на экране лишь главную панель. При этом все функции навигации по прикладному решению будут доступны с её помощью.
Можно разместить на экране сразу несколько панелей, обеспечив себе разнообразные и быстрые возможности перехода к различным частям прикладного решения.
Начальная страница
Начальная страница — это стандартный раздел программы, содержащий часто используемые документы, отчеты, справочники и т. п. Это своеобразный «помощник» пользователя. Каждый рабочий день начинается с «общения» с ним. Начальная страница вводит пользователя в курс дел, отвечает на его вопросы — подробнее.
Панель разделов
Панель разделов — это наиболее крупное разделение функциональности прикладного решения. Она расположена в верхней части основного окна и соответствует верхнему уровню подсистем, добавленных в конфигурацию. С ее помощью осуществляется переход к другим разделам программы. Подробнее…
Раздел
При активизации раздела вся функциональность соответствующей подсистемы, включая вложенные подсистемы, представляется пользователю в виде команд в панели функций текущего раздела. Подробнее…
Команды
Команды — это действия, которые может выполнить пользователь. Программа может содержать разнообразные команды. Часть из них, стандартные команды, предоставляется самой платформой. Другая часть создается разработчиком прикладного решения. Подробнее…
Панель функций текущего раздела
Панель функций текущего раздела содержит самые востребованные и часто используемые команды, позволяющие просматривать информацию в списках, быстро создавать новые объекты, выполнять типовые обработки или строить популярные отчеты — подробнее.
Главная панель
Главная панель предназначена для быстрого доступа к основным функциям прикладного решения: меню функций, глобальному поиску, центру оповещений, истории, избранному, к текущему пользователю и главному меню — подробнее.
Меню функций
Меню функций предоставляет удобный доступ ко всем командам прикладного решения. Перемещаясь по разделам можно видеть на экране все команды раздела и выполнять поиск по ним. Подробнее…
Глобальный поиск
Избранное
Любой раздел, список, объект базы данных, отчет или обработку, а также команду можно добавить в избранное, чтобы потом быстро вернуться к ней, при необходимости — подробнее.
История
История содержит все действия пользователя, связанные с добавлением, изменением данных, или просто с открытием форм элементов справочников, документов и т. д. Она позволяет быстро перейти к тем объектам, которые пользователь недавно изменял или открывал — подробнее.
Центр оповещений
В центре оповещений отображаются важные оповещения, на которые пользователь еще не отреагировал — не закрыл или не выполнил связанное с оповещением действие. Оповещения располагаются в порядке их появления, самые новые сверху. О том, что есть новые важные оповещения, сигнализирует колокольчик на зеленом фоне. Таким образом, даже если пользователь отходил от компьютера, он не пропустит важные оповещения — подробнее.
Текущий пользователь
Гиперссылка с именем текущего пользователя открывает окно, в котором можно завершить работу, отменив при этом аутентификацию, если она выполнялась с помощью OpenID.
Кроме этого, если прикладное решение подключено к системе взаимодействия, в этом окне отображается аватар пользователя, телефон, адрес электронной почты и статус, которые можно изменить в этом же окне.
Главное меню
Главное меню содержит набор команд, относящихся к прикладному решению в целом и не зависящих от прикладной специфики конфигурации.
Например, команды пользовательской настройки интерфейса и команды установки параметров системы в целом — подробнее.
Вспомогательные окна
При вызове некоторых команд ввода новых и редактирования существующих объектов, а также при открытии некоторых отчетов и обработок открываются вспомогательные окна приложения.
Меню формы
Каждая форма имеет собственное меню, которое позволяет сохранять и печатать файлы, вносить правки в текстовые и табличные документы, а также управлять открытыми окнами — подробнее.
Ссылки на данные
На любой раздел, список, объект базы данных, отчет или обработку можно получить ссылку в виде строки текста. Такую ссылку можно, например, передать коллеге, чтобы тот мог быстро перейти к этим же данным и внести изменения. Подробнее…
Панель открытых
Панель открытых предназначена для частого переключения между открытыми формами. Каждой открытой форме соответствует отдельная закладка. Подробнее…
Информационная панель
В нижней части основного окна приложения может существовать информационная панель. Она предназначена для отображения показателей производительности и индикации того, что включён режим имитации задержек при вызовах сервера. Подробнее…
Поддержка корпоративного стиля
Платформа 1С:Предприятия содержит ряд инструментов, позволяющих подстроить внешний вид прикладного решения под корпоративные требования заказчика, под тот стиль, который используется в большинстве его программных продуктов — подробнее.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают. А смысла писать давно описанное нет. Для меня пп. 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С:Предприятие 8» и какие технологии используются при ее разработке.
Нативные приложения
- STL (в частности, строки, контейнеры и алгоритмы)
- множественное наследование, в т.ч. множественное наследование реализации
- шаблоны
- исключения
- умные указатели (собственная реализация)
Компоненты
- Разделение способствует лучшему проектированию, в частности лучшей изоляции кода
- Из набора компонентов можно гибко собирать разные варианты поставки:
- Например, инсталляция тонкого клиента будет содержать wbase, но не будет backend
- а на сервере wbase, наоборот, не будет
- оба варианта будут, конечно, содержать nuke и bsl
- Предоставляет фабричные методы, позволяющие создать класс из другой компоненты зная только его название (без раскрытия реализации)
- Предоставляет инфраструктуру умных указателей с подсчетом ссылок. За временем жизни SCOM-класса не нужно следить вручную
- Позволяет узнать реализует ли объект конкретный интерфейс и автоматически привести указатель на объект к указателю на интерфейс
- Создать объект-сервис, всегда доступный через метод get_service и т.д.
Этот макрос опишет специальный статический класс-регистратор, конструктор которого будет вызван при загрузке компоненты в память.
После это можно создать его экземпляр в другой компоненте:Для поддержки сервисов SCOM предлагает дополнительную, достаточно сложную инфраструктуру. Центральным в ней является понятие SCOM-процесса, который служит контейнером для запущенных сервисов (т.е. выполняет роль Service Locator), а также содержит привязку к локализуемым ресурсами. SCOM процесс привязывается к потоку ОС. Благодаря этому внутри приложения можно вот так получать сервисы:
Более, того переключая логические (SCOM) процессы привязанные к потоку, можно получить практически независимые с точки зрения информационного пространства приложения, выполняющиеся в рамках одного потока. Так устроен наш тонкий клиент, работающий с файловой базой — внутри одного процесса ОС находятся два SCOM-процесса, один связан с клиентом, а второй — с сервером. Такой подход позволяет унифицировать написания кода, который будет работать как на локальной файловой базе, так и в «настоящем» клиент-серверном варианте. Цена за такое единообразие — накладные расходы, но практика показывает, что они того стоят.
На основе компонентной модели SCOM реализована и бизнес-логика и интерфейсная часть 1С: Предприятия.
Пользовательский интерфейс
Кстати, об интерфейсах. Мы не используем стандартные контролы Windows, наши элементы управления реализованы напрямую на Windows API. Для Linux-версии сделана прослойка, работающая через библиотеку wxWidgets.
Библиотека элементов управления не зависит от других частей «1С:Предприятия» и используется нами еще в нескольких небольших внутренних утилитах.За годы развития 1С:Предприятие внешний вид контролов менялся, но серьезное изменение принципов произошло только один раз, в 2009 году, с выходом версии 8.2 и появлением «управляемых форм». Помимо изменения внешнего вида, фундаментально изменился принцип компоновки формы — произошел отказ от попиксельного позиционирования элементов в пользу flow-компоновки элементов. Кроме того, в новой модели элементы управления работают не напрямую с доменными объектами, а со специальными DTO (Data Transfer Objects).
Эти изменения позволили создать веб-клиент «1С:Предприятия», повторяющий С++ логику контролов на JavaScript. Мы стараемся поддерживать функциональную эквивалентность между тонким и веб клиентами. В том случае, когда это невозможно, например, из-за ограничений доступных из JavaScript API (например, возможности работы с файлами очень ограничены), мы часто реализуем нужную функциональность при помощи расширений браузеров, написанных на C++. На данный момент мы поддерживаем Internet Explorer и Microsoft Edge (Windows), Google Chrome(Windows), Firefox (Windows и Linux) и Safari (MacOS).Кроме того, технология управляемых форм используется для создания интерфейса мобильных приложений на платформе 1С. На мобильных устройствах отрисовка контролов реализована с использованием «родных» для операционной системы технологий, но уже для логики компоновки формы и реакции интерфейса используется тот же код, что и в «большой» платформе «1С:Предприятие».
![image]()
Интерфейс 1С на ОС Linux![image]()
Интерфейс 1С на мобильном устройстве![image]()
Интерфейс 1С на ОС Windows![image]()
Интерфейс 1С — веб-клиентOpen source
Заключение
В статье мы коснулись нескольких основных аспектов разработки платформы «1С: Предприятие». В ограниченном объеме статьи мы затронули лишь некоторые интересные, на наш взгляд, аспекты.
Общее описание различных механизмов платформы можно посмотреть тут.
Какие темы были бы интересны Вам в следующих статьях?Как реализована мобильная платформа 1С?
Описание внутреннего устройства веб-клиента?
Или, может быть, Вам интересен процесс выбора фич для новых релизов, разработки и тестирования?Читайте также:
