Главная цель всего цикла статей - устранение парадокса: во всех вакансиях есть требование "уметь читать чужой код", но нигде этому не учат.
Раздел 1. Общие вопросы. Доработка чужого кода. Code review.
Прежде чем читать чужой код, необходимо понять, зачем мы это делаем и какой результат хотим получить в итоге.
Чтение кода - это сложная задача! И без понимания того, какой результат мы хотим видеть - не обойтись.
Чужой код необходимо читать в следующих ситуациях:
1. Необходимо выполнить небольшую или, наоборот, большую доработку в уже существующем (не типовом) объекте метаданных или во внешней обработке/отчете.
В результате:
Доработка выполнена таким образом, чтобы не сломать уже существующие сценарии, соответствует общепринятым стандартам разработки.
Если дорабатывается тиражное решение - стилистика кода соответствует общепринятой.
2. Выполняем код ревью.
В результате:
Проверили путь решения задачи, указали коллегам на явные и не очень ошибки, рассказали, какой код можно оптимизировать либо заменить на программный интерфейс.
Проверили синтаксис написанного кода, указали на опечатки и лишние сокращения.
3. Дорабатываем типовую конфигурацию.
В результате:
Разобрались, как работает типовой код. Определили объекты метаданных, из которых он вызывается.
Определили сценарии работы кода. Выполнили свои доработки, не нарушив логической целостности кода.
4. Выполняем обновление доработанной конфигурации.
В результате:
Обновили доработанную конфигурацию, перенесли весь дописанный код.
Где-то код заменили на типовой. Где-то пришлось заново доработать.
5. Разбор и изменение запросов.
В результате:
Разобрались с запросом. Внесли в него свои доработки. По возможности оптимизировали запрос. Ничего не сломали.
6. Разбор программного интерфейса и его использование в своей доработке.
В результате:
Разобрались с программным интерфейсом, изучили временные таблицы, включили его в свою доработку.
7. Необходимо помочь коллеге, или необходимо за кого-то переделать работу в невероятно короткие сроки.
В результате:
Помогли коллеге, ответили на вопросы, проверили его способ реализации, подсказали правильный путь.
Либо всё это сделали без использования коллеги. Исправили все ошибки, либо с нуля выполнили доработку.
Рассмотрим вводную информацию, применимую ко всем кейсам:
1. Будут попадаться незнакомые процедуры или функции встроенного языка. Их изучают в 2 простых шага:
-- Синтаксис помощник содержит информацию о её предназначении.
-- Поиск по всем текстам в типовой конфигурации покажет множество примеров по использованию.
Эти примеры можно копировать в свой код.
2. Программирование в 1С построено на том, что любая переменная или реквизит имеет определённый тип значения.
Набор свойств и методов, доступных для переменной, можно найти в синтаксис помощнике в разделе с описанием типа значения.
Тип значения конкретной переменной в коде можно посмотреть отладчиком.
Узнав тип значения какой-то переменной, Вам может стать понятней код, который написан применительно к ней.
3. Не использовать отладчик для прохождения ВСЕГО кода. Искать место разбора кода через поиск по всем текстам.
4. Если требуется разобраться с объектом метаданных, с которым Вы никогда не сталкивались, описанные выше методы не подойдут.
Необходимо поискать статьи, которые описывают теорию об этом объекте и практическое применение объекта.
Например, Вы не знаете, как работают Web-сервисы. Найдите статью об этом, скорей всего, статья даже окажется на Инфостарте.
Часто авторы статей совмещают теорию с практикой и показывают примеры кода.
Если пример можно скачать за 1$m, не жалейте этих денег. Самостоятельно дольше будете писать!
И нет, это не скрытая реклама данного ресурса. Это мой опыт, который позволил со многими трудными механизмами разобраться.
5. Непонятные вопросы необходимо задавать на форумах.
Даже если Вас обольют 10 человек грязью, всегда найдётся один, который поможет!
6. Любой объект метаданных - это набор сценариев, который заложил в него разработчик.
Прежде, чем пытаться доработать тот или иной кусок кода, необходимо выявить сценарии, которые уже заложены.
7. Сценарий - это основа для любой разработки.
Приучите себя к правилу: Нельзя начинать разработку, пока Вы четко не знаете существующие сценарии и как должен выглядеть сценарий после Ваших изменений. Писать его нужно ДО кодирования, а не после!
8. Не использовать при разработке "тестовые примеры".
Тестовые данные никогда не показывают полную картину. Максимум тестовый пример охватывает 20-30% сценариев, которые необходимо учесть. Задайте себе вопрос: "Кто будет дорабатывать/тестировать остальные"?
Рассмотрим основные приемы доработки чужого (не типового) кода.
Рассмотрим самую страшную ситуацию - доработать нужно написанное с нуля решение/обработку/отчет, либо "партнёрские решения".
1. Первое, что необходимо понять, есть ли описание этого решения, либо человек, который может рассказать, как оно работает.
Не требуется знать всю архитектуру, но обязательно нужно понять, как работает дорабатываемый кусок кода.
2. Если нет ни описания, ни носителя знаний - запускаем в пользовательском режиме и пробуем использовать доработку.
а. С отчетом всё просто - пробуем разные настройки, смотрим, какие данные выводит, используем разные варианты отчета.
б. С обработкой сложней:
-- Сначала изучаем - какие объекты модифицирует обработка. Делаем поиск метода Записать(). Всё станет очевидно.
-- Далее отвечаем на вопрос: откуда берется список объектов, который обрабатывается. Скорей всего есть запрос...
-- Часто создают промежуточную табличную часть с обрабатываемыми объектами. Пробуем определить, что это за список на данном этапе.
-- При отсутствии табличной части список обрабатываемых объектов смотрим в коде отладчиком.
Обязательно нужно изучить массив обрабатываемых данных!
ВАЖНО: Прежде чем отладчиком смотреть такие обработки, необходимо закомментировать все Записать(), найденные на первом шаге. Это убережет Ваши данные от ненужных изменений.
-- Разбираемся с заполнением параметров, выведенных на форму. Смотрим, где в запросах они используются?
Некоторые параметры могут быть не используемыми! Определяем на данном этапе и убираем их с формы обработки!
-- Проходим отладчиком несколько циклов по обработке данных. Так совсем понятно станет, что происходит.
в. Чужие доработки без описания - самый сложный случай.
Финальная цель - разобраться со сценариями работы и модифицировать их. Для этого:
-- Делим код на 2 части: интерфейсный (управление элементами формы) и объектный
(обработка заполнения, проверки, запись объекта, формирования движений документов, печать).
-- Для интерфейсного через поиск по всем текстам (или по одному модулю) ищем код, управляющий поведением элемента формы.
В поиске имя элемента формы. НО! Помним, что прятать элементы управляемых форм можно благодаря ещё 2-м механизмам: функциональные опции и права.
-- Для объектного определяем, какую часть кода дорабатываем (обработка заполнения, проверки, записи объекта, формирования движений, печать).
-- Смотрим на уже заполненные данные. Неважно, какой это объект метаданных.
Изучаем, чем заполнены реквизиты, особенно, если их тип - Перечисление. Ведь этот тип создан для описания сценариев.
По коду можно определить все сценарии, в которых задействовано перечисление.
-- Для разбора алгоритма заполнения изучаем, куда заполненные данные идут?
Если это документ, то изучаем движения. Если источник регистр сведений - изучаем, где он используется.
-- Изучаем найденные сценарии в пользовательском режиме.
-- Непонятные куски кода смотрим в отладчике.
4. Ищем объектный код в правильных местах:
-- Печать, заполнение - модуль менеджера. Часть процедур могут быть вынесены в общие модули.
-- Проверка заполнения, запись, проведение - модуль объекта.
-- У регистров используется модуль набора записей. В нём расположен код формирования записей вспомогательных регистров сведений.
-- Не стоит искать (как и писать) код заполнения объекта в форме объекта.
Итак, мы изучили сценарии работы и массив данных - можно приступать к доработке.
ВАЖНО: В остальных кейсах необходимо пройти те же шаги. По ним опишу только отличия.
Рассмотрим основные аспекты проведения code review.
Цель код ревью - проверка правильности пути решения задачи и соблюдения стандартов разработки 1С.
На эту тему написано много статей, поэтому кратко опишу, что проверяю сам:
1. Раздел "Соглашения при написании кода". Раздел показывает грамотность разработчика.
Выполнение разработчиком этой группы стандартов так же важно, как и грамотная устная и письменная речь.
Несоблюдение этих стандартов затрудняет чтение и понимание кода! Можно автоматизировать проверки через Sonar Qube.
2. Группа стандартов "Создание и изменение объектов метаданных".
Цель - обеспечение единого подхода при создании объектов метаданных.
3. Группа стандартов "Вопросы клиент-серверного взаимодействия".
Цель - снижение нагрузки на клиентскую часть приложения, оптимизация вызовов сервера.
4. Группа стандартов "Разработка пользовательских интерфейсов" и "Проектирование интерфейсов 8.3".
Главное - удобное расположение элементов формы, таблиц, команд, итогов.
5. Группа стандартов "Обработка данных" (запросы, выборки, транзакции, блокировки). Здесь укажу основные проблемы:
-- Неверное использование индексов.
-- Не используются виртуальные таблицы с параметрами, запросы делают к физическим таблицам.
-- Вложенные запросы к довольно большим таблицам.
-- При обработке данных используется Запрос.Выполнить().Выгрузить() и дальше обрабатывается таблица. Зачем? Есть же выборка!
-- Запросы в циклах. Особенно часто они неявные! Возникают при вызове программного интерфейса в цикле.
-- Избыточное использование транзакций
-- Избыточное использование блокировок при выполнении запросов к регистрам накопления.
Блокировка нужна только при ОДНОВРЕМЕННОМ обращении нескольких пользователей К ОДНИМ И ТЕМ ЖЕ ДАННЫМ, а не к одному и тому же регистру!
6. Без привязки к стандартам проверяю выбранный способ решения задачи.
-- Рекомендую проводить промежуточный этап проверки Design review.
Этот этап проводится когда разработчик выполнил примерно треть своей работы.
Цель этого этапа на старте разработки понять: выбран правильный путь решения и задача поставлена верно.
Основные проблемы на этом этапе:
-- Отработаны не все сценарии. Из нескольких веток условия доработка есть только в одной ветке. А кто остальные будет делать?
-- Копирование типовых объектов целиком и изменение в скопированном объекте!
Программный интерфейс этого объекта перестанет работать после обновления.
-- Копирование важных процедур/функций общих модулей и доработка в скопированном модуле.
-- Неверно доработан запрос. Либо вообще не в тот запрос внесены изменения.
Выводы по итогам код-ревью:
Главная причина срыва сроков при внедрении - не все сценарии учтены.
Главная проблема сопровождения - код, не соответствующий стандартам разработки.
"Оно же работает!" - так себе подход.
Исходная статья: Как читать чужой код? Часть 1. Общие вопросы. Доработка чужого кода. Code review
Раздел 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации.
Существует сильное заблуждение - типовую конфигурацию нужно дорабатывать только в крайнем случае.
Главное же, что нужно сделать - разобраться со сценариями работы типовой конфигурации.
Т.к. конфигурация типовая, можно найти огромное количество информационных источников.
Подходы для разбора и доработки типовой конфигурации.
Рассмотрим последовательность изучения типового решения:
1. Предметная область. Наличие знаний по предметной области позволяет полноценно разобраться в происходящих бизнес-процессах и выявить все сценарии работы. Она состоит из:
-- Характерных для предметной области бизнес-процессов
-- Законодательства
-- Локальных нормативных актов
2. Архитектура решения. Рассмотрим порядок изучения каждой из подсистем:
-- Какие операции выполняются в рамках подсистемы.
-- Какая справочная информация используется. Какие особенности заполнения справочной информации.
-- Какие регистры, и как используются для обеспечения работоспособности подсистемы.
-- Какая отчетность, на основании каких данных, формируется.
Глубокий анализ требуется только при решении сложных задач, требующих больших доработок.
3. Назначение объектов метаданных.
-- Для крупных задач - необходимо понимать, как связаны все объекты подсистемы, какова последовательность их ввода.
-- Для мелких задач - это разбор конкретного объекта метаданных.
-- Для некоторых задач не имеет значения, в какой подсистеме этот объект метаданных.
Важно, на основании каких данных объект заполняется, и какие данные объект меняет.
4. Сценарии работы - основа любой разработки!
Сценарии работы следует изучить не только в месте доработки, но и в связанных объектах метаданных.
5. Работа интерфейса.
-- Продолжаем изучать сценарии работы: команды, печатные формы, обработчики событий всё это набор сценариев.
-- Учитываем наличие динами
Вступайте в нашу телеграмм-группу Инфостарт