Как читать чужой код? Часть 1. Общие вопросы. Доработка чужого кода. Code review

31.07.22

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

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

 Сразу напишу вопросы, которые в статье не будут рассматриваться:

1. Разбор и отладка правил конвертации

2. Отладка фоновых заданий. 

3. Отладка асинхронных вызовов.

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

 

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

В моей практике чужой код необходимо читать в следующих ситуациях:

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 минут!

	//Запрос к справочнику сотрудники
	ВыборкаПоСотрудникам = Запрос.Выполнить.Выбрать();

	//В таблицу помещаем данные табельного учета за месяц.
	//Получается более 100 тыс записей
	ТаблицаТабеля = Новый ТаблицаЗначений;

	//В цикле необходимо подобрать ссылки для подразделений и сотрудников, 
	//т.к. данные получены через COM есть только строковые значения.
	Для Каждого ТекСтрока Из ТаблицаТабеля Цикл
		ВыборкаПоСотрудникам.Сбросить();
		Если ВыборкаПоСотрудникам.НайтиСледующий(СтруктураПоиска) Тогда
			...
		КонецЕсли;
	КонецЦикла;

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

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

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

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

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

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

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

 

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

 

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

Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации.

Часть 3. Разбор и доработка запросов

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

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

 

Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:

1. Кто такой архитектор. Редакция 2!

2. Пример работы с файлами odt в клиент-серверной модели работы

3. Использование ПоказатьВопрос() в событии НачалоВыбора()

Чужой код чтение кода доработать чужой исправить оптимизация проверка помощь разработка запрос программный интерфейс

См. также

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

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

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

18.03.2024    1147    ZhokhovM    2    

4

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

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

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

18.03.2024    2672    ZhokhovM    4    

8

Реструктуризация - бесконечная история

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

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1909    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

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

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

27.09.2023    6966    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

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

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

19.09.2023    4345    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

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

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

10.08.2023    9584    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

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

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3033 20.09.21 10:32 Сейчас в теме
2. biimmap 1827 20.09.21 10:32 Сейчас в теме
(1) Да не прошло и году) Всего 1,5 месяца
3. starik-2005 3033 20.09.21 10:33 Сейчас в теме
(2) сохранил себе, почитаю на досуге.
4. Steelvan 302 20.09.21 11:10 Сейчас в теме
Ага, а потом придет следующий программист и весь ваш код тоже удалит и напишет свой, тоже считая свой подход единственно правильным.

Ты 1Сник, это твоя судьба почти всегда работать с чужим кодом. Без разницы, это код типовых конфушек от 1С или самописки.
В 1Сники идут добровольно, так что жуйте свой кактус :)
siamagic; Andreeei; dehro; SerVer1C; so-quest; +5 Ответить
6. ivanov660 4330 20.09.21 11:41 Сейчас в теме
(4)Если код хороший (качественный), то вряд ли он будет переписан. Если только этому программисту платят за количество строк, а так ему скорее всего будет лень переписывать и они приткнет где-нибудь свой костыль.
sturamironova; RickyTickyTok; biimmap; +3 Ответить
8. biimmap 1827 20.09.21 11:55 Сейчас в теме
(4) Так картинка то специально подобрана под статью))) А статья чтоб не удаляли код! А грамотно модифицировали!
5. smit1c 106 20.09.21 11:25 Сейчас в теме
(4) это судьба всех программистов.
morin; Bassgood; ubnkfl; +3 Ответить
7. ivanov660 4330 20.09.21 11:43 Сейчас в теме
Статья годная, мне нравится когда делятся результатами, своим опытом, особенно если он большой.
9. AntonProgma 46 20.09.21 13:47 Сейчас в теме
Свой код становится чужим через некоторое время.
Ryo3000; Vlan; chiki-79; Andreeei; Stref75; albert.goncharov; RickyTickyTok; Drivingblind; Bassgood; anton-1981@yandex.ru; mark_iz; sanches; biimmap; +13 Ответить
11. biimmap 1827 20.09.21 14:31 Сейчас в теме
(9) Да бывает смотришь на давно написанное и не помнишь как и почему. А иногда думаешь, чё за говнокодер это писал))))
chiki-79; I_r_a; Stref75; Bassgood; +4 Ответить
10. QuickMix 20.09.21 14:04 Сейчас в теме
Во всех вакансиях есть требование - умение читать чужой код.

Всегда считал такое требование, и вообще его формулировку - странным. Ещё не встречал 1Сника, который бы работал только со своим кодом, и всё бы писал с нуля. Как минимум приходится работать с кодом типовых конфигураций. Этот самый код типовых конфигураций тоже является "чужим", только если ты не пишешь типовые.

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

Тогда корректно формулировать это требование так:
Умение читать корявый код, который написан по принципу "главное чтобы работало".

А некоторые наоборот дорабатывают типовые так, что код от типового не отличить (в хорошем смысле. Я понимаю, что код типовых далеко не идеален). Тогда код хоть и чужой, и не типовой, и если он написан также, как в типовых, то умение "читать чужой код" можно отключать.
12. biimmap 1827 20.09.21 14:33 Сейчас в теме
(10) У меня описаны все кейсы, и с типовой и нет. В статье они разделены, т.к. действительно написаны лишь бы работало)))
Работают то все, но время на разбор чужого кода у всех разное. Я его читаю просто как книгу, а кто-то неделю разбирает запрос. Вот статья нужна чтоб прокачать эту компетенцию!
13. hiduk 124 20.09.21 14:38 Сейчас в теме
Когда, в конце концов, вместо требования "умение читать чужой код" будет выдвигаться другое, например: "умение писать свой код так, чтобы его могли прочесть другие"?
ShiningPhoenix; nekit_rdx; EvgeniyOlxovskiy; biimmap; +4 Ответить
16. biimmap 1827 20.09.21 14:43 Сейчас в теме
(13) В моей статье много раз говорится про стандарты разработки. А вот про соблюдение стандартов разработки уже многие пишут в вакансиях. Есть ощущение, что именно это поможет писать так, чтоб другие могли прочитать)
EvgeniyOlxovskiy; +1 Ответить
43. RustIG 1351 22.09.21 09:16 Сейчас в теме
(13) доработка типовых и сдача на спеца - это как раз "умение читать чужой код" - для адаптации типовой конфигурации
44. Bassgood 1425 23.09.21 19:56 Сейчас в теме
(43)
сдача на спеца

Это ж где там требуется читать чужой код?
Спец по платформе - пишешь мини-конфу с "нуля", спец по конфам - минимальное вмешательство в определенные участки конфы
45. biimmap 1827 23.09.21 20:40 Сейчас в теме
(44)
минимальное вмешательство в определенные участки конфы

т.е. их читать не надо? вслепую вмешиваетесь?
46. Bassgood 1425 23.09.21 20:48 Сейчас в теме
(45) Я к тому, что они довольно очевидны, и реального копания по множеству модулей и разбора логики работы алгоритмов путем чтения тысяч строк кода практически не требуется
47. biimmap 1827 23.09.21 21:03 Сейчас в теме
(46) Вы знаете, я вот 14 лет назад спеца сдавал... И вот совсем не было очевидно)))

В целом статья предназначена для начинающих или середнячков. С трудом верю, что профи могут найти в ней полезное что-то. Разве что для профи моя статья как чек-лист - убедиться, что да эти навыки есть))
14. Steelvan 302 20.09.21 14:40 Сейчас в теме
Эта публикация https://infostart.ru/public/1518811/ оприлюднена сразу после вашей.
Автор решил вас немного потроллить и все ваши случаи обзора и правки кода :)
17. biimmap 1827 20.09.21 14:45 Сейчас в теме
(14) честно не вижу связи между статьями... ссылок на мою нет.
15. Steelvan 302 20.09.21 14:41 Сейчас в теме
(13) ...чтобы его могли прочесть другие...

Смотря какой уровень опыта у "других".
Наверное правильнее "Умение писать код в соответствии с требованиями 1С к оформлению кода".
Bassgood; +1 Ответить
18. flex81 66 20.09.21 15:02 Сейчас в теме
Прикольно. Моделирование не используют чтобы логику кода понять?
19. biimmap 1827 20.09.21 15:04 Сейчас в теме
(18) В каком-то слове у Вас опечатка. Из-за этого вопрос непонятен...

Но предполагаю, что речь идёт про составление сценариев. Об этом почти в каждом кейсе идёт речь! Пару раз подчеркнуто, что сценарий - основа для разработки.
33. flex81 66 21.09.21 13:47 Сейчас в теме
(19)а в чем составляите сценарии?
34. biimmap 1827 21.09.21 13:50 Сейчас в теме
(33) Наверно в ответ хотите услышать модные программки... Но нет я ими не пользуюсь. Итог в презентациях.
37. flex81 66 21.09.21 14:06 Сейчас в теме
(34)тоесть презентации в point делаете для разбора кода?
EvgeniyOlxovskiy; +1 Ответить
38. biimmap 1827 21.09.21 14:09 Сейчас в теме
(37) нет конечно) если реально нужны описанные сценарии, мне достаточно пару схем от руки в тетради... А вот если надо заказчику отдать описание, тогда перевожу это в презентацию.

Например, вот была задача из 2.5 обработку переделать в 3.1. Обработка 4000 строк и их было 3 почти одинаковых. Вот тут пришлось порисовать)

В итоге получился конструктор выгрузки данных из ЗУП 3 в Excel.
41. flex81 66 21.09.21 14:56 Сейчас в теме
(38)понял, спасибо за статью
42. biimmap 1827 21.09.21 14:57 Сейчас в теме
(41) Пользуйтесь на здоровье)
35. biimmap 1827 21.09.21 13:56 Сейчас в теме
(33) ещё добавлю, важно не ГДЕ, важно ЧТО и с каким качеством! Потому как сейчас много модных программ, в которые вписывают откровенную чушь! Процесс производства чуши для клиента выглядит невероятно красиво.

Но результата от этого не будет, пока написанное не перестанет быть чушью)
EvgeniyOlxovskiy; +1 Ответить
20. пользователь 20.09.21 17:14
Сообщение было скрыто модератором.
...
21. AntonProgma 46 20.09.21 18:45 Сейчас в теме
Чужой код нужно читать от начала выполнения слева направо, сверху вниз. Ошибки в алгоритме исправлять. Текст выравнивать. Если можно написать понятнее, переделываешь. Если и так понятно, оставляешь. Ускорением занимаешься, там, где тормозит. Переменные объявляешь там, где используешь. Функции и процедуры делаешь специализированными. Повторяющийся код выносишь "за скобки". Думай о здравом смысле, а не стандартах 1с. Остальное - вкусовщина.
36. biimmap 1827 21.09.21 13:58 Сейчас в теме
(21) Коллега. а как Вы относитесь к SonarQube? Тоже вкусовщина?

Что касается "и так понятно"... Очень мало кода есть, который мне непонятен) Но это не повод его оставлять в исходном состоянии!
EvgeniyOlxovskiy; +1 Ответить
39. AntonProgma 46 21.09.21 14:22 Сейчас в теме
(36) не имею мнения на счёт сонаркьюба, не пользовался. Стандартизация, конечно, желательна в сообществе. Ничего не имею против. Но как быть, если стандарт противоречит здравому смыслу? Или аргументированно лучшее решение идёт в разрез с привычным большинству подходом?
40. biimmap 1827 21.09.21 14:25 Сейчас в теме
(39) Никто не запрещает осознанно нарушать правила, особенно когда это приносит плюсы, например, в производительности! В статье про разбор запросов написал про то, что можно нарушать стандарты... в рамках статьи рассматривать не стал, т.к. нарушение стандартов это уже актуально для самых опытных коллег.
EvgeniyOlxovskiy; +1 Ответить
22. starik-2005 3033 20.09.21 22:09 Сейчас в теме
Статья в принципе нормальная. Сегодня как раз показывал код (code review), но на С++ (в основном STL, кода немного, он четко разделен на блоки - внешняя компонента для стресс-теста методом Монте-Карло), поэтому 99% вопросов были по С++, а не по компоненте ))) Все хотят разобраться, но боятся подступиться.

Да, я тоже пишу подобную статью. Фактически это будет статья про тот самый Code Review, отделенный от языка и 1С в принципе. Т.е. этакий TRUE-скилл будет рассматриваться. Надеюсь у меня на это хватит воли )))

-- При выборке данных часто встречается Запрос.Выполнить().Выгрузить() и дальше обрабатывается таблица. Зачем? Необходимо использовать выборку из результата запроса.
Был уже на эту тему срач, который кончился тестированием, в котором загрузить-выгрузить работало быстрее. Более того, обход цикла по выгруженной таблице был быстрее, чем обход с помощью выборки. 1С тоже не дураки пишут - источник для цикла ровно один раз исполняется, данные таблицы кешируются. Да, когда трава была зеленой, деревья большими, а памяти не хватало, то такой подход (типа map-reduce) был оправдан, но сейчас результат выборки для заполнения ну в лучшем случае пары тысяч строк - экономить тут сто килобайт памяти совершенно необосновано, при том в скорости обход с помощью выборки проиграет.
24. ltfriend 954 20.09.21 22:33 Сейчас в теме
(22)
Необходимо использовать выборку из результата запроса.

Могу подтвердить из собственного опыта, что на нескольких миллионах записей замена "Выбрать.Следующий()" на "ТЗ = РезультатЗапроса.Выгрузить() ... <Выборка из ТЗ>" сократило время выполнения с нескольких минут до пары десятков секунд.
p.s. Выражение типа "Запрос.Выполнить().Выгрузить()" довольно широко используется в современных типовых конфигурациях.
26. biimmap 1827 20.09.21 22:44 Сейчас в теме
(24) Тут далеко ходить не надо. конфигурацию ЗУП берем, смотрим Менеджер расчета зарплаты. Его в хлам переписали с запросов на таблицы) Честно говоря ускорение я не заметил))) Но переписали знатно. Видать скучно было
28. starik-2005 3033 20.09.21 22:55 Сейчас в теме
(26)
Честно говоря ускорение я не заметил)))
Чтобы заметить ускорение, нужно взять и измерить. Они одно переписали на побыстрее, другое - замедляющее - добавили.
25. biimmap 1827 20.09.21 22:43 Сейчас в теме
(22) С выборкой я там описал один прикол... Что Выборка.Сбросить() + Выборка.НайтиСледующий() ну очень долго работает.
23. ltfriend 954 20.09.21 22:27 Сейчас в теме
2. Если так случилось, что нет ни описания, ни носителя знаний - надо запускать в пользовательском режиме и пробовать использовать доработку.

Действительно, зачем изучать код, когда "метод тыка" ни кто не отменял.
27. biimmap 1827 20.09.21 22:45 Сейчас в теме
(23) Это сейчас молодёжь разбалованная... А мы всё изучали так)))
29. biimmap 1827 20.09.21 23:00 Сейчас в теме
Коллеги, ко всем предложение - изучайте все 4 статьи) Эта часть вводная. Самое интересное дальше. И плюсы ставьте всем статьям)
30. starik-2005 3033 20.09.21 23:51 Сейчас в теме
(29)
И плюсы ставьте всем статьям)
А нельзя так вот сразу плюсы всем статьям поставить - инфостарт запрещает это делать. Надо было статьи по очереди выкладывать, а не все чохом.
31. biimmap 1827 21.09.21 00:47 Сейчас в теме
(30) каждые 5 минут можно))) Это одна статья просто публикации 4. выложить одну как то не очень мне кажется
32. starik-2005 3033 21.09.21 10:15 Сейчас в теме
48. user1196762 24.09.21 11:13 Сейчас в теме
Хорошая статья. Сохраню себе.
49. AnryMc 849 01.10.21 08:37 Сейчас в теме
Как читать чужой код?

Очень просто: Сверху - вниз и справа - налево...
Остальное зависит только от "маразматичности" этого кода и твоего понимания предметной области задачи...
QuickMix; +1 Ответить
50. Nubsdale 12.10.21 09:51 Сейчас в теме
5. Не стесняйтесь непонятные вопросы задавать на форумах. Даже если Вас обольют 10 человек грязью, всегда найдётся один, который поможет!

Очень жизненно, статье плюс
51. biimmap 1827 12.10.21 10:05 Сейчас в теме
52. strelec13 20 18.10.21 09:57 Сейчас в теме
Интересно, а разбираться в типовом коде можно понимать как чужой код? Как пример. Давно не обновляли конфигурацию или устарела. Конечно проще обновить, если позволяет компетенция обновлять устарелые или запущенные релизы. А если нет такого опыта или нет необходимости обновлять и в целом устаривает, то приходится разбираться в этом теперь уже "чужом коде". Или более распространенный пример. Всем приходится разбираться в "чужом коде", когда мы чтото меняем в типовом коде, чаще всего такое бывает при работе в расширении. Спасибо автору в том, что его советы и рекомендации как работать с чужим кодом, так же можно применить и в работе с типовым кодом.
53. biimmap 1827 18.10.21 10:59 Сейчас в теме
(52) про типовой код дальше кейс описан, и про обновление тоже. Наверно ещё не читали... кейсов всего 7 описано в 4-х статьях
54. herres 20.10.21 14:01 Сейчас в теме
а мне вот не нравится типовой код.
Я считаю, что длинна названий должна кореллировать с частотой и специализированным характером.

т.е. функции БСП должны были бы называться максимально коротко и модули БСП должны были иметь короткие названия (пусть из 3х символов !)

т.к. это базовый словарь и он должен быть удобным. Для себя же делаем, для человеков !

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

Тоже к именам переменных.
Если переменная объявлена и единственный раз использована на следующей строке - ну не должна она быть длинной. Это мешает чтению
56. biimmap 1827 20.10.21 14:17 Сейчас в теме
(54) Это к Нуралиевым) С некоторыми тезисами (количество функций) я согласен. но имена сам пишу длинные, чтоб потом легче вспомнить было что и зачем делал. Потому что иногда переменная встречается пару раз, но от неё всё зависит)
55. herres 20.10.21 14:05 Сейчас в теме
Типовой код очень водянистый и перегружен недостаточно универсальными функциями.

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