Как читать чужой код 1с

Обновлено: 04.07.2024

Примечание: первоначально эта статья была написана для сайта Fuel Your Coding back в мае 2010 года. К сожалению, этот сайт сейчас не работает, поэтому я публикую статью здесь, чтобы сохранить её для потомков. Я собирался обновить её, учитывая последние веяния, но решил оставить так, как она была написана. Те части, что подустарели, могут показаться немного смешными, но да ладно. Получайте удовольствие…

Наиболее очевидным способом повысить качество своего программирования является писать больше программ. Каждый знает это. Однако другой способ, который, я уверен, улучшит ваше программирование, — совершенно противоположный. Изложу это так ясно, как смогу.

Если вы желаете резко поднять ваше умение программировать, необходимо… читать код, написанный другими программистами.

Вы можете верить в это, можете не верить. Ваше право. Но если вы готовы рискнуть, то, уверен, вы будете вознаграждены за потраченное время.

В этой статье я хотел бы помочь вам в выборе того, что именно читать, и дать практические советы по такому чтению. Если вы уже и так читаете другие программы, то, может быть, вы найдёте здесь что-нибудь, что позволит получить больше от ваших усилий. Если же вы не читаете коды других разработчиков, то вы просто обязаны заняться этим.

Что читать

Это — важное решение, и то, в котором трудно советовать. Я не хотел бы просто указать вам на какой-то код, который, как я думаю, вы должны прочитать, потому что на самом деле надо рассматривать то, чем вы занимаетесь. Однако я дам несколько направляющих указаний, чтобы помочь вам в выборе программ для чтения.

Читайте программы, имеющие к вам отношение

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

• Плагин WordPress, который вам действительно нравится;
• Ruby gem, который вы считаете полезным;
• Плагин jQuery, к которому вы продолжаете возвращаться.

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

Читайте программы, впечатлившие вас

Помню, что, когда я первый раз просматривал сервис создания презентаций 280 Slides, я подумал: «Да! Круто!». Я быстро выяснил, что программа, управляющая этим сайтом, является проектом Cappuccino с открытым кодом. Это знание вошло глубоко в моё сознание, и когда я как-то наткнулся на ещё одно впечатляющее приложение, работавшее на Cappuccino, я уже знал, что на этом проекте я смогу многому научиться. Что произвело сильное впечатление на вас в последнее время? Эта программа имеет открытый исходный код? Если так, то она — отличный выбор для чтения: код, скорее всего, впечатлит вас так же, как и само приложение.

Читайте программы, написанные теми, кого вы уважаете

Программисты, достойные уважения

Если вы уже занимаетесь программированием с открытым исходным кодом какое-то время, то, вероятно, у вас уже есть на примете программисты, заслужившие ваше уважение. Я мог бы с ходу назвать несколько разработчиков, программы которых вызывают у меня просто «белую зависть».

Если у вас пока нет такого разработчика, то найти его несложно. Он(а), вероятно, является автором какой-нибудь программы в одном из предыдущих двух разделов (программы, имеющие к вам отношение, или программы, впечатлившие вас).

Читайте программы, которые вы сможете, действительно, достаточно глубоко понять

Если вы склонны рисковать, то можете рассмотреть погружение в большой проект, как, например, Ruby на Rails, Drupal или jQuery. Но я предложил бы вам не использовать пока такие проекты, если вы, конечно, не являетесь опытным читателем программ.

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

Как читать

Теперь, когда код для чтения выбран, как наилучшим способом читать его? Я прочитал на сегодня множество программ и могу предложить несколько способов максимизации вашего КПД.

Изучите общую картину

Структура каталога twitter gem

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

После того как надлежащая ясность внесена, вашим первым шагом должно быть рассмотрение структуры проекта. Объём этой работы зависит от размера выбранной базы исходного кода, но даже если она занимает больше одного файла, это потребует лишь ненамного больше времени.

Прежде всего, зафиксируйте для себя структуру файлов. Этот шаг легче выполнить с помощью редактора, который имеет вид иерархии папок, как, например, TextMate. Здесь, как пример, показан прекрасный вид Twitter Ruby gem.

