Главная цель всего цикла статей - устранение парадокса: во всех вакансиях есть требование "уметь читать чужой код", но нигде этому не учат.
Раздел 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. Главные сложности решения, что отталкивает
Описываем ошибки правильно. Правило трех вопросов
