Переписывать нельзя рефакторить: перестань бояться легаси‑кода в 1С

Легаси — это когда открываешь модуль, и сразу хочется в отпуск.

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

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

Первая реакция нормального человека — закрыть модуль, сделать глоток крепкого кофе и притвориться, что никогда этого не видел. Вторая — переписать все с нуля: красиво, структурированно, в лучших традициях SOLID.

Но бизнес ждет фичи «еще вчера», времени мало, а система должна работать стабильно. И здесь вступает в игру рефакторинг.

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

PS. Понимаю, тема неоднозначная и вызывает много споров. Готов обсудить: форма для вопросов расположена в конце статьи.

Легаси-код в 1С не пишется: он возникает, когда никто не смотрит.

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

Разберемся, почему это так, и почему это не всегда плохо.

1. Разработка «на выкатить»

В 1С почти всегда работает принцип: «Сделай, чтобы работало. Быстро». И это понятно: мы автоматизируем бизнес, а это живые деньги, и процесс их заработка не должен прерываться из-за мелочей вроде невзлетевшей фичи. Более того, наша работа не генерирует деньги бизнесу напрямую, мы – всегда расходы для компании. Поэтому недовольство заказчиков и фразы вроде «опять не работает» для нас становятся частью рабочего процесса.

Процесс внедрения выглядит примерно так:

• заказчик звонит вечером в пятницу,
• утром в понедельник «уже нужно, чтобы работало»,
• документации нет,
• данные примерные, отчеты — «на глаз»,
• и, конечно, «в типовой не лезть, но чтобы все было как надо».

На фоне этого темпа:

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

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

2. Отсутствие стандартов и культура «как привык»

Внутри одной и той же базы можно найти:

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

Проблема не в том, что 1С плохая. Просто в платформе изначально мало встроенных ограничителей. Можно написать хоть всю бизнес-логику внутри одной формы или функции. Хоть весь модуль написать в одну строку. И платформа не скажет ни слова!

Практический вывод: чтобы не плодить легаси в будущем, начните хотя бы с внутренних стандартов команды или проекта. Это не про бюрократию или формализм ради формализма, а про то, чтобы любой разработчик (включая вас через 3 месяца) мог открыть модуль и быстро понять, что происходит.

С чего именно можно начать:

2.1 Именование переменных и функций

Используйте читаемые логичные имена. Имя переменной или функции должно объяснять, для чего это нужно и что здесь происходит. Хорошие имена = самодокументируемый код.

Плохо: П1, Таб, Проверка().

Лучше: ПараметрыСоединения, ТаблицаНераспределенныхОстатков, ПроверитьЗаполнениеПоля() (подробнее см. в главе 4, пункт 2).

2.2 Структура модулей

Разделяйте код на смысловые блоки. Самое простое: пользоваться для этого предусмотренной Стандартами разметкой кода на области с соблюдением их порядка. Для конфигуратора можно пользоваться шаблонами кода: https://github.com/stasganiev/OnesTemplates. А EDT сам подсвечивает неверное размещение, плюс можно в настройках включить авторазметку модулей.

2.3 Единообразие в порядке объявлений

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

2.4 Принцип DRY (Don’t Repeat Yourself — Не повторяйся)

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

Плохо:

Лучше:

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

3. Монолит на монолите с начинкой из костылей

Одна из самых частых архитектур 1С-систем — это огромный единый модуль, куда слиты и учет, и логистика, и CRM, и API, и магия.

Это удобно… до поры. Потом:

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

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

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

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

• отдельная область ОбработкаСкидок — только расчет скидок;
• область ОбменСCRM — только логика интеграции (возможно, это будет отдельный модуль);
• область Проверки — вся валидация, которая касается оформления;
• область ВспомогательныеПроцедуры — технические рутинные вещи, вроде приведения типов или манипуляций с динамическими коллекциями. Зачастую функции из этой области мигрируют в общий программный интерфейс (см. главу 4, п. 1.1).

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

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

4. Боязнь трогать рабочее

Когда в модуле появляются слова «временно» и «костыль» — это надолго.

Классическая цитата из практики: «Оно вроде работает. Не трогай. Лучше добавь сверху».

Так появляются «обертки», «обходы», «обходы обходов», «если пользователь Иванов, то отключить проверку» — и все это живет в боевом коде. Разработчики боятся сломать что-то критичное, потому что:

• нет тестов;
• непонятно, как повлияет;
• сроки горят.

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

Практический вывод: боязнь менять — это не слабость. Это показатель отсутствия процесса безопасной разработки (контроля версий, тестов, изолированных сред, документации). А зачастую просто нехватка времени на изучение чужого кода. Хотите меньше легаси — сделайте так, чтобы было не страшно править.

Вывод

• Легаси в 1С — это не чья-то вина, а результат естественного давления реальности: сроков, ресурсов, платформы и привычек.
• Если понимать, почему это случается — легче будет не только разобрать этот код, но и не создавать такой же в будущем.

Плохой код, как флирт с тигром. Пока не двигаешься, все нормально.

Плохой код — это не просто некрасиво. Это дорого, рискованно и тормозит развитие. Во многих компаниях отношение к коду примерно такое: «Главное — работает. Остальное не важно». 

И это логично… пока:

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

Плохой код — это не только проблема отдела разработки. Это системная угроза бизнесу. Разберемся по пунктам.

1. Поддержка стоит дороже, чем разработка

Когда код написан абы как, любая доработка превращается в мини-экспедицию:

• нужно полдня, чтобы понять, как работает текущая логика;
• еще полдня, чтобы не поломать случайно соседнюю функциональность;
• и еще полдня на откат и переделку, потому что «что-то пошло не так».

Пример из жизни
Разработчик получил задачу: «В отчете добавить отбор по дате». Идет смотреть. Вместо простой схемы СКД «в один проход» он видит монстрообразную функцию, которую не сразу удалось найти из-за неинформативного имени. А в ней:

• Запрос из временных таблиц, часть из которых собирается из разных общих модулей. Приходится лезть в них и смотреть, нет ли там необходимости добавить отбор по дате? А если эти функции вызываются еще откуда-то? Надо добавить возможность обратной совместимости, а для этого изменить состав параметров как самой функции, так и (возможно) во всех местах, где она вызывается.
• Замысловатая магия с использованием универсальных коллекций, никак не прокомментированная. Часть кода при этом большими фрагментами выделена в отдельные блоки «Если… КонецЕсли», а их вложенность напоминает восхождение на Мачу-Пикчу.
• И все это богато «оптимизировано» несложными коротко-названными переменными, вроде ТТ, ВрСтр, ТемпВремЛок и т. п.

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

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

2. Любое изменение — как операция на живом

Когда код связан десятками невидимых нитей, он становится хрупким. Изменил процедуру в модуле объекта — сломался отчет. Добавил проверку в форму — отвалилась интеграция. Удалил «ненужный» Если — и теперь отчеты печатаются задом наперед. Это состояние, в котором разработчик:

• боится нажимать F5 или F7,
• сохраняет базу перед каждой правкой,
• втайне надеется, что задачу отменят.

Метко сказал один коллега: «Старый код — это как проводка в доме: пока не трогаешь — работает. Начнешь ковырять — все замкнет».

Это как раз тот случай, когда заказчик просит добавить быстренько маленькую фичу, а через неделю удивляется: «Почему так долго/дорого? Там уже все было сделано до тебя, нужно было только это использовать». И вот в этом «только использовать» скрывалась огромная яма проблем.

Практический смысл: хрупкий код — это стресс. Не только для разработчика, но и для бизнеса. Потому что нельзя быстро реагировать на изменения. А в наше время скорость — это конкурентное преимущество.

3. Развитие системы останавливается, число ошибок растет

Плохо структурированный код не масштабируется. Он не дает возможности:

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

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

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

Пример №2

«Ты пофиксил экспорт в Excel? Почему тогда удалились остатки на складе?».

Практический смысл №1: плохой код замедляет развитие продукта. Бизнес не может быстро внедрять новое и проигрывает более гибким конкурентам.

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

4. Новым людям страшно входить в проект

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

Признаки проекта, где код страшный:

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

Практический смысл №1: плохой код снижает привлекательность проекта. Люди не хотят работать в хаосе. Это усложняет найм, адаптацию, масштабирование команды.

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

Вывод

• Плохой код — это не эстетическая проблема. Это бизнес-угроза, и чем дольше его игнорировать, тем дороже это обойдется.
• Чем хуже код, тем выше риск ошибок при малейших изменениях.
• Поэтому рефакторинг — не «лишняя роскошь», а стратегическая инвестиция в устойчивость, скорость и масштабируемость системы.

Рефакторинг — это как хирургия: чуть глубже — и ты уже трогаешь бухгалтерию.

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

Если вы полезли «улучшать код», а в итоге:

• никто не может зайти в базу,
• отвалились отчеты,
• клиенты начали звонить…

…значит, вы не рефакторили, а устроили маленькую катастрофу.

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

Принцип «только вокруг задачи»

Безопасный рефакторинг — как игра в Jenga. Главное: не дергать все сразу.

Допустим, есть задача: «В форме документа добавить фильтр по дате».

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

Рефакторить нужно ровно ту часть, к которой вы прикасаетесь в рамках задачи. Это безопасно, полезно и эффективно.

Если ты пришел чинить кран — не сноси кухню.

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

Используйте «правило поломки»

Перед тем как тронуть старый код, задайте себе 3 вопроса:

1. Я понимаю, как он работает?
2. Я знаю, что произойдет, если он перестанет работать?
3. Я смогу откатить изменения?

Если на один из них ответ «не уверен» — остановитесь, сделайте резервную копию, поищите информацию, проверьте в тестовой базе. Это не трусость, это профессионализм.

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

Идите малыми шагами

Рефакторинг — это марафон, а не спринт. Не пытайтесь исправить весь модуль в одной задаче. Вместо этого:

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

Фишка: делайте это в рамках одного помещения в хранилище (либо одного коммита, если работаете с EDT + Git), рядом с правкой по задаче, в контексте которой находитесь. Тогда изменения легко отследить и проверить.

Пример

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

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

И все! Пусть это будет первым этапом рефакторинга для этого модуля. Определите еще 2-3 момента, которые бросились в глаза, обозначьте их TODO-комментарием, чтобы вернуться на следующей итерации (в рамках другой таски или другому разработчику). Зафиксируйте только эти изменения и возвращайтесь к задаче.

Практический смысл: маленькие улучшения — это единственный устойчивый способ рефакторинга в реальных проектах.

Когда вы:

• выносите кусок кода в отдельную функцию;
• переименовываете переменную;
• выполняете только одно изменение за раз,

вы оставляете за собой чистый след, который:

• легко проверить,
• легко протестировать,
• и, если что, откатить.

Маленький рефакторинг — меньше шансов стать виноватым в пятничном аврале.

Не ломайте «темные зоны»

В каждом проекте есть участки кода, которые никто не трогает. Почему? Потому что:

• никто не знает, зачем они работают,
• когда-то тронули — и пожалели.

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

Практический смысл: старый код можно улучшать точечно. Не лезьте вглубь без плана и без задачи.

Вывод

• Рефакторинг — это не «вперед на амбразуру». Это аккуратная, осознанная работа в зоне, где вы точно знаете, зачем это нужно.
• Так можно навести порядок, не разрушая систему и не становясь причиной ночного релиза.

И запомните: лучше маленькое изменение к лучшему коду, чем большая переделка, которую потом откатят.

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

Рефакторинг — это не «переписать по красоте». Это: «оставить лучше, чем было, и чтобы работало». Вы не обязаны делать из старой базы шедевр чистого кода. Но вы можете (и должны) делать код чуть понятнее, чуть чище, чуть удобнее, каждый раз, когда к нему прикасаетесь. 

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

1. Выделение функций: разделяй и управляй

В отдельную функцию точно следует выделить часть кода, который повторяется два и более раз в разных местах конфигурации. Я пользуюсь таким правилом: блоки от 5 строк и больше точно вынести отдельно, блоки от 3 строк — рассмотреть кандидата, менее 3 — не считать дублем и оставить на месте.

Еще одна категория выделяемого кода — это фрагмент кода, который сам по себе решает какую-то микро-задачу, например, получение параметров сотрудника или сериализация JSON-ответа от внешней системы. Цель такого приема: выделить как можно больше атомарных задач в отдельные функции. В дальнейшем их можно будет использовать в других алгоритмах, не изобретая отдельные велосипеды. Такой код становится повторно используемым, а модули для новых фич все больше обретают отдельные готовые «кирпичики» для построения алгоритмов.

До:

После:

Почему это хорошо:

• появляется структура;
• каждый кусок можно протестировать отдельно;
• коллеге (и вам через 3 месяца) проще понять, что происходит.

Мини-хак: если в процедуре больше 60 строк — это сигнал. Там можно что-то вынести.

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

1.1. Пишите чистые функции

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

До:

После (чистая функция):

2. Говорящие имена: пусть код говорит сам за себя

Мне очень нравятся слова Стива Джобса, который однажды сказал: «Если ваш продукт нуждается в инструкции, значит, он не готов. Идите и переделывайте».

В отношении имен переменных и функций действует то же правило. Если по имени непонятно, что делает функция, значит, имя задано неверно.

Плохо:

Лучше:

Почему это важно: переименование — один из самых дешевых, но мощных способов навести порядок. 

Совет: называйте функции как действия (Проверить(), Выполнить(), Получить()) — это делает логику прозрачной.

Для операции переименования в конфигураторе также есть отдельный инструмент рефакторинга «Переименовать».

3. Уберите мертвый код. Буквально

Удалил строчку. Ничего не сломалось. Подозрительно…

До:

После (удалено, и никто не заметил).

Зачем это нужно:

• Мертвый код создает шум.
• Его боятся удалять ( «вдруг надо?»), но он мешает читать остальной код.
• В 90% случаев он давно не нужен, просто никто не рискнул убрать.

4. Избавьтесь от дублирования

До:

После:

Плюсы:

• правите логику в одном месте;
• сокращаете объем кода;
• исключаете расхождения при копипасте.

Хитрость: дублирующийся код — ловушка. Сегодня вы забыли его править в одной из 6 копий, завтра вам звонит клиент.

5. Микрокомментарии: только по делу

Плохо:

Лучше:

Комментарий — это не «повторить код словами», а «объяснить, зачем он тут».

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

6. Мини-юнит-тестирование перед изменением

Хоть простейшее: скрипт на проверку результата.

Сценарий:

• Задача — внести правку в отчет.
• Вы запускаете отчет ДО изменений, сохраняете скриншот/выгрузку.
• После правок сравниваете результат.

Почему это работает:

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

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

Вывод

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

И да, если в модуле была Процедура П() и вы назвали ее ПроверитьПередЗаписью() — вы уже молодец!

Быстрое исправление без плана — идеальный способ провести вечер с отладчиком. Иногда весь уикенд.

Рефакторинг без подготовки — как прыжок в воду с завязанными глазами. А если это еще и боевая база, то в воду с крокодилами. Поэтому, прежде чем нажать Alt+Shift+F, проверьте себя по простому, но рабочему чек-листу.

Легаси не стыдно. Стыдно — когда ты все понял и все равно оставил как было.

Легаси — это не всегда плохой код. Это просто код, который жил дольше, чем его автор ожидал. Он есть в каждом проекте, потому что:

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

Он просто появляется, растет, обрастает условиями, флажками, Если Не Пусто Тогда и магией. И в какой-то момент начинает мешать. 

Но это не приговор. Хороший рефакторинг — это не подвиг и не риск. Это маленькие осмысленные шаги:

• дать осмысленное имя переменной,
• вынести повторяющийся код,
• добавить минимальный тест,
• и вносить изменения не «авось пронесет», а с планом и контролем.

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

И да, если вы однажды удалили Если Ложь Тогда и поняли, что это никому не нужно было, вы уже рефакторите. Просто продолжайте.