Цель этого шага состоит просто в ознакомлении с источником. Разберитесь, какие файлы включают в себя / вызывают / загружают другие файлы, где находится основная часть кода, какие пространства имён используются (если таковые имеются) и прочее такого рода. Получив общее представление, можно погружаться в детали.

Документируйте ваши результаты

Чтение кода не должно быть каким-то пассивным действием. Рекомендую добавлять комментарии по мере продвижения, документировать ваши предположения и ваши выводы, когда вы начнёте понимать ход выполнения программы. Когда вы начнёте впервые, ваши комментарии будут выглядеть, вероятно, так:

По мере понимания процессов вы можете удалить небольшие иерархические комментарии, которые вы оставляли для себя, и, возможно, написать более значимые и авторитетные комментарии, которые могли бы быть переданы обратно в проект.

Используй тесты, Люк

(Прим. переводчика: автор вспомнил «Используй силу, Люк» из «Звёздных войн»)

Будем надеяться, что проект, который вы выбрали, имеет набор тестов. Если нет, то можете пропустить этот раздел вообще (или найти проект, имеющий такой набор).

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

Измените код, скомпилируйте

Кто сказал, что чтение кода должно быть пассивным? Вы начнёте, действительно, понимать код, только после того, как сломаете всё и снова соберёте вместе. Вспомните пройденные тесты? Сделайте так, чтобы они завершились неудачно, добавьте кое-что или попытайтесь изменить реализацию так, чтобы они прошли нормально. Попробуйте добавить какую-нибудь небольшую «фичу», которая вам кажется «крутой», или настройте регистрацию по всему проекту так, чтобы можно было распечатать вывод на различных этапах выполнения программы. Это по-прежнему чтение? Абсолютно, но такой подход является больше собственным приключением, чем чтением детективного романа. И это — именно то, что надо!

Смыть и повторить

(Прим. переводчика: из анекдота про айтишника, моющегося шампунем строго по инструкции — бесконечно)

Закончив с чтением одной кодовой базы, возьмите другую и начните процесс снова. Чем больше кодов вы читаете, тем лучше идёт это чтение и тем больше вы получаете из него за меньшее время. Я думаю, вы обнаружите, что ваш КПД растёт довольно быстро и что это действительно очень приятный способ обучения.

Где начать

Единственным, самым важным источником для чтения кода является для меня GitHub. Этот сайт позволяет так легко найти новые проекты и действительно великих программистов, что вы действуете себе во вред, если не используете его. Я предлагаю начать на GitHub и читать код прямо на сайте, пока не найдёте проект, из которого по вашему мнению вы сможете извлечь какие-то уроки. Затем склонируйте его и читайте!

А вы используете чтение кода как обучающий инструмент? Какие проекты вы порекомендовали бы коллегам? Прочитали какую-нибудь хорошую программу в последнее время?

Здесь если начать описывать данный процесс, то получится статья о том, как они работают. А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.

Кейс 6. Как разобратьcя и использовать программный интерфейс.

Наверняка часто встречаются разработчики, которые считают, что написать самому запрос к какому-то регистру гораздо проще, чем разбираться в существующих модулях типовых конфигураций. На первый взгляд - ДА! НО! Любой программный интерфейс генерирует с десяток, а иногда и больше временных таблиц. Часто оказывается, что данные одной из временных таблиц ну просто специально для меня написали, чётко под мою задачу! Конечно, не все это знают, не все знают, что вообще есть какой-то программный интерфейс, как его искать и т.д. Вот и разберёмся со следующими вопросами:

1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?

2. Что такое БСП (кратко)?

3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?

4. Чем отличается программный интерфейс от служебного? Можно ли использовать служебные экспортные процедуры/функции?

5. Он же изменится. Зачем его использовать, если 1С перепишет его?

Раскроем каждый пункт подробно:

1. Как понять, какой интерфейс нам предоставляет типовая конфигурация?

