Как найти неиспользуемый код

03.08.20

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

Описание нескольких способов поиска и определения неиспользуемого кода

Легаси он везде

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

  • Использование устаревших возможностей платформы
  • Дублирование кода в ходе разработки (особенно командной)
  • Появление неиспользуемого кода отдельных процедуры и функций, так и целых модулей
  • Появление "мертвого" кода в ходе обновления типовых конфигураций, когда разработчик решает не удалять старые процедуры, т.к. он их использовал в своих решениях.
  • И много чего еще.

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

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

Зачем вообще этим заниматься

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

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

Очистка кода от неиспользуемых процедур и функций или целых модулей необходимо только:

  1. Вы на поддержке и регулярно устанавливаете типовые обновления. При этом в общих модулях от поставщика почему-то не удалили процедуры и функции предыдущих релизов, хотя по факту они не используются в свежих версиях конфигурации. Да, они могут использоваться в самописных модулях или внешних отчетах / обработках, но возможно это повод их отрефакторить и привести к актуальному виду.
  2. В конфигурации огромный объем кода, который вроде бы никто не использует, но он остался с давних времен. Может с этапа внедрения какой-нибудь подсистемы или более глобальных событий. В любом случае, со временем появится путаница какие процедуры и функции стоит использовать и сопровождать, дорабатывать, а какие нет. 
    • Сталкивался с такими запущенными решениями. Очень часто можно было встретить такое поведение разработчиков: никто не знает что это за функция, где она используется и можно ли ее вообще изменять. Поэтому я добавлю новую! Со своими фичами и багами! :) Думаю, Вы понимаете к чему это потом приводит...
  3. Вы делаете тиражируемое решение и внутренне качество должно быть на уровне. С появлением неиспользуемых модулей в таком решении его сопровождение может стать проблемным. Как для Вас, так и для клиентов из-за нескончаемого потока багов...

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

От простого...

Допустим, из-за причин выше у Вас появилась необходимость удалить процедуру / функцию из конфигурации или внешних отчетов / обработок. У Вас могут быть и другие причины :) В любом случае, нам уже известен модуль, где располагается эта процедура / функция, названия метаданных и содержимое этого модуля. Как действовать дальше?

Метод "На продакшене все и узнаем"

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

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

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

Мы этот вариант особо описывать не будем, ведь с ним и так все понятно. Надеюсь что эти "bad practice" Вы не используйте вне зависимости от масштаба информационной системы / базы.

Метод "Ручной поиск"

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

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

А вот так выглядит поиск по файлам внешних отчетов и обработок. Заметите знакомые обработки, попавшие в поиск? :)

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

Например, если нужно найти где используется функция "ТолькоЦифрыВСтроке" из общего модуля "СтроковыеФункцииКлиентСервер", то в глобальном поиске лучше использовать следующее значения поиска:

  • "СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке(" - то есть полный путь к вызову функции.
  • ".ТолькоЦифрыВСтроке(" - только имя функции.

Поиск по полному имени не всегда может помочь, если в коде используется что-то вроде этого:

// ...
СтроковыеФункцииКлиентСервер
	.ТолькоЦифрыВСтроке(
// ...

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

Модуль = ОбщегоНазначения.ОбщийМодуль("СтроковыеФункцииКлиентСервер");
Если Модуль <> Неопределено Тогда
	Результат = Модуль.ТолькоЦифрыВСтроке(КакоеТоЗначение);
КонецЕсли;

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

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

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

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

Метод "Добавить метку"

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

РезультатПроверки = СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке(ИсходнаяСтрока);

Содержимое функции, которое я взял из "Библиотеки стандартных подсистем", выглядит так:

// Проверяет, содержит ли строка только цифры.
//
// Параметры:
//  Значение         - Строка - проверяемая строка.
//  Устаревший       - Булево - устаревший параметр, не используется.
//  ПробелыЗапрещены - Булево - если Ложь, то в строке допустимо наличие пробелов.
//
// Возвращаемое значение:
//   Булево - Истина - строка содержит только цифры или пустая, Ложь - строка содержит иные символы.
//
// Пример:
//  Результат = СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке("0123"); // Истина
//  Результат = СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке("0123abc"); // Ложь
//  Результат = СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке("01 2 3",, Ложь); // Истина
//
Функция ТолькоЦифрыВСтроке(Знач Значение, Знач Устаревший = Истина, Знач ПробелыЗапрещены = Истина) Экспорт
	
	Если ТипЗнч(Значение) <> Тип("Строка") Тогда
		Возврат Ложь;
	КонецЕсли;
	
	Если Не ПробелыЗапрещены Тогда
		Значение = СтрЗаменить(Значение, " ", "");
	КонецЕсли;
		
	Если СтрДлина(Значение) = 0 Тогда
		Возврат Истина;
	КонецЕсли;
	
	// Если содержит только цифры, то в результате замен должна быть получена пустая строка.
	// Проверять при помощи ПустаяСтрока нельзя, так как в исходной строке могут быть пробельные символы.
	Возврат СтрДлина(
		СтрЗаменить( СтрЗаменить( СтрЗаменить( СтрЗаменить( СтрЗаменить(
		СтрЗаменить( СтрЗаменить( СтрЗаменить( СтрЗаменить( СтрЗаменить( 
			Значение, "0", ""), "1", ""), "2", ""), "3", ""), "4", ""), "5", ""), "6", ""), "7", ""), "8", ""), "9", "")) = 0;
	
КонецФункции

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

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

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

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

Функция ТолькоЦифрыВСтроке(Знач Значение, Знач Устаревший = Истина, Знач ПробелыЗапрещены = Истина) Экспорт
	
	#Если Сервер Тогда
		
	ЗаписьЖурналаРегистрации("АнализКода.ПроверкаИспользования",
		УровеньЖурналаРегистрации.Информация,,,
		"Выполнен вызов функции СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке");
		
	#КонецЕсли
	
	// тут продолжение функции ...
	
КонецФункции

Если же использовать подсистему "Оценка производительности", то сохранение информации о вызове можно сделать так:

Функция ТолькоЦифрыВСтроке(Знач Значение, Знач Устаревший = Истина, Знач ПробелыЗапрещены = Истина) Экспорт
	
	#Если Клиент Тогда
		
	УИДЗамера = ОценкаПроизводительностиКлиент.ЗамерВремени("Использование_НаКлиенте_СтроковыеФункцииКлиентСервер_ТолькоЦифрыВСтроке",Ложь,Ложь);
	ОценкаПроизводительностиКлиент.ЗавершитьЗамерВремени(УИДЗамера, Ложь);
		
	#ИначеЕсли Сервер Тогда
		
	НачалоЗамера = ОценкаПроизводительности.НачатьЗамерВремени();
	ОценкаПроизводительности.ЗакончитьЗамерВремени("Использование_НаСервере_СтроковыеФункцииКлиентСервер_ТолькоЦифрыВСтроке", НачалоЗамера);
		
	#КонецЕсли

	// тут продолжение функции ...
	
КонецФункции

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

Через некоторый период времени проверяем собранную информацию, анализируем были ли вызовы и как часто. Остается вопрос: а кто вызвал и откуда? Если посмотреть предыдущие события журнала регистрации или добавить дополнительную информацию в собираемый лог (например, можно получить стэк вызовов программно, но это может привести к замедлению работы). Но можно поступить иначе и использовать следующий подход для выявления факта использования программного кода.

Метод "У меня все в логах записано"

И тут нам на помощь приходит, барабанная дробь, технологический журнал! Для получения информации о вызове функции "ТолькоЦифрыВСтроке" настроим сбор ТЖ с помощью следующей настройки:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
 <dump create="false"/>
 <log location="F:\Logs1С\" history="168">
  <event>
   <eq property="name" value="scall"/>
   <like property="context" value="%СтроковыеФункцииКлиентСервер%ТолькоЦифрыВСтроке%"/>
  </event>
  <property name="all"/>
 </log>
</config>

Делаем отбор событий исходящего удаленного вызова (SCALL) с отбором по контексту (context). В контексте как-раз и хранится стэк вызовов. В результате в ТЖ будут попадать следующие события:

45:59.073005-1,SCALL,5,process=rphost,p:processName=trade_11_4,OSThread=16444,t:clientID=354,t:applicationName=1CV8C,
t:computerName=YY-COMP,t:connectID=30,SessionID=2,Usr=Администратор (ОрловАВ),AppID=1CV8C,DBMS=DBMSSQL,
DataBase=YY-COMP\trade_11_4,ClientID=362,Interface=b3711610-b248-42aa-a215-5d7150a5f7fd,
IName=IClusterMiscUtils,Method=0,CallID=1893457,MName=isItTimeToGetLocks,DstClientID=3062,
Context='
Форма.Вызов : ВнешняяОбработка.ПроверкаИспользованияКода.Форма.Форма.Модуль.ВызватьНаСервереНаСервере
    ВнешняяОбработка.ПроверкаИспользованияКода.Форма.Форма.Форма : 9 : ТестВызова();
        ВнешняяОбработка.ПроверкаИспользованияКода.Форма.Форма.Форма : 32 : Результат = СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке("231313А");
            ОбщийМодуль.СтроковыеФункцииКлиентСервер.Модуль : 359 : НачалоЗамера = ОценкаПроизводительности.НачатьЗамерВремени();
                ОбщийМодуль.ОценкаПроизводительности.Модуль : 21 : Если ОценкаПроизводительностиВызовСервераПовтИсп.ВыполнятьЗамерыПроизводительности() Тогда
                    ОбщийМодуль.ОценкаПроизводительностиВызовСервераПовтИсп.Модуль : 19 : Возврат Константы.ВыполнятьЗамерыПроизводительности.Получить();'

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

Но для клиентского приложения поиск вызовов отловить сложнее. Событие "SCALL" также может быть отловлено на стороне клиента, но стэк вызовов формируется несколько иначе. В нем нет явной информации о вызове функции "СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке" как на стороне сервера. Вместо этого в стэке присутствует программный клиентский код, влияющий на вызовы. Надежного способа поиска выполнения кода на клиенте я так и не нашел, но радует что клиентская часть чаще всего не является проблемой.

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

Вместо заключения

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

  • Проверка на пользователях. Самый ужасный способ :)
  • Глобальный поиск по конфигурации, расширениям и файлам внешних отчетов и обработок.
  • Через добавления записи события в лог при вызове кода и последующий анализ собранных данных.
  • И в конце рассмотрели вариант с использованием технологического журнала.

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

  1. Сначала ищем использование с помощью глобального поиска и изменяем / удаляем код там где найдем.
  2. Добавляем запись метки в лог при вызове анализируемого кода.
  3. Если вызовы до сих пор остаются и не удается найти откуда именно они выполняются, то задействуем технологический журнал.

Анализ полученных данных можно выполнять инструментами, которые Вы привыкли использовать. Мой набор это:

На этом все.

А как Вы решаете подобные задачи? Добро пожаловать в комментарии, если есть что дополнить.

Другие ссылки

  • К сожалению, похожих публикаций не заметил. Дайте знать истину в комментариях :)

Авторские разработки

 
 Другие разработки (8 штук, бесплатные и за $m)

Поиск код рефакторинг реинжениринг качество легаси

См. также

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

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

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

18.03.2024    1149    ZhokhovM    2    

4

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

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

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

18.03.2024    2675    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    6968    Lemmonbri    136    

36

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

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

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

19.09.2023    4346    Lemmonbri    16    

31

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

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

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

10.08.2023    9586    0    1c-izhtc    37    

21

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

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

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

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Evg-Lylyk 4559 03.08.20 10:48 Сейчас в теме
Познавательно конечно, но все предложенные методы не очень.
Тема востребованная, думаю это должно решатся инструменты типа АПК, SonarCube
3. пользователь 03.08.20 11:01
(1) как активный пользователь JetBrains Resharper мне очень не хватает подобного для разработки на платформе 1С.
У меня есть мечат, что что-то подобное появиться и в "желтой" экосистеме. Это было бы намного лучше SonarCube, потому что применялось бы в активной фазе процесса разработки, а не после коммита в репозиторий.

Но так да, это все олдскульные способы проверки.
Плюс Сонар, АПК никак не помогут, если код для анализа в правилах конвертации или приходит из другой системы как в примере из статью. Но это никак не уменьшает значимости его использования!
2. VKislitsin 960 03.08.20 10:58 Сейчас в теме
Юрий, по названию статьи я предположил, что речь пойдет о том как обнаружить неиспользуемый код - возможно об альтернативе функционалу Конфигуратора "Проверка конфигурации" с установленным флажком " Поиск неиспользуемых процедур и функций".
В статье же описано как проверить что некий метод действительно нигде не используется. Подскажите, как всё же Вы находите те методы, которые затем проверяете на использование описанными способами?
CratosX; a_a_burlakov; Дмитрий74Чел; artbear; SagittariusA; user1147832; YPermitin; CyberCerber; tormozit; +9 Ответить
4. пользователь 03.08.20 11:03
(2) обычно это такие случаи:

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

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

Осторожность, паранойя...
5. tormozit 7136 03.08.20 11:13 Сейчас в теме
(2) Я тоже испытал подобное чувство после прочтения. Думаю стоит изменить название статьи.
CratosX; Дмитрий74Чел; artbear; YPermitin; +4 Ответить
6. пользователь 03.08.20 11:14
(5) предлагайте варианты.

Возможно исправлю, но не сразу. Голосование! :)))
28. CratosX 112 13.02.22 06:57 Сейчас в теме
(6) вам же уже предложили, добавить слово "проверить" в заголовок: Как проверить, используются ли функции и процедуры в коде.
7. CyberCerber 852 03.08.20 11:45 Сейчас в теме
Тоже ожидал увидеть либо, что есть поиск в конфигураторе при проверке конфигурации, либо предупреждение "на лету" в EDT
artbear; YPermitin; +2 Ответить
8. sapervodichka 6697 03.08.20 11:57 Сейчас в теме
У меня концепты такие: 1) Если функционал легко обновляемый, даже если не работающий, то его не нужно трогать (пусть будет и будет законсервирован, иначе можно удалить из благих намерений и сломать программу). 2) Если функционал не нужный и сложно обновляемый, то при переходе на новый релиз вы его и удалите и проверите работоспособность. 3) Если функционал не нужный и ресурсоемкий, то вы его вычислите после жалоб на медленную работу и отключите. =))) А вот прям чтобы сидеть и выискивать ненужный код.... сильно сомневаюсь, что это кому-то нужный оплачиваемый позитив. А вот методы описанные в статье, про подключение к новым доработкам замеров производительности и проверки таким образом частоты вызовов и работоспособности функционала - это очень полезная вещь! +1
SerVer1C; nekit_rdx; shard; zqzq; YPermitin; &rew; +6 Ответить
9. VKislitsin 960 03.08.20 12:47 Сейчас в теме
(8)
ние к новым доработкам замеров производительности и проверки таким образом частоты вызовов и работоспособности функционала - это очень полезная вещь! +1

На мой субъективный взгляд, самый полезный прием из описанных - это с использованием ТЖ. Писать вызовы методов в ЖР или РС ЗамерыВремени мне представляется "засорением", тем более, что еще и требует вставки кода для этого. Но, вероятно, в каких-то случаях и эти способы имеют право на применение.
YPermitin; +1 Ответить
10. sapervodichka 6697 03.08.20 12:55 Сейчас в теме
(9) я имею ввиду новые документы, новые справочники, обработки разрабатываемые в конфе (к аналогичным типовым объектам замеры подключаются и это не является засорением, а является частью APDEX технологии, а вот к новым доработкам их редко подключают, а следовало бы иначе объекты выпадают из APDEX анализов встроенных во все новые конфы)
YPermitin; +1 Ответить
11. VKislitsin 960 03.08.20 13:11 Сейчас в теме
(10)
я имею ввиду новые документы, новые справочники, обработки разрабатываемые в конфе

Дмитрий, Вы как эксперт, полагаю, не забываете добавлять в новый функционал замеры производительности. И уж точно не так как предложено в статье, а по всем правилам: начало как можно раньше, окончание - как можно позже.
Засорением я назвал использование подсистемы не по назначению. Здесь приведено её использование в "побочных" целях. Замер начинается и завершается в одном месте. Если эти записи не удалить из РС ЗамерыВремени, то Ключевая операция "Использование_НаСервере_СтроковыеФункцииКлиентСервер_Только­ЦифрыВСтроке" исказит (приукрасит) показатель APDEX потому что всегда выполняется мгновенно. И чем больше будет таких записей, тем лучше будет выглядеть общий APDEX. Особенно красивым он будет, если вызов СтроковыеФункцииКлиентСервер_ТолькоЦифрыВСтроке найдется в каком-нибудь частом цикле.

Упс, похоже промахнулся веткой. Отвечал Дмитрию на (10)
YPermitin; +1 Ответить
12. sapervodichka 6697 03.08.20 13:18 Сейчас в теме
(11) Виталий, (норм, я увидел) со всем согласен "Нужно делать так как нужно, а как не нужно - делать не нужно", как говорил Винни Пух ))
nekit_rdx; YPermitin; VKislitsin; +3 Ответить
13. PerlAmutor 129 03.08.20 19:24 Сейчас в теме
В сервере не хватает модуля сбора статистики - профайлера, который бы собирал информацию по всем вызовам, в том числе длительность, количество и объемы оперириуемых данных. Чтобы можно было построить "Heat-map" по всему дереву конфигурации с именами функций и методов. Целиком для сервера (на сколько бы кластеров он не был разнесен).

На основе статистики можно было бы собирать динамический вариант конфигурации. Например не выкачивать 1.5Гб ERP из БД и не загружать всю конфигурацию в каждый rphost, а собирать её исходя из используемых участков и объектов метаданных и дополнять в процессе использования. Тоже самое и для пользовательского кэша. Обновили конфигурацию - проверили контрольные суммы объектов метаданных, увидели изменения - скачали только недостающее.
nekit_rdx; bulpi; AlexKo; sapervodichka; YPermitin; +5 Ответить
14. sapervodichka 6697 04.08.20 01:23 Сейчас в теме
(13) Влад, прив, мысль Агонь! (всё по делу)
YPermitin; +1 Ответить
15. makfromkz 35 04.08.20 14:27 Сейчас в теме
В типовой разве нет в конфигураторе проверки модулей конфигурации?
ByNiko1984; +1 Ответить
16. ByNiko1984 05.08.20 08:49 Сейчас в теме
(15) статья о другом. Про практику больше. Хотя заголовок немного может обманывать
17. tormozit 7136 05.08.20 09:12 Сейчас в теме
Еще замечание. Авто анимация - не всегда хорошо. В данной статье ярко прочувствовал, как она отвлекает и мешает читать текст. Даже если она показывает что то очень полезное, оно очень быстро становится запомненным и потом только мешает. Снова призываю вместо авто анимации делать видео, чтобы при чтении текста GIF-анимация не отвлекала. А вот когда уже я захочу посмотреть видео, я нажму, посмотрю, остановлю его и буду спокойно читать дальше. К тому же в видео есть пауза - в ряде случаев очень полезна возможность, отсутствующая в авто анимации.
CratosX; VKislitsin; YPermitin; +3 Ответить
18. пользователь 05.08.20 09:24
(17) мне видео наоборот очень не нравится. Это совсем другой тип контента, а анимация проще во всех смыслах. Я подумаю над вышесказанным :)
19. user721756 05.08.20 10:15 Сейчас в теме
Коллеги, пожалуйста, расставьте запятые - текст читается с большим трудом и в режиме "угадайка". Казнить нельзя помиловать.
YPermitin; +1 Ответить
20. пользователь 05.08.20 10:36
(19) ок, перепроверю вечером, поправлю :)
21. kosmo0 107 07.08.20 09:16 Сейчас в теме
Три месяца проверки на использование - с моей точки зрения автор очень оптимистичен.

Обычно делал так :
- потенциальный код на удаление комментировал (обязательно дата когда код закомментировали, сообщение программисту почему закомментировали, и срок через который это все можно удалить - уважайте программиста который, возможно, будет работать после вас),
- вставлял команду на запись в журнале регистрации,
- ОБЯЗАТЕЛЬНО УВЕДОМЛЕНИЕ ПОЛЬЗОВАТЕЛЮ что обработка данных не будет выполнена и что он ДОЛЖЕН СООБЩИТЬ ОБ ЭТОМ в такой-то отдел (можно даже телефон или мыло указать).

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

Пользователь по сообщению сразу понимает что делать - иначе есть варианты что начнут мудрить с программой и терять свое время (опять же - в отчетный период оно ценно).

Можно держать список таких удаляемых фрагментов, можно при очередном обновлении увидеть "ненужный" кусок кода, определить сколько времени пользователи не применяли данный код (заодно прошерстить журнал регистрации на сообщения) - если не использовалось более года удалить.
Дмитрий74Чел; YPermitin; +2 Ответить
22. пользователь 07.08.20 09:19
(21) полностью согласен, 3 месяца это обычный срок. Но бывают и места в коде, где год и более. Если знаешь конфигурацию, то примерно представляешь где и в какой срок проверять.

Но иногда и год может не помочь, к сожалению (:
23. It-developer 24 07.08.20 13:25 Сейчас в теме
Я писал лет 5 назад обработку по удалению неиспользуемого. Неиспользуемый искал через конфигуратор ("Проверка конфигурации" с установленным флажком " Поиск неиспользуемых процедур и функций"). Из того что написано в статье более-менее это ТЖ, но когда-то был негативный опыт работы с ним поэтому тоже минус, все остальное - очевидно. Я думал будет какой-то "умный" поиск, который будет анализировать код
24. tezin 574 26.10.20 12:33 Сейчас в теме
YPermitin, проверка с флажком "Поиск неиспользуемых процедур и функций" не анализирует экспортные методы общих модулей, т.к. видимо считается что данные методы могут вызываться не только внутри самой конфигурации. Что используете для поиска устаревших экспортных методов общих модулей?
user1464234; FatPanzer; +2 Ответить
25. FatPanzer 26.10.20 12:39 Сейчас в теме
(24) Да, понятие "неиспользуемые методы" - довольно-таки скользкое в отношении экспортных.
Поручик; +1 Ответить
26. tezin 574 26.10.20 13:11 Сейчас в теме
(25) ну вердикт "к удалению" в этом случае точно должен человек выносить
но инструментов для поиска этих "подозреваемых" я пока что то не нашел
сейчас свою обработку пилю (уже закончил практически), но может есть что то готовое
27. Поручик 4670 18.01.22 16:12 Сейчас в теме
В хозяйстве всё пригодится. В нашей конфигурации не то что код, остались даже модули и объекты со времён ранних версий, которые давным-давно не используются. Вычищать барахло большого желания нет, так как это потребует реструктуризации баз в нескольких конторах. Оно мне по ночам надо, учитывая, что конторы работают чуть ли не в режиме 24/7?
29. kser87 2438 01.03.22 11:28 Сейчас в теме
Помимо неиспользуемого кода еще могут быть ненужные, устаревшие объекты: справочники, документы, предопределенные данные. Сталкивался также с такими ситуациями:

1) в базе огромное количество проверок на устаревший функционал. Например, настроена дата перехода на новый механизм учета ОС. и в коде повсюду проверки на нее. Закешированы, но все равно их количество огромно и АПДЕКС проседает.

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