Сразу напишу вопросы, которые в статье не будут рассматриваться:
1. Разбор и отладка правил конвертации
2. Отладка фоновых заданий.
3. Отладка асинхронных вызовов.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают... А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.
Кейс 6. Как разобратьcя и использовать программный интерфейс.
Наверняка часто встречаются разработчики, которые считают, что написать самому запрос к какому-то регистру гораздо проще, чем разбираться в существующих модулях типовых конфигураций... На первый взгляд - ДА! НО! Любой программный интерфейс генерирует с десяток, а иногда и больше временных таблиц. Часто оказывается, что данные одной из временных таблиц ну просто специально для меня написали, чётко под мою задачу! Конечно, не все это знают, не все знают, что вообще есть какой-то программный интерфейс, как его искать и т.д. Вот и разберёмся со следующими вопросами:
1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?
2. Что такое БСП (кратко)?
3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?
4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?
5. Он же изменится... Зачем его использовать, если 1С перепишет его?
Раскроем каждый пункт подробно:
1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?
На самом деле элементарно! Давайте рассмотрим на примере ЗУПа. В ЗУП есть часто используемые разделы:
-- Штатное расписание
-- Кадровый учет
-- Остатки отпусков
-- Расчет зарплаты
-- Учет НДФЛ
-- Учет страховых взносов
Остановимся на таком списке. Конечно, разделов гораздо больше. На что надо обратить внимание: На то, что каждый раздел имеет свои Общие модули, и они называются так же, как и раздел учета. Т.е. в любой конфигурации названия общих модулей сделаны очень понятными и соответствуют разделам учета/решаемым задачам.
Здесь необходимо напомнить о стандартах разработки! Согласно стандартов по оформлению общих модулей, секция "Программный интерфейс" должна всегда располагаться вверху общего модуля. Далее следует секция "Служебный программный интерфейс".
Берем штатное расписание. Заходим в основной серверный модуль "УправлениеШтатнымРасписанием". Видим процедуры:
-- СформироватьДвиженияИсторииПозицийШтатногоРасписания
-- СформироватьДвиженияСпециальностейПоШтатномуРасписанию
-- СформироватьДвиженияКлассовУсловийТрудаПоШтатномуРасписанию
если посмотреть в служебный программный интерфейс, можем найти там довольно полезную функцию:
-- ЗанятостьПозицийШтатногоРасписания.
полезные процедуры можно найти даже в секции "Служебные процедуры и функции". Например, в этом модуле много функций, для построения запросов по штатному расписанию:
-- СоздатьВТНачисленияШтатногоРасписания
-- СоздатьВТЕжегодныеОтпускаПозицийШтатногоРасписания
-- СоздатьВТПозицииШтатногоРасписанияПоВременнойТаблице
или процедуры, которые позволяют получать какие-то данные по позициям штатного расписания:
-- ДанныеПозицийШтатногоРасписания
-- РассчитатьФОТНесколькихПозиций
Если таким образом проанализировать каждый раздел учета, можно обнаружить невероятное количество полезных процедур и функций. Расчет ФОТ - это довольно сложная задача в ЗУП. Написать самому это не получится от слова НИКАК! Она даже запускает "страшный и ужасный" менеджер расчета зарплаты. А здесь всего лишь надо на вход дать правильные данные и система рассчитает ФОТ позиций штатного расписания сама!
Окунувшись в стандарты разработки чуть глубже, станет понятно, что программный интерфейс есть не только в общих модулях. Эта область в коде может присутствовать в модуле менеджера или модуле объекта абсолютно любого объекта метаданных.
Опять же на примере ЗУП обратимся к модулю объекта обработки "Менеджер данных учета времени сотрудников". Здесь есть вот такие полезные процедуры:
-- СоздатьВТИнтервалыДействияИсточниковДанныхУчетаВремени
-- СоздатьВТСуммированныйУчетПоСотрудникам
-- СоздатьВТЗарегистрированныеНаборыВидовВремени
-- СоздатьВТНормаВремениСотрудников
-- СоздатьВТДанныеПроизводственногоКалендаряПоСотрудникам
Если посмотреть модуль менеджера документа "Больничный лист", можно найти функцию:
-- МаксимальноеКоличествоОплачиваемыхДнейПоПричинеНетрудоспособности.
На этом перестану переписывать названия процедур и функций в текст статьи... Главное понять принцип, что общие модули, модули объекта и менеджера могут содержать программный интерфейс, который Вам требуется.
Настоятельно рекомендую изучать программный интерфейс того раздела учета, в котором Вам предстоит вести разработку по Вашей задаче. Наверняка много полезного найдёте для себя.
2. Что такое БСП (кратко)?
БСП - Библиотека стандартных подсистем. Описывать её функционал, конечно, не стану. Функционал в каком-то виде описан и на сайте ИТС, и на данном ресурсе.
Что важно отметить в этом пункте: Если Вам нужно что-то сделать с таблицей, массивом, файлом, хранилищем значений или ещё с каким-то универсальным механизмом, которым "оборудованы" все конфигурации... ОБЯЗАТЕЛЬНО смотрите в описание БСП. Наверняка Ваша задача уже решена. Осталось с ней разобраться ниже описанными способами, и использовать программный интерфейс в своём коде.
С точки зрения качества кода при использовании как программного интерфейса как типового (имею в виду учетные задачи), так и БСП, Вы шагнёте на новую высоту (это больше, чем на ступень вверх!). На собеседованиях Вам наверняка зададут вопрос о том, знаете ли Вы, что такое БСП, используете программный интерфейс в своём коде или нет?
По себе могу сказать, что половину своих задач решаю именно с помощью программного интерфейса! Лучше я потрачу время на изучение этой темы, чем буду писать никому ненужный код с так себе качеством.
3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?
Опишу способы которыми пользуюсь сам:
-- Первое, что я делаю - читаю описание процедуры/функции, которое, согласно стандартам разработки, является обязательным для экспортных процедур/функций программного интерфейса модулей. Обычно в нём сухо, коротко описано назначение и тип значения/назначение входящих параметров. Часто уже это описание на 30% даёт понимание, как использовать этот программный интерфейс.
-- Программный интерфейс БСП описан на сайте ИТС и в большом количестве статей. Нужно не полениться воспользоваться поиском и почитать статьи.
-- Следующий шаг - посмотреть, как вызывается программный интерфейс в типовой конфигурации. Бывало, сталкивался с неиспользуемым программным интерфейсом. Таким пользоваться сразу не рекомендую, т.к. наверняка его забыли стереть и скоро это обязательно сделают. На этапе анализа примеров вызова программного интерфейса необходимо обратить внимание на заполнение параметров программного интерфейса.
-- Главное, что помогает мне и обязательно поможет Вам, - отладчик! Найдя место вызова нужного Вам программного интерфейса, нужно изучить, что у него на входе и на выходе. Для этого необходимо:
а. Поставить точку останова в месте вызова программного интерфейса в типовом коде. Конечно, необходимо найти хотя бы одно место, откуда он вызывается. Т.е. какое пользовательское действие приводит к запуску программного интерфейса. Зачастую таких мест много и найти их нетрудно, часто даже можно догадаться.
б. Скопировать весь текст вызова программного интерфейса в свой код, и постепенно адаптировать свой код под параметры интерфейса, чтобы он сработал без ошибок. Данный путь, во-первых, сложней, во-вторых, Вам его всё равно придётся пройти, т.к. адаптация своего кода под программный интерфейс неизбежна, если Вы его хотите использовать. Поэтому обязательно идём по этому пути.
-- В отладчике Вам необходимо посмотреть параметры на вход, тип значения, чем заполнены. Часто необходимо, чтобы в Менеджере временных таблиц уже была временная таблица с определёнными колонками, которая станет "фильтром" для получаемых данных. Отладчик позволяет увидеть, какие данные в этой временной таблице.
ВАЖНО: Опять же напишу - не пытайтесь фантазировать, как выглядит заполненная таблица. Надо найти такой вызов программного интерфейса, чтоб в нём было как можно больше данных и на входе, и на выходе. Иногда полезно несколько мест посмотреть отладчиком.
-- Последним действием необходимо изучить все временные таблицы, которые создал программный интерфейс, и посмотреть на результат его работы. В моей практике нередко бывает, что использую не результирующую таблицу, а несколько промежуточных! Поэтому и надо посмотреть их все. Вдруг наилучшим образом под Вашу задачу подойдёт промежуточная таблица!?
-- После того, как программный интерфейс сработал, не забывайте удалять из менеджера временных таблиц ненужные данные. Особенно если какие-то временные таблицы огромных размеров, т.е. >= 100 тыс. записей.
4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?
Для ответа на этот вопрос нужно обратиться к стандарту разработки под названием "Структура модуля". В нём указано вот какое описание:
а. Раздел "Программный интерфейс" содержит экспортные процедуры/функции, которые можно вызывать из любых объектов метаданных, в т.ч. через внешнее соединение. Т.е. не важно какую задачу решаете, если есть потребность в использовании процедур/функций этого раздела смело пользуйтесь!
б. Раздел "Служебный программный интерфейс" содержит экспортные процедуры/функции, которые являются частью какой-то подсистемы. Их использование, согласно стандарту, допускается только внутри подсистемы, в которую входит общий модуль или объект конфигурации. Т.е. если мы смотрим служебный программный интерфейс штатного расписания, то эти процедуры не следует использовать в расчете налогов или зарплаты) Да и вряд ли они туда подойдут!
в. Раздел "Служебные процедуры и функции" содержит процедуры/функции, которые используются для реализации программного интерфейса (в т.ч. служебного) данного модуля. Не рекомендуется их использование за рамками модуля, а тем более за рамками подсистемы. Но "не рекомендуется" не означает, что в модуле не могут быть экспортные процедуры/функции. Их необходимо также использовать в рамках подсистемы, в которую входит общий модуль.
Как видно, знание стандартов разработки помогает лучше понимать подходы и принципы, которыми руководствуются разработчики типовых конфигураций и тиражных решений.
5. Он же изменится... Зачем его использовать, если 1С перепишет его?
Помните, мы раньше ТиС 7.7 дорабатывали? А как ЗУП 2.5 или УПП 1.3 в хлам переписывали? Никто ведь не думал в тот момент, что 1С придумает УТ11, ЗУП3, ЕРП2? Всё меняется со временем, поэтому не стоит рассчитывать, что программный интерфейс 1С никогда не поменяет! Но вопрос тут, конечно, не в психологии, а в том, что делать, если программный интерфейс перестал работать!?
Необходимо попробовать следующие действия:
-- Чаще всего меняется состав, назначение или тип значения у переменных, передаваемых в программный интерфейс. Как это понять? Найти место, где этот программный интерфейс используется в типовой конфигурации, и изучить обновлённый состав параметров.
-- Необходимо зайти в модуль, в котором располагается программный интерфейс, и изучить описание самого интерфейса и параметров. Также рекомендую остановиться в общем модуле отладчиком и посмотреть, как теперь он работает, какие данные в нём.
-- Иногда меняются временные таблицы, которые создает программный интерфейс, или убираются/добавляются колонки в основной таблице. Опять же увидеть можно все эти изменения в отладчике. По сути надо повторить путь разбора программного интерфейса, описанный выше.
-- Бывает, что процедура/функция переносится в другой общий модуль. Здесь поможет поиск по всем текстам той, которая перестала работать. Меняем название модуля - опять всё работает.
Делаем вывод: Волка бояться - в лес не ходить! Каждая проблема имеет своё решение. Главное не паниковать, а подумать над этим решением. Варианты постарался описать.
Кейс 7. Помочь коллеге, переделать (исправить) быстро чужую работу.
Наверняка многие сталкивались с ситуацией, когда есть сложная задача, её поручили кому-то... А он взял и не справился! И самое приятное в этом - поиск нового исполнителя, того кто справится.
Вторая ситуация, которая в рамках этого кейса рассматривается - это когда разработчик вроде сделал, но сделал нереально криво с огромным количеством ошибок. В такой ситуации возвращать на доработку нет смысла, т.к. рабочий день убьёшь на описание ошибок. Бывает, что проще исправить самому или отдать человеку, который со слов поймёт, что надо переделать, и выдаст качественный результат.
Так вот, если Вы тот самый бедолага, кому прилетела такая задача - этот кейс для Вас!
Сразу напишу, что самое главное, что Вы должны выяснить, - сценарии работы по прилетевшей Вам задаче. Т.е. Вам необходимо найти хотя бы один из источников информации:
1. Техническое задание
2. Список сценариев работы. В грамотных командах этот список составляется ДО начала разработки. Сценарий работы пользователя - это основа для проектирования любого процесса.
3. Консультанта, который выяснял детали и писал какую-то документацию по этой доработке.
4. Можно дать задание консультанту набить тестовых примеров в базу, где Вы планируете вести доработку. По себе знаю, что для программиста вводить тестовые примеры - каторга! Для консультанта - ничего необычного, это его работа. Поэтому для ускорения процесса нужно получить тестовые примеры.
5. Пообщаться с архитектором (если такая опция есть в проекте). Необходимо выяснить максимум того, что не так в выполненной кем-то работе и каковы ожидания.
6. Всё, что удалось выяснить, необходимо ОБЯЗАТЕЛЬНО ЗАПИСАТЬ! Не надо надеяться на свою память. Она Вас точно подведёт!
Как только выяснили постановку, сценарии, ошибки и как должно быть... Срочно начинаем доработку. Какие действия Вам помогут ускориться:
1. Попробуйте выяснить у архитектора правильный путь решения задачи. Как бы он сам делал? Может, даже подскажут, в какие модули надо залезть, и пояснят подход к решению задачи.
2. Если реализация уже есть хоть какая-то... Попробуйте совместно с консультантом/аналитиком протестировать доработку. Иногда достаточно поправить несколько мелких ошибок, и ситуация спасена!
3. Если в процессе кодирования столкнулись с непониманием кода... Уже в этой статье много способов в нём разобраться описано. Не стесняйтесь просить более опытных коллег пояснить кусок кода, который непонятен. Не нужно полдня тратить на разбор 10 строк кода.
Итак, коллеги, те, кто дочитал до этого места, начав с первой части, Вы, как и я, проделали огромную работу. Да, это всё теория. Практика всегда менее радужная и занимает время. Прочитав мою статью, Вы не сможете за 5 минут прочесть чужой код. НО! Уверен, мои подходы позволят Вам сократить время на изучение чужого кода. Если кто-то вдруг не обладает такой компетенцией, то статья - хороший старт. Надеюсь, что даже профи с многолетним опытом работы найдут в этой статье для себя что-то новое.
Остальные части доступны по ссылкам:
Часть 1. Общие вопросы. Доработка чужого кода. Code review.
Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации.
Часть 3. Разбор и доработка запросов
Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!
Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:
1. Кто такой архитектор. Редакция 2!
2. Пример работы с файлами odt в клиент-серверной модели работы