На самом деле элементарно! Давайте рассмотрим на примере ЗУПа. В ЗУП есть часто используемые разделы:

-- Учет страховых взносов

Остановимся на таком списке. Конечно, разделов гораздо больше. На что надо обратить внимание: На то, что каждый раздел имеет свои Общие модули, и они называются так же, как и раздел учета. Т.е. в любой конфигурации названия общих модулей сделаны очень понятными и соответствуют разделам учета/решаемым задачам.

Здесь необходимо напомнить о стандартах разработки! Согласно стандартов по оформлению общих модулей, секция "Программный интерфейс" должна всегда располагаться вверху общего модуля. Далее следует секция "Служебный программный интерфейс".

Берем штатное расписание. Заходим в основной серверный модуль "УправлениеШтатнымРасписанием". Видим процедуры:

если посмотреть в служебный программный интерфейс, можем найти там довольно полезную функцию:

полезные процедуры можно найти даже в секции "Служебные процедуры и функции". Например, в этом модуле много функций, для построения запросов по штатному расписанию:

или процедуры, которые позволяют получать какие-то данные по позициям штатного расписания:

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

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

Опять же на примере ЗУП обратимся к модулю объекта обработки "Менеджер данных учета времени сотрудников". Здесь есть вот такие полезные процедуры:

Если посмотреть модуль менеджера документа "Больничный лист", можно найти функцию:

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

Настоятельно рекомендую изучать программный интерфейс того раздела учета, в котором Вам предстоит вести разработку по Вашей задаче. Наверняка много полезного найдёте для себя.

БСП - Библиотека стандартных подсистем. Описывать её функционал, конечно, не стану. Функционал в каком-то виде описан и на сайте ИТС, и на данном ресурсе.

Что важно отметить в этом пункте: Если Вам нужно что-то сделать с таблицей, массивом, файлом, хранилищем значений или ещё с каким-то универсальным механизмом, которым "оборудованы" все конфигурации. ОБЯЗАТЕЛЬНО смотрите в описание БСП. Наверняка Ваша задача уже решена. Осталось с ней разобраться ниже описанными способами, и использовать программный интерфейс в своём коде.

С точки зрения качества кода при использовании как программного интерфейса как типового (имею в виду учетные задачи), так и БСП, Вы шагнёте на новую высоту (это больше, чем на ступень вверх!). На собеседованиях Вам наверняка зададут вопрос о том, знаете ли Вы, что такое БСП, используете программный интерфейс в своём коде или нет?

По себе могу сказать, что половину своих задач решаю именно с помощью программного интерфейса! Лучше я потрачу время на изучение этой темы, чем буду писать никому ненужный код с так себе качеством.

3. Как понять, что делает та или иная процедура/функция, какие параметры нужно передать, чтоб она сработала?

Опишу способы которыми пользуюсь сам:

-- Первое, что я делаю - читаю описание процедуры/функции, которое, согласно стандартам разработки, является обязательным для экспортных процедур/функций программного интерфейса модулей. Обычно в нём сухо, коротко описано назначение и тип значения/назначение входящих параметров. Часто уже это описание на 30% даёт понимание, как использовать этот программный интерфейс.

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

-- Следующий шаг - посмотреть, как вызывается программный интерфейс в типовой конфигурации. Бывало, сталкивался с неиспользуемым программным интерфейсом. Таким пользоваться сразу не рекомендую, т.к. наверняка его забыли стереть и скоро это обязательно сделают. На этапе анализа примеров вызова программного интерфейса необходимо обратить внимание на заполнение параметров программного интерфейса.

-- Главное, что помогает мне и обязательно поможет Вам, - отладчик! Найдя место вызова нужного Вам программного интерфейса, нужно изучить, что у него на входе и на выходе. Для этого необходимо:

а. Поставить точку останова в месте вызова программного интерфейса в типовом коде. Конечно, необходимо найти хотя бы одно место, откуда он вызывается. Т.е. какое пользовательское действие приводит к запуску программного интерфейса. Зачастую таких мест много и найти их нетрудно, часто даже можно догадаться.

б. Скопировать весь текст вызова программного интерфейса в свой код, и постепенно адаптировать свой код под параметры интерфейса, чтобы он сработал без ошибок. Данный путь, во-первых, сложней, во-вторых, Вам его всё равно придётся пройти, т.к. адаптация своего кода под программный интерфейс неизбежна, если Вы его хотите использовать. Поэтому обязательно идём по этому пути.

-- В отладчике Вам необходимо посмотреть параметры на вход, тип значения, чем заполнены. Часто необходимо, чтобы в Менеджере временных таблиц уже была временная таблица с определёнными колонками, которая станет "фильтром" для получаемых данных. Отладчик позволяет увидеть, какие данные в этой временной таблице.

ВАЖНО: Опять же напишу - не пытайтесь фантазировать, как выглядит заполненная таблица. Надо найти такой вызов программного интерфейса, чтоб в нём было как можно больше данных и на входе, и на выходе. Иногда полезно несколько мест посмотреть отладчиком.

-- Последним действием необходимо изучить все временные таблицы, которые создал программный интерфейс, и посмотреть на результат его работы. В моей практике нередко бывает, что использую не результирующую таблицу, а несколько промежуточных! Поэтому и надо посмотреть их все. Вдруг наилучшим образом под Вашу задачу подойдёт промежуточная таблица!?

-- После того, как программный интерфейс сработал, не забывайте удалять из менеджера временных таблиц ненужные данные. Особенно если какие-то временные таблицы огромных размеров, т.е. >= 100 тыс. записей.

Для ответа на этот вопрос нужно обратиться к стандарту разработки под названием "Структура модуля". В нём указано вот какое описание:

а. Раздел "Программный интерфейс" содержит экспортные процедуры/функции, которые можно вызывать из любых объектов метаданных, в т.ч. через внешнее соединение. Т.е. не важно какую задачу решаете, если есть потребность в использовании процедур/функций этого раздела смело пользуйтесь!

б. Раздел "Служебный программный интерфейс" содержит экспортные процедуры/функции, которые являются частью какой-то подсистемы. Их использование, согласно стандарту, допускается только внутри подсистемы, в которую входит общий модуль или объект конфигурации. Т.е. если мы смотрим служебный программный интерфейс штатного расписания, то эти процедуры не следует использовать в расчете налогов или зарплаты) Да и вряд ли они туда подойдут!

в. Раздел "Служебные процедуры и функции" содержит процедуры/функции, которые используются для реализации программного интерфейса (в т.ч. служебного) данного модуля. Не рекомендуется их использование за рамками модуля, а тем более за рамками подсистемы. Но "не рекомендуется" не означает, что в модуле не могут быть экспортные процедуры/функции. Их необходимо также использовать в рамках подсистемы, в которую входит общий модуль.

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

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. Необходимо выполнить небольшую или, наоборот, большую доработку в уже существующем (не типовом) объекте метаданных или во внешней обработке/отчете.

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

3. Отдельно выделю доработку типовой конфигурации. Её код усложнён из-за необходимости учитывать большое количество сценариев и стандартов разработки. Универсальный код всегда сложнее анализировать.

4. Вам необходимо провести обновление доработанной кем-то или Вами конфигурации. Зачастую необходимо обновить вообще незнакомую конфигурацию, возможно, Вы с ней не сталкиваетесь по работе. Например, моя конфигурация ЗУП, но мне приходилось обновлять 5 примерно похожих между собой конфигураций УПП 1.3.

5. Отдельно выделю разбор и изменение запросов.

6. Как разобраться в работе программного интерфейса. Как его использовать в своей доработке.

7. Отдельно выделю необходимость помочь коллеге, или необходимость за кого-то переделать работу в невероятно короткие сроки. Не все разработчики могут выполнить поставленную им задачу, и приходится за кем-то переделывать.

Теперь определимся с ожидаемым результатом от наших действий:

1. Доработка выполнена таким образом, чтоб не сломать уже существующие сценарии. Доработка соответствует общепринятым стандартам разработки. Если дорабатывается тиражное решение - стилистика кода соответствует общепринятой.

2. Проверили работу коллег, указали им на явные и не очень ошибки, рассказали, какой код можно оптимизировать либо заменить на программный интерфейс. Проверили синтаксис написанного кода, указали на опечатки и лишние сокращения.

3. Разобрались, как работает типовой код. Определили объекты метаданных, из которых вызывается. Определили сценарии работы кода. Выполнили свои доработки, не нарушив логической целостности кода.

4. Обновили доработанную конфигурацию, перенесли весь дописанный код. Где-то код заменили на типовой. Где-то пришлось заново доработать.

5. Разобрались с запросом. Внесли в него свои доработки. По возможности оптимизировали запрос.

6. Разобрались с программным интерфейсом, включили его в свою доработку.

7. Помогли коллеге, ответили на вопросы, проверили его способ реализации, подсказали правильный путь. Либо всё это сделали без использования коллеги. Исправили все ошибки, либо с нуля выполнили доработку.

Вводная информация, применимая ко всем кейсам:

1. Конечно же, будут попадаться незнакомые процедуры или функции встроенного языка. Их изучают в 2 простых шага:

-- Синтакс помощник расскажет Вам о её предназначении.

-- Поиск по всем текстам в любой типовой конфигурации покажет Вам множество примеров по использованию. Часто эти примеры можно прямо копировать в свой код, когда будете вести разработку.

2. В целом программирование в 1С построено на том, что любая переменная или реквизит имеет определённый тип значения. Набор свойств и методов, доступных для переменной/реквизита, можно найти в синтакс помощнике в разделе, где описан конкретный тип значения. Тип значения конкретной переменной в коде можно посмотреть отладчиком. Узнав тип значения какой-то переменной, Вам может стать понятней код, который написан применительно к переменной.

3. Не нужно никогда изучать код путём прохождения ВСЕГО кода через отладчик. Поверьте, Вы сойдёте с ума и ничего не поймёте! На выходе будет каша в голове. Пользуйтесь поиском по всем текстам, чтоб найти нужное для разбора и отладки место.

4. Возможно, Вам требуется разобраться с каким-то объектом метаданных, с которым Вы никогда не сталкивались. Тут описанные выше методы не подойдут. Вам необходимо поискать статьи, которые описывают теорию об этом объекте и практическое применение объекта. Например, Вы не знаете, как работают Web-сервисы. Найдите статью об этом, скорей всего, статья даже окажется на Инфостарте. Часто авторы статей совмещают теорию с практикой и показывают примеры кода, как это использовать. Если пример можно скачать за 1$m, не жалейте этих денег. Самостоятельно дольше будете писать! И нет, это не скрытая реклама данного ресурса. Это мой опыт, который позволил со многими трудными механизмами разобраться.

5. Не стесняйтесь непонятные вопросы задавать на форумах. Даже если Вас обольют 10 человек грязью, всегда найдётся один, который поможет!

6. Любая конфигурация/обработка/отчет/объект метаданных - это набор сценариев, который заложил в неё разработчик. Прежде, чем пытаться доработать тот или иной кусок кода, необходимо выявить те сценарии, которые уже заложены. Способы выявления сценариев будут раскрыты ниже для каждого кейса.

7. Приучите себя к правилу: Нельзя начинать разработку, пока Вы четко не знаете существующие сценарии и как должен выглядеть сценарий после Ваших изменений. Сценарий - это основа для любой разработки. Писать его нужно ДО кодирования, а не после!

8. Не рекомендую никому вести разработку на "тестовых примерах". Тестовые данные никогда не показывают полную картину. Максимум тестовый пример охватывает 20-30% сценариев, которые необходимо учесть. Задайте себе вопрос: "Кто будет дорабатывать/тестировать остальные 70-80% сценариев"?

Кейс 1. Доработка кем-то придуманного кода. Условимся, что это не код типовой конфигурации.

В данном случае рассмотрим самую страшную ситуацию, когда доработать нужно либо написанное с нуля решение/обработку/отчет, либо так называемые партнёрские решения.

1. Первое, что Вы должны понять, есть ли описание этого решения, либо человек, который может рассказать, как оно работает. Конечно, Вам не требуется знать всю архитектуру, но Вам обязательно нужно понять, как работает кусок, который требуется доработать.

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

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

б. С обработкой сложней:

-- Первое, что надо посмотреть в коде - какие объекты модифицирует обработка. Делаем просто поиск процедуры Записать(). Всё станет очевидно.

-- Далее надо ответить на вопрос: откуда берется список объектов, который меняется. Скорей всего есть запрос.

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

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

ВАЖНО: Прежде чем отладчиком смотреть такие обработки, необходимо закомментировать все Записать(), найденные на первом шаге. Это убережет Ваши данные от ненужных изменений.

-- Нужно разобраться с заполнением тех параметров, которые выведены на форме. Для этого смотрим, где в запросах они используются? Некоторые параметры могут быть не используемыми! Это нужно определить на данном этапе и убрать сразу их с формы обработки!

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

в. С чужими доработками, особенно когда нет описания, самый сложный случай. Рассмотрим именно его. Финальная цель - также разобраться со сценариями работы и потом их модифицировать. Вот что для этого необходимо сделать:

-- Весь код можно разделить на 2 части: интерфейсный код (управление элементами формы) и объектный код (обработка заполнения, проверки, записи объекта, формирования движений документов, печать). Поэтому первое, что надо сделать - определиться, что Вы планируете доработать - интерфейс или объект.

-- С интерфейсным кодом обычно в самописных решениях никто особо не заморачивается. Поэтому найти, где прячется тот или иной реквизит, несложно. Но здесь стоит напомнить, что прятать реквизиты можно благодаря ещё 2-м механизмам: функциональные опции и права пользователя (для управляемых форм).

-- С объектным кодом чуть сложней. Надо определиться, какую часть кода Вы хотите изменить (обработка заполнения, проверки, записи объекта, формирования движений документов, печать).

-- Далее Вам необходимо посмотреть на уже заполненные данные. Неважно, какой это объект метаданных, можно вывести запросом все или часть данных с отбором по периоду или какому-то полю (чтоб не повесить сервер). Изучите, какими значениями заполнены реквизиты, особенно, если их тип - Перечисление. Стоит помнить, что перечисления созданы для описания сценариев. Можно по коду посмотреть, прописаны какие-то сценарии по значениям перечислений или это просто настройка, которую в отчете используют.

-- Чтобы разобраться с заполнением, необходимо изучить, куда потом заполненные данные идут? Если это документ, то изучаем движения. Если это регистр сведений - изучаем, где он используется. Так можно выяснить часть сценариев работы.

-- Необходимо понимать, где какой код искать. Печать, заполнение - модуль менеджера. Часть процедур могут быть вынесены в общие модули. Проверка заполнения, запись, проведение - модуль объекта. У регистров вместо модуля объекта используется модуль набора записей. Обычно в модуле набора записей расположен код формирования записей вспомогательных регистров сведений. Не стоит искать код заполнения объекта в форме объекта, хотя иногда и такое ещё встречаю.

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

После того, как мы выяснили сценарии работы, изучили массив данных, протестировали в пользовательском режиме и посмотрели в отладчике. Можно приступать к доработке такого кода.

ВАЖНО: В остальных кейсах необходимо пройти те же самые шаги. Поэтому по остальным кейсам буду описывать только отличия от первого.

Кейс 2. Выполняем code review.

Почему кейс 2 идёт после доработки нетиповых решений? Всё потому, что проверяем-то мы не типовую конфигурацию от 1С. А проверяем мы то, что написали наши коллеги. Иногда приходится проверять то, что написали уволенные коллеги или уволенная вся команда))) Т.е. никто не знает, как оно работает, и нигде не описано.

НО! Цель код ревью - проверка соблюдения стандартов разработки 1С. На эту тему написано очень много статей, поэтому подробностей здесь не будет. Коротко опишу, что проверяю сам:

1. Есть в стандартах раздел "Соглашения при написании кода". Этот раздел по сути показывает, грамотный человек писал код или нет. Многие любят излишние сокращения, не любят писать с заглавной буквы, делать пустые строки между блоками и т.д. Выполнение разработчиком этой группы стандартов так же важно, как и грамотная устная и письменная речь. Несоблюдение этих стандартов затрудняет чтение и понимание кода! Да и просто это неуважение к остальным коллегам! Ну и собственно длительно с таким кодером я работать не стану. Пару раз предупреждаю о соблюдении этой группы стандартов, не понял - на выход!

2. Если в рамках задачи создаются новые объекты метаданных - проверяю группу стандартов "Создание и изменение объектов метаданных". Цели данной проверки те же. Обеспечение единого подхода при создании объектов метаданных. Иногда встречаю реквизиты вместо Сотрудник, Подразделение - Сотр, Подр. Встречалось, что Сотрудник был с типом "Строка", а не справочник. И это была не механическая ошибка. В самописной базе не было такого справочника! Необходимо создавать объекты метаданных по описанным в стандартах принципам. В обработчике ПередЗаписью встречал проверку заполнения реквизитов и т.д.

3. Далее проверяю вопросы клиент-серверного взаимодействия. Собственно в этой группе стандартов перечислены необходимые проверки. Очень много кода пишут на клиенте, много лишних серверных вызовов, не используется серверный вызов без контекста.

4. Следующее проблемное место в коде - обработка данных (запросы, выборки, транзакции, блокировки).

-- По запросам наиболее часто встречается неверное использование индексов, либо вообще не думают об этом. Данная ошибка тормозит работу не только одного клиентского сеанса, но и сервера в целом! Не используются виртуальные таблицы с параметрами, запросы делают к физическим таблицам. До сих пор встречаю вложенные запросы к довольно большим таблицам.

-- При выборке данных часто встречается Запрос.Выполнить().Выгрузить() и дальше обрабатывается таблица. Зачем? Необходимо использовать выборку из результата запроса.

-- Часто встречаются запросы в циклах. Особенно часто они неявные, возникают при вызове программного интерфейса типовых конфигураций в цикле. Иногда пишут свою процедуру/функцию с запросом и используют её потом в цикле. Цикличное обращение к базе данных в несколько раз замедляет работу кода. При количестве итераций более 1000 замедление будет очень заметным!

-- Избыточное использование транзакций (при редактировании формы, к примеру)

-- Неоправданное использование блокировок при выполнении запросов к регистрам накопления. Ведь блокировка нужна только при ОДНОВРЕМЕННОМ обращении нескольких пользователей К ОДНИМ И ТЕМ ЖЕ ДАННЫМ! Но её используют и там, где пользователи жестко разграничены через РЛС. Необходимо на этапе разработки понимать, как будут работать пользователи. Можно по этому вопросу проконсультироваться с архитектором проекта. На всякий случай использовать блокировки НЕЛЬЗЯ!

-- Из неописанного в стандартах разработки. С удивлением для себя обнаружил, что использование следующего кода сильно тормозит работу. В выборке 6000 записей, в таблице, которую обрабатываем 100 000 (сто тысяч). В итоге этот код выполнялся 40 минут!

После того, как данный код был переписан на запрос, заполнение ссылок занимает секунды.

5. В последнюю очередь проверяется группа стандартов "Разработка пользовательских интерфейсов" и "Проектирование интерфейсов 8.3". Список проверок описан в стандартах. Нет цели его здесь повторить. Самое главное это удобное расположение элементов формы, таблиц, команд, итогов. Необходимо располагать самые важные элементы так, чтоб они заполнялись первыми. В табличных частях фиксировать левые колонки, если без прокрутки невозможно просмотреть всю табличную часть. Интерфейс должен быть понятен пользователю и не содержать лишних элементов, которые в текущем сценарии не используются.

6. Без привязки к стандартам проверяю выбранный способ решения задачи. Многие коллеги настолько боятся менять типовые объекты, что копируют их целиком и меняют скопированный объект! В этот момент коллеги забывают, что скопированный объект работает на программном интерфейсе конфигурации, в которой он создан. Если через сколько-то релизов сильно изменят программный интерфейс, то скопированный объект перестанет работать и его придётся обновлять! Так почему не доработать сразу типовой объект?!

Аналогично поступают с некоторыми процедурами общих модулей. Создают новый общий модуль, в него копируют процедуры и функции, которые планируют поменять и там меняют. Ошибочно это по той же причине: как только изменят используемые процедуры и функции в типовой конфигурации, Ваша доработка перестанет работать!

7. Также по коду часто видно, отработаны все сценарии? или разработчик схалтурил и сделал лишь часть работы. Понять это можно, анализируя условия, которые есть в доработанных процедурах и функциях. Часто встречаю, что из нескольких веток условия доработка есть только в одной ветке. А кто остальные будет делать?

8. Очень рекомендую проводить дополнительный (промежуточный) этап проверки Desing review. Этот этап проводится когда разработчик выполнил примерно треть своей работы. Он уже разобрался в коде, который ему требуется менять, уже знает, какие запросы и как будет менять, "накидал", как будет выглядеть интерфейс. Цель этого этапа на старте разработки понять, что разработчик выбрал правильный путь решения с одной стороны, архитектор/аналитик верно поставил задачу с другой стороны.

Главная причина срыва сроков в разработке - не все сценарии учтены. Так это или нет позволяет понять промежуточная проверка. Если мы находим новые сценарии или видим, что текущие описаны неверно, можем сразу об этом сообщить руководству/заказчику, согласовать новые сроки и учесть бОльшее количество сценариев при разработке.

Пройдя все описанные этапы код ревью, пишем кучу замечаний разработчику и заставляем его исправлять свой код, даже если ему кажется, что "оно же работает!".

Остальные части доступны по ссылкам:

Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!

Предположим, от такого занятия Ваши веки постепенно тяжелеют, и… Приходится пробудиться от необходимости понять чужой код и привести его в порядок. На мой взгляд, визуально сканировать иероглифы не так сложно как может показаться сначала. Как бы то ни было, необходимо уметь читать чужой код и редактировать, и один процесс не существует без второго.

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

Говоря о вероятности наличия ошибок, заметим, что в старых, тысячу раз проработанных файлах их меньше. Обычно массу ошибок мы встречаем в файлах, который никогда не меняли.

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

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

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

Если Вы совершаете повторный поиск чего-то, на что вновь потребовалось приличное количество времени – необходимо обратить на это внимание.

Проведите анализ – с чем чаще всего пришлось повторно столкнуться; какого рода элементы вы ищите долго и почему. Возможно, это происходит из-за того, что Вы бы написали определенный фрагмент кода иначе, или не до конца ясна логика. В любом случае, надо действовать исходя из осознания того, что работа с кодом — уже Ваша задача, а не того, кто первым его написал.

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

Решения многих задач ждут Вас в сетях интернета, и поиск их занимает не так много времени, как кажется может показаться на первых порах.

Приятно воспользоваться благами обычных блокнотов. Например, CTRL + G (поиск по номеру строки) и прочие удобности, что значительно экономит время.

Работая с кодом желательно оставлять комментарии. Со временем они приобретут лаконичную форму и будут размещены в нужном месте. Это облегчает работу не только Вам, но и другим коллегам.
Приблизительно в середине работы над изменением кода для небольшой разгрузки можно просмотреть его на содержание синтаксических ошибок.

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

Когда уходите на перерыв или домой, просмотрите что необходимо еще сделать. Когда перед Вами не будет кода и в памяти будет «висеть» задача, Вы заметите появление свежих оригинальных мыслей, даже если не будете намеренно думать о способе решения. Особенно такой прием подходит для сложных задач. Не говоря о пустяковых, конечно.

Читайте также: