Зачем и как читать чужой код? Какой результат ожидаем получить? Основные подходы

06.02.23

Разработка - Рефакторинг и качество кода

Данная статья является кратким содержанием статей цикла "Как читать чужой код". Цель такой публикации: создать чек-лист различных подходов для чтения непонятного кода. Более подробно каждый из методов можно прочитать в исходной статьей. Последовательность изложения материала полностью совпадает с исходными статьями, и разделена на 4 части.

Главная цель всего цикла статей - устранение парадокса: во всех вакансиях есть требование "уметь читать чужой код", но нигде этому не учат.

 

Раздел 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. Работа интерфейса. 

-- Продолжаем изучать сценарии работы: команды, печатные формы, обработчики событий всё это набор сценариев.

-- Учитываем наличие динамически (программно) создаваемых реквизитов.

-- Учитываем наличие пустых групп в дереве реквизитов управляемой формы. Например, "ПодписиГруппа"  или "ГруппаИсправление".

-- В неучтённых ситуациях появляются ошибки: неверно отображается форма, программная ошибка!

 

6. Программный код. Изучение программного кода позволяет:

-- Понять каждый в отдельности сценарий работы.

-- Увидеть данные запросов, движений, как работает печать и почему именно так и т.д. 

-- Процедуры/функции программного интерфейса воспринимаем наряду с методами встроенного языка.

Изучаем входящие параметры и возвращаемое значение.

-- Необходимо локализовать место, которое требуется доработать. Не нужно изучать сценарии для всей страны. 

 

Мифы и подсказки при обновлении доработанной типовой конфигурации.

Миф №1. Не нужно дорабатывать типовую конфигурацию, иначе не сможем её потом обновлять. Опровержение:

-- Дорабатываем грамотно, соблюдаем стандарты разработки.

-- Не создаем дубли типовых объектов метаданных для изменения.

 

Миф №2. Нельзя дорабатывать формы типовых объектов, будет сложно их обновить. Опровержение:

-- Перенос новых реквизитов на обновленную форму происходит через Скопировать + Вставить. Они не создаются с нуля!

-- Не стоит добавлять новые элементы на форму программно! Так модули остаются типовыми. 

 

Миф №3. Обновить конфигурацию может только самый опытный сотрудник. Опровержение:

-- 15 лет назад обновил сильно переписанную Бухгалтерию 7.7 за месяц, имея опыт работы в регионе 3,5 года. 

-- Отсутствие страха и наличие системы переноса доработок помогут.

 

Подсказки:

Подсказка №1. При пропуске релизов, обновляем сразу на последний! 

Многие при пропуске 5-10 релизов обновляются последовательно 5-10 раз! Причины:

-- Обработчики обновления неверно сработают, если запустить их сразу... Впору записать в очередной миф.  

-- Не получится сохранить СФ из-за большого количества изменений... При сохранении возникнут какие-то конфликты в данных. 

-- Возникнут проблемы с объектами с префиксом в названии "Удалить". 

 

Эти вопросы можно продумать заранее. Решение есть:

-- Определить релизы, в которых удаляются объекты с префиксом "Удалить".

-- Составить список удаляемых объектов и объектов преемников. 

-- Для каждого из промежуточных релизов обновить обработчики обновления. Продумываем необходимые действия по этим объектам.

-- На копии последовательно обновляем структуру и запускаем обработчики обновления. Также делаем при обновлении рабочей базы.

-- В один заход обновляем остальные объекты на последний релиз.

 

Подсказка №2. Выполнять обновление в режиме "Показать дважды измененные объекты". 

-- Обновить требуется только объекты метаданных, которые были доработаны и Вами и вендором.

-- Объекты не попадающие под это условие автоматически выделяются.

-- Эти объекты считаем уже обновлёнными!

 

Подсказка №3. Необходимо создать несколько баз. Назначение баз:

База 1. Копия до обновления. Смотрим код и состояние форм до перехода на новый релиз. 

База 2. Типовая конфигурация старый релиз. Проверяем исходный код до доработок. Не все отмечают границы своих доработок.

База 3. Типовая конфигурация новый релиз. Смотрим исходный код в новом релизе. Рекомендуется использовать демо-базу для тестирования.

База 4. Обновляемая база. В этой базе будет новая конфигурация с выполненными ранее доработками. 

База 5. Типовая конфигурация старый релиз для сравнения. Запускаем сравнение/объединение с конфигурацией нового релиза.

Требуется для понимания объёма доработок. Помогает сделать выбор, что переносить: свои доработки или доработки типового релиза. 

 

Исходная статья: Как читать чужой код? Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации

 

Раздел 3. Разбор и доработка запросов.

 

Каждый запрос решает какую-то задачу - сценарий, чаще всего нам не известный. Как быть?

Классифицируем задачи по доработке запросов:

1. Запрос выдает не весь набор данных. Задача звучит так: Раньше работало нормально - сейчас неверный результат заполнения...

2. Добавить "несколько полей". 

3. Добавить в результат запроса дополнительный набор данных.

4. Оптимизация работы запроса.

5. К существующему запросу добавить новый регистр(ы). 

 

Как разобрать и доработать запрос.

Кратко о запросах:

1. Главные аналогии по запросам:

-- Результат запроса - это таблица. Получилась она из других таблиц.

-- При работе с запросами должна быть ассоциация работы с Excel.

-- Условия запроса - это фильтр, который накладывается как в Excel.

 

2. При работе с большими таблицами (много колонок и много строк),

-- Не пытаемся представить результат запроса в голове!

-- Сохраняем в Excel и анализируем данные там.

-- В Excel используем наложение фильтров (включается Данные->Фильтры->Автофильтр) . 

 

3. Выгрузить данные в таблицу можно следующими способами:

-- Для переменной с типом РезультаЗапроса, нажимаем Shift+F9 и пишем РезультатЗапроса.Выгрузить(). 

-- Для переменной с типом ВыборкаИзРезультатаЗапроса, пишем Выборка.Владелец().Выгрузить(). 

-- Для временных таблиц нажимаем Shift+F9 и пишем:

Запрос.МенеджерВременныхТаблиц.Таблицы[<НомерТаблицы>].ПолучитьДанные().Выгрузить()

-- Таблицу необходимо сохранить как печатную форму через Shift+F9, у Вас должен быть тип ТаблицаЗначений.

Далее F2 - показать значение. Далее справа вверху пиктограмма "Вывести список". 

-- Обязательно изучаем содержимое всех таблиц запроса.

Изучаем, какие измерения, ресурсы, реквизиты заполнены и, главное, какими значениями.

 

4. Способы наложения условий в запросах. 

Условия накладываются в следующей последовательности:

-- В параметрах виртуальных таблиц.

-- В связях между таблицами.

-- Условия в секции после слов "ГДЕ" и "ИМЕЮЩИЕ". 

ВАЖНО: Условия в секции «ГДЕ» накладываются на результирующую таблицу

 

5. Изучим главную таблицу запроса. Она всегда слева и в тексте запроса и в конструкторе запросов.

Если таблица виртуальная, то вот 3 действия для её разбора:

-- Делаем отдельный запрос без соединений и без блока условий "ГДЕ". Просматриваем и анализируем данные результата запроса.

-- Для виртуальной таблицы стираем параметры виртуальных таблиц. Все кроме периода.  

-- Если виртуальная таблица не известна, изучаем назначение в статьях! (ФактическийПериодДействия)

 

6. Изучим влияние условий в секции "ГДЕ" на результат запроса.

Иногда их так много, что не очевидно, какое из условий удаляет нужную запись. Действия для разбора:

-- Комментируем все условия. Убеждаемся, что есть нужные записи. 

-- Включаем по одному условию. Проверяем, пропали нужные записи? 

-- Как только пропали записи - внимательно изучаем и аккуратно дорабатываем условие. Контролируем результат.

 

7. Анализируем соединения. Самое простое - ЛЕВОЕ. Левое соединение не уменьшает количество записей.

НО! Могут появляться дубли и значение NULL. Их поиск - одна из задач для разработчика.

Чуть сложнее ВНУТРЕННЕЕ. 

ПРАВОЕ - не используется согласно стандартов разработки.

ПОЛНОЕ стоит использовать в исключительных случаях. Возникает много значений NULL

 

8. Действия для поиска дублей:

-- ЛЕВОЕ СОЕДИНЕНИЕ - это означает, что к левой таблице присоединяются все записи правой таблицы, которые удовлетворяют условиям связи. Одной записи левой таблицы могут соответствовать несколько записей правой таблицы.  

-- Для устранения дублей необходимо проанализировать правую таблицу и найти ещё одно поле для связи. 

-- Иногда дубли - следствие использования не всех ключевых полей в условиях связи.

Устраняем через "ВЫБРАТЬ РАЗЛИЧНЫЕ" или "СГРУППИРОВАТЬ ПО".

 

9. Особенности "ВНУТРЕННЕЕ СОЕДИНЕНИЕ":

-- Используется для фильтрации данных.

-- Иногда используют вместо условий в конструкции "ГДЕ". Это часто приводит к потере нужных записей. 

-- Для больших таблиц  для проверки запросов рекомендую ЛЕВОЕ СОЕДИНЕНИЕ, лишние записи фильтровать условием НЕ ЕСТЬ NULL. После проверки заменить на ВНУТРЕННЕЕ СОЕДИНЕНИЕ

-- Такая проверка позволяет проверить правильность условий в связях. 

 

10. Особенности конструкции ПОЛНОЕ СОЕДИНЕНИЕ:

-- Приводит к появлению "лишних" записей и полей со значением NULL.

-- Конструкцию ПОЛНОЕ СОЕДИНЕНИЕ использовать в крайних случаях.

 

11. Особенности конструкции ОБЪЕДИНИТЬ ВСЕ:

-- Объединяет таблицы с однотипной информацией.

-- Количество и тип значения полей должны совпадать.

-- NULL возникает если в одной из таблиц не указано одно из полей.

Значение NULL - чаще всего ошибка! 

-- "ОБЪЕДИНИТЬ" без слова "ВСЕ" не добавляет записи, которые уже есть. Равносильно "СГРУППИРОВАТЬ ПО" по всем полям.

-- Если в запросе с "ОБЪЕДИНИТЬ ВСЕ" много объединяемых запросов, то добавляем во все запросы первым поле "НомерЗапроса" для проверки. 

 

ВАЖНО:

ВСЕ поля запроса при использовании "ПОЛНОЕ СОЕДИНЕНИЕ" обрабатываем функцией ЕСТЬNULL.

При использовании "ЛЕВОЕ СОЕДИНЕНИЕ", все поля из правой таблицы обрабатываем функцией ЕСТЬNULL.

При использовании "ВНУТРЕННЕЕ СОЕДИНЕНИЕ" значение NULL появиться в запросе не может!

При использовании "ОБЪЕДИНИТЬ ВСЕ" при отсутствии поля в таблице, подставляем пустое значение нужного типа

 

Приёмы для разбора запросов:

1. Запрос необходимо разбирать "с конца". Не пытаться понять весь запрос! Задача - найти место, требующее доработки. 

 

2. Понять, где используется результат запроса? Его используют так:

-- Заполнение таблиц/табличных частей

-- Формирование движений

-- Проверка правильности данных

-- Для отчетов и регламентированной отчетности.

 

3. Проверяем в отладчике каждую временную таблицу/запрос. 

 

В этом Вам поможет вот эта обработка: Отладка временных таблиц и типа ТаблицаЗначений

 

4. Динамический запрос из разных процедур ищем там, где он собран полностью, и смотрим полный текст запроса. 

 

5. Для поиска места создания временной таблицы в поиск по всем текстам пишем строку: ПОМЕСТИТЬ <ИмяВременнойТаблицы>. 

 

Осталось рассмотреть особенности разбора запроса для его оптимизации.

1. Конечно, самым идеальным вариантом будет анализ плана запроса! НО! Этим механизмом далеко не все владеют!

 

2. Заменяем вложенные запросы на временные таблицы. Причины и ограничения:

-- Выбирается неоптимальный план выполнения запроса.

-- Не обращаться к физическим либо виртуальным таблицам. Обращаться к временным таблицам.

-- Для физических/виртуальных таблиц важен размер - до 1000 записей. 

-- Для временных таблиц аналогичные требования.

 

3. Без надобности не использовать таблицу ОстаткиИОбороты.

 

4. При наложении условий и связей:

-- Не использовать конструкцию ИЛИ. Она отключает использование индексов.

-- Условия и связи должны накладываться по индексированным полям.

-- При количестве записей более 10 тыс. оправдано индексирование полей временной таблицы, которые используются в связях и условиях.

 

5. Не использовать разыменовывание полей. Делать явное ЛЕВОЕ СОЕДИНЕНИЕ. 

 

6. Разыменовывание полей составного типа ЗАПРЕЩЕНО! 

 

7. Для виртуальных таблиц не использовать периодичность Регистратор и Запись. Это должно быть обосновано. 

 

Главное правило: соблюдайте стандарты разработки 1С и проблем не будет. Это работает в 90% случаев.

 

Исходная статья: Как читать чужой код? Часть 3. Разбор и доработка запросов

 

Раздел 4. Программный интерфейс. Исправление чужих доработок.

 

Как разобрать программный интерфейс и его параметры:

1. Изучаем описание экспортной процедуры/функции, которое является обязательным. Изучаем назначение и тип значения параметров. 

2. Программный интерфейс БСП описан на сайте ИТС.

3. Изучаем примеры вызова программного интерфейса в типовой конфигурации.

Обращаем внимание на параметры, тип и значение заполнения. 

4. Используем отладчик для изучения и адаптации кода.

5. Изучаем все временные таблицы программного интерфейса.

6. Нередко использую не результирующую таблицу, а промежуточные!

7. Экспортные методы служебного программного интерфейса также допустимо использовать.

 

Как быстро переделать чужую работу.

Рассмотрим ситуацию, когда сложную задачу кому-то поручили, а он не справился!

Или сделал нереально криво с огромным количеством ошибок.

Самое главное в такой ситуации - выяснить все сценарии работы по задаче. Источники информации:

1. Техническое задание

2. Список сценариев работы. 

3. Аналитик по задаче.

4. Набить тестовых примеров в базу. 

5. Пообщаться с архитектором. Выяснить, что не так и каковы ожидания. 

6. Всё, что выяснили - ОБЯЗАТЕЛЬНО ЗАПИСАТЬ! 

 

Действия для ускорения разработки:

1. Выяснить у архитектора правильный путь решения задачи. 

2. Совместно с аналитиком протестировать доработку.  

3. Спросить более опытных коллег.

4. Если в процессе кодирования столкнулись с непониманием кода... 

Уже рассмотрели много способов в нём разобраться!  

 

Исходная статья: Как читать чужой код? Часть 4. Программный интерфейс. Исправление чужих доработок

 

Другие полезные статьи:

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Ни в ЗУП ногой!? А мне нравится! Часть 4. Главное - правильный перенос данных!

Ни в ЗУП ногой!? А мне нравится! Часть 1. Главные сложности решения, что отталкивает

Описываем ошибки правильно. Правило трех вопросов

 

 

См. также

Пример проведения Code-review #1

Рефакторинг и качество кода Программист Платформа 1С v8.3 Абонемент ($m)

В статье расскажу и покажу процесс проведения Code-review на примере обработки с GitHub.

1 стартмани

04.06.2024    3502    mrXoxot    46    

32

Результаты ревью кода 1500+ решений каталога Инфостарт: наиболее частые ошибки разработчиков в коде

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

10.04.2024    9939    artbear    84    

101

Ниндзя-код

Рефакторинг и качество кода Программист Платформа 1С v8.3 Россия Бесплатно (free)

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)

01.04.2024    2862    DrAku1a    15    

35

Практическое программирование: когда скорость важнее совершенства

Рефакторинг и качество кода Программист Бесплатно (free)

В новом материале мы анализируем, как в программировании баланс между быстротой разработки и тщательной проработкой кода влияет на конечный продукт. Обсуждаем, почему иногда важнее сосредоточиться на скорости выполнения проекта, и когда можно позволить себе уступить в качестве ради достижения бизнес-целей.

01.04.2024    813    Prepod2003    6    

2

Когда понадобился новый оператор

Рефакторинг и качество кода Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1545    ZhokhovM    5    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    3224    ZhokhovM    4    

9
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. maksa2005 536 06.02.23 11:58 Сейчас в теме
"уметь читать чужой код"
Прочитал код 1сников от ЗУП, БП т.п. нормально. читабельно
2. biimmap 1944 06.02.23 13:55 Сейчас в теме
(1)
ЗУП, БП т.п. нормально. читабельно


Да настанет судный день, когда типовые конфигурации станут не читабельными)))
3. пользователь 07.02.23 05:34
Сообщение было скрыто модератором.
...
4. pavlov_dv 07.02.23 06:53 Сейчас в теме

6. Без привязки к стандартам проверяю выбранный способ решения задачи.

-- Рекомендую проводить промежуточный этап проверки Desing review.


Наверное речь про Design review?
5. biimmap 1944 07.02.23 11:21 Сейчас в теме
(4)
Наверное речь про Design review


всё верно! исправлю опечатку
6. starik-2005 3050 07.02.23 12:33 Сейчас в теме
А я вот все никак не доберусь. Или слишком много получается, или не получается объяснить. В первом случае читатель столкнется с информационным сопротивлением, во втором случае ничего не поймет. Может быть однажды дума выдумается и напишется.
7. biimmap 1944 07.02.23 13:18 Сейчас в теме
(6) поэтому на мой взгляд и нужны 2 варианта! Короткий вариант как замануха, или для тех кто не любит много символов... А длинный вариант для тех кто всё таки любит читать.
8. пользователь 07.02.23 19:12
Сообщение было скрыто модератором.
...
9. vipetrov2 08.02.23 05:37 Сейчас в теме
Описаны очевидные вещи, когда надо анализировать чужой код, который находится в 3 - 5 функциях.
В реальности такие дебри бывают.
Что делать если код выполняется в несколько потоков? Как тестировать?
Что делать если вложенных уровней вызовов 20 штук?
Особенно повеселило: "Узнать тип переменной...". Ага в нетипизированном языке программирования узнать тип. А что вы будите делать с массивом, в котором еще 3 - 5 уровней массивов? Или хотя бы в функцию передается форма и там столько накрутят.
Что делать, если запросы формируются программно, с рекурсией и 10 уровнями вложенных функций?
Это все сложные вопросы, здесь нужно еще формировать культуру написания сложного кода, шаблоны.

Что бы со всем этим работать, нужен инструментарий.
10. biimmap 1944 08.02.23 11:43 Сейчас в теме
(9) неплохие вопросы... Давай разберем по пунктам:


(9)
В реальности такие дебри бывают.


Если понимать, что любые дебри - это набор простых кусков кода, то к каждому из кусочков кода нужно применить какой-то из описанных способов разбора кода. А уж какие бывают дебри рассказывать ЗУПеру с опытом в 15 лет нет смысла!


(9)
Что делать если вложенных уровней вызовов 20 штук?


У меня в статье написано, что не надо отладчиком по ним шагать. Надо искать через поиск по всем текстам нужное для доработки место! Т.е. ищешь по именам реквизитов или именам объектов метаданных. Это реально большая сложность в текущих версиях типовых конфигураций. При переходе с обычных форм было тяжело.


(9)
Узнать тип переменной


Что значит не типизированный язык??? Здесь любая переменная в коде имеет какой-то тип значения. И когда через Shift+F9 смотришь её тип, становится понятней, что с этим можно сделать.

Какая разница сколько уровней у массива? Открой последний и посмотри тип значения элементов?! Где здесь противоречие?



(9)
Что делать, если запросы формируются программно


Разбору запросов посвящен весь третий раздел статьи. + есть в более подробном виде статья. В конце раздела ссылка на неё добавлена. Отвечу по сути вопроса:

Нужно найти место, в котором собран финальный запрос. Получить готовый текст запроса. Этот текст запроса закинуть в конструктор запроса и доработать. Потом уже когда стало ясно, что результат получился, нужно по именам временных таблиц найти то место, которое доработано тобой, и уже туда внести свои правки. Описанный подход для ЗУПа работает "на УРА"! Если есть желание изучи подробней третью статью.



(9)
нужно еще формировать культуру написания сложного кода


чаще всего достаточно просто изучить и соблюдать стандарты разработки. На это ссылаюсь в статье как на этапе Code review, так и в статье про разбор и доработку запросов.

Ну и главные выводы по Вашим вопросам:
1. Никто не говорил, что чтения кода - простой процесс! Именно поэтому и написаны 4 большие статьи! Эта статья - выжимка тезисов, ключевых моментов
2. Чужой код зачастую не могут читать даже люди с опытом 5 и более лет. Много раз это встречал на практике!
3. Систематизация подходов помогает абсолютно в любой сфере. В т.ч. и при чтении кода.
11. Virikus 62 13.02.23 15:49 Сейчас в теме
Что делать если вложенных уровней вызовов 20 штук?


У меня в статье написано, что не надо отладчиком по ним шагать. Надо искать через поиск по всем текстам нужное для доработки место! Т.е. ищешь по именам реквизитов или именам объектов метаданных. Это реально большая сложность в текущих версиях типовых конфигураций. При переходе с обычных форм было тяжело.


Можно еще включить замер производительности. В результатах замера также работает поиск. Плюс при просмотре кода и хождении по методам видно какие из них выполнялись и в каких ветках условий и циклов было выполнение.
popov2000; biimmap; +2 Ответить
Оставьте свое сообщение