К сожалению сейчас не хватает ресурсов на тех, кто отправляет по 200 откликов в день...
А вам и не надо делать на них акцент. Ваша задача - обработать 30 резюме в день. При этом, насколько я могу судить, ваш HR не работает с соискателями (первичное собеседование), раз такое количество выдаёт за раз.
Представьте, что HR выдает вам раз в три дня по 100 резюме, которые прошли формальный фильтр. Вам надо работать, руководить командой и прочее. Как долго вы сможете вчитываться в каждое резюме?
Этапы, которые очень бы помогли вам: 1. HR смотрит резюме, которые остались после всех фильтров (включая всякие ATS, если пользуетесь), и просеивает их согласно тому, что именно вы ожидаете увидеть (конкретные дополнительные метрики) 2. Оставшимся назначается встреча только с HR, где он знакомит базово с компанией, описывает приблизительный pull задач, выясняет дополнительные пункты метрик, которые помогут отсеять еще больше кандидатов (от 30 минут) 3. Оставшихся уже направляет к вам.
А то складывается ощущение, что при 8 часах непосредственной работы HR менеджера, получаем по 16 минут общения с одним кандидатом (8 * 60 / 30 = 16). За это время можно только очень коротко рассказать о компании, еле успеть задать пару вопросов, а ведь еще надо, чтобы сам кандидат о себе рассказал, поговорить о задачах, подготовиться к другому кандидату (хотя бы посмотреть резюме, с кем будет общение, чтобы задать нужные вопросы).
Вывод: вам точно стоит пересмотреть данную область, так как складывается ощущение, что HR не проводит второй пункт, а сразу переходит к третьему, при этом перекладывая всю ответственность на вас. С таким подходом - именно вы выполняете его работу, а он просто получает зарплату так, будто выполнил всю работу сам.
И не увидите в большинстве случаев, так как человек работает на работе и там NDA на любые гитхабы, а после работы семья, заботы и тд, и на пет-проект времени нет.
В основном пет-проекты ведут те, кто имеет достаточно свободного времени вне работы.
Но вам тут не про пет-проект говорят, а про расположение вашего тестового задания на гитхабе, где человек может сделать fork, выполнить его, и прислать вам ссылку на готовое решение. А вы, как тимлид, можете провести code-review с указанием фидбека
Да, именно так и нужно делать. Вы провели общение, выявили слабые стороны, из-за которых отказываете, так проследите за тем, чтобы это было донесено до HR, а от него до кандидата. Так как, написать "{ФИО кандидата} нам не подошел, так как у него слабые показатели в использовании {название библиотеки / функции}" или же любой другой оцениваемый показатель - займет одну-две-три минуты.
От вас не требуется подробно описывать все слабые стороны, а возьмите только критические для вашей вакансии.
К тому же, на ваш взгляд не равно реальное ожидание у кандидата, он ждет, а вы его игнорируете, или даёте, если вообще даёте, шаблонный отказ "Мы не можем пригласить вас на следующий этап".
То есть, может вы и говорить о причинах отказа, только они не доходят до соискателя, а потом "Ой, никто не хочет работать", "Не можем найти", и прочие высказывания подобные по духу.
А ведь причина тут, на поверхности: кандидат не знает, чего именно от него будут ждать на собеседовании (кому-то важно техническое понимание выбора той или иной технологии, кому-то умение объяснять логику решения и тд и тп).
Как пример, вы идете в ночной клуб на мероприятие, и вас не пускает face-контроль, который прямо скажет, почему вы не проходите. И только в самых крайних случаях вам откажут "без причины", что будет говорить об сильной неадекватности и вызывающего поведения. А тут - пообщались, и "без причины" разошлись....
React, Redux Frontend developer совсем не про то, как работает ваш Redux под капотом. Это совсем лишняя информация, которая не пригодится в реальных проектах и задачах. А вот зачем он нужен, и чем он лучше и/или хуже другого state менеджера - это уже ближе к правде (реальной работе).
Иначе, если судить по акценту, который вы делаете на вопрос "Как работает Redux под капотом?", можно подумать, что вы спрашиваете у человека как работает код данной библиотеки, а не то, какие проблемы он решает, и, тем более, не какие проблемы он может создать при неправильном использовании.
То есть, возможно проблема в том, как именно задавать вопрос? Ведь, каков вопрос - таков и ответ :)
Не о том вам говорят. ХРюшами называют не всех специалистов HR, а именно тех, кто действительно ХРюша: 1. Отказ без объяснения 2. Игнорирование с обратной связью или ответом 3. Размытое тело вакансии 4. Опоздание на встречи и прочее, прочее, прочее
Работа HR заключается в том, чтобы пройтись по всем отобранным вакансиям, дать ответ тем, кто не подходит (не тыкать шаблоном отказа "Вам отказано.", а именно дать ответ), найти среди подходящих более достойного (или достойных) кандидата. Быть полностью ответственным и дотошным специалистом. Именно в этом и заключается работа HR, а не в бездумном отсеивании. Ему как бы за это и платят...
Узкая специализация работы с оборудованием Cisco, и широкая специализация с Frontend. В любом случае, не возможно всё сразу вспомнить, так уж устроен человек....
Попробовал погонять вот так это всё дело, ну как-то получается, что цикл быстрее, чем два .map, а если использовать только один map, то случается периодически, но не всегда, что цикл отстаёт от map (в примере я его не указывал, но попробовал).... :)
Но, если смотреть в сухом остатке, то можно спокойно использовать .map, если так хочется, ничего сильно трагичного не случится, тут зависит только от объектов и их "глубины" и code-style, а то можно запутаться можно будет в объектах и циклах, если они начнут вложенными быть один в другой, чтобы корректно обработать тот или иной case, необходимый в рамках задачи :)
Я понял посыл автора данной статьи, и вот что я могу сказать по этому поводу (ИМХО и только):
В вашем случае можно использовать тот же dayjs, luxon, momentjs (или любую другую библиотеку), и будет вам счастье, но в остальном - неправильное использование Date не повод для того, чтобы его "хоронить", а повод посмотреть документацию непосредственно к нему, где черным по белому написано - почему month не 1, 2 или 3 (и т.д.), а 0, 1 или 2 (и т.д.).
Лично я во всех проектах, где принимал участие и используется Date, дополнял небольшими dateUtils, в которых хранил helper функции для работы с Date и только те, что необходимы в рамках данного проекта. Без усложнений кода, его читаемости и прочего.
К тому же, не стоит забывать, что есть пользователи со старыми устройствами, где тот же Temporal работать не будет (Chrome до 144 версии, welcome, как пример), особенно устройства Digital Signage, где ES6-то не везде поддерживается и нужно через кучу polyfill пропускать код, а если и поддерживается, то обязательно найдется то, чего он не знает, так как там версии Chromium отстают от актуальных. Как пример: устройство Samsung Digitial Signage 2025 года поддерживает Chromium 120 версии и не выше... (ссылка тут, с указанием года выпуска модели и версии Chromium, что лежит внутри)
Как итог моего монолога: Выбирайте то, что необходимо вам в рамках ваших задач и целевой аудитории, но никогда не навязывайте своё мнение другим, так как у других могут быть другие задачи и другая целевая аудитория. А пока Temporal не имеет широкой браузерной поддержки, то пока не достоин столь пристального внимания. Лучше будет обратить на него внимание тогда, когда он будет поддерживаться всеми современными браузерами, и то, с точки зрения интереса "Что за зверь?"...
попсовый софт как яндекс диск(нет гуя для линукса), маил диск(нет даже консольного но можно накрасноглазить через rclone mount)
Это не проблема Linux (Ubuntu, Mint, и так далее), а проблема создателей данных приложений (Яндекс и Mail Group соответственно)...
Говоря другими словами, отсутствие того или иного "привычного Windows пользователю" приложения в том виде, с которым данный пользователь привык работать, не относится к проблемам или минусам Linux операционных систем.
К тому же, в последнее время, некоторые производители программного обеспечения начинают адаптировать или выпускать приложения, чтобы в том и или ином случае, у пользователя возникло меньше проблем с адаптацией к другой операционной системе.
Плохой пиар - тоже пиар )) Черный пиар - тоже пиар )) И тд ))
@nin-jinа можно уже перестать продвигать ваши решения, как единственно верные?.. Хотят использовать Moment.js (или любую другую библиотеку), то пусть используют, так как в большинстве своём это продиктовано руководством, или другой иной причиной ))
---------
По статье: большинство решений можно написать самому без использования каких-либо сторонних библиотек, что в некоторых случаях может снизить итоговый вес исполняемого файла, а также снизить риск в контексте "вдруг автор библиотеки сделает что-то неприятное" ))
Смотря на то, какой именно код вы используете в своём примере, сугубо по моему личному мнению, есть подозрение, что данный пример сильно "притянут за уши". И, на основе личного опыта, есть вопрос: а почему нельзя использовать useEffect на каждое из состояний в отдельности?
Пояснение вопроса: у нас есть несколько состояний нашего условного компонента, и каждое состояние, по написанной логике, отвечает за определенное поведение компонента, и мне не очень понятно, почему по одному изменению пропса должны меняться все состояния в совокупности разом, если каждое из данных состояний должно порождать то или иное дальнейшее поведение. То есть: category -> порождает обновление ссылки -> ссылка порождает fetch -> результат ответа (response / catch) на запрос порождает изменение либо data с обнулением error, либо error с обнулением data -> наличие которых уже порождает изменение isLoading, что в свою очередь позволяет держать актуальные состояния и ошибки в текущем моменте, а не держать их из "прошлого".
Попробуйте через голосового робота записаться на приём в поликлинику при дефектах речи (раза с тьсатого у вас получится, а при разговоре с оператором - с первого). И это полностью аналогично звонку в банк.
Ситуации бывают настолько разные, что шаблонов ответов и действий на них нет, из-за чего и необходима возможность связаться с оператором, который уже сможет, даже спустя некоторое время, найти решение, либо соединить с тем, у кого хватает квалификации и/или опыта в решении именно данной ситуации
И это касается, как голосовых, так и текстовых ботов/помощников, которые оперируют только шаблонами, и не подразумевают под собой воздействие человеческого фактора, как при получении той или иной услуги, так и при предоставлении услуги.
Поэтому, у всех ботов/помощников должна быть кнопка "связаться с оператором", либо "обратиться в поддержку"
PS: Всегда всё пытаются взвалить на сотрудников, при этом забывая, что сотрудник продуктивен в том случае, если для этого созданы все необходимые условия, о которых в своё время не одну статью здесь публиковали
PPS: ТОП-26 программ мониторинга тотального слежения для мнительных работодателей
Самая главная фича лично для меня это способность изменять пропсы компонента
Кто вам сказал, что менять props это замечательно и так нужно делать всегда? Вы не меняете props для компонента, к сожалению, вы меняете state, если судить по примеру, который вы привели.
Не знаю как вам, но в каждом проекте я сталкивался с необходимостью менять пропс
никогда с таким, лично, не сталкивался, сколько бы проектов не было за плечами.
И никакой тайпскрипт не нужен. Честно, ненавижу тайпскрипт.
TypeScript - не зло, которое нужно ненавидеть, но "на вкус и цвет..."
В реакте есть чудо юзэффект. У вью тоже есть computed, но почему то именно в моем коде мне приходилось всяческий изощряться чтобы заставить его работать.
Как это логично, не справились вы - но вините в этом инструмент. Это звучит так, "У меня не получилось забить гвоздь, виноват молоток" :)
If-elseIf-else, await, store, events
"Смешались в кучу кони, люди..." (с) М. Лермонтов. Бородино
На пункте "Special elements" я устал читать заметку автора о том, что "молоток не забивает винты, а отвертка не закручивает гвозди"... :)))
Это дело автора, его личное мнение и личная позиция, с которой спорить не буду, но дам один маленький, ничтожный совет: "Наполните заметку полноценными примерами как во Vue, так и на Svetle, чтобы у читателей была возможность в сравнение"
Сам по себе WebSocket никакого влияния не оказывает. Оказывает только умением им пользоваться для отображения данных, полученных, например, от сервера в момент опроса поисковыми ботами.
Профильные эксперты считают, что если доступ к реестру появится у всего кредитного рынка, то это может вызвать определённые сложности и риски, касающиеся утечки информации. По их мнению, при отказе в кредите правовые риски есть, но для банков они будут незначительными.
По порядку (сугубо моё личное мнение и видение данной ситуации):
Утечка информации всегда есть, даже на моменте создания реестра. Всегда стоит только вопрос в размере материального обеспечения к созданию данного риска - чем выше размер, тем выше шанс. И, какой бы закон, указ и/или постановление не вводилось для борьбы, то всегда будет тот/те, кто будет игнорировать данное ограничение, в особенности, учитывая размер штрафных выплат.
Правовые риски могут в дальнейшем сыграть обратную роль, и, вместо того, чтобы полностью оправдывать решение о непредоставлении услуги, они создают минимум один претендент на полное обжалование, что повлечет за собой:
Снижение доверия к государственным органам
Снижение доверия к банковской организации
и любые дальнейшие шаги, опирающиеся на данные выше пункты
Прежде, чем вводить что-то, принимать на том и/или ином уровне, необходимо продумать все возможные случаи, с которыми может столкнуться действие этого чего-то, а не "сначала вводим, разбираемся потом", как это делается последние n-десятков лет.
Скажу за свой опыт: мне попался очень хороший репетитор, который за месяц занятий обучил меня понимаю грамматики в сотни раз лучше, чем преподавали в школе )
А вам и не надо делать на них акцент. Ваша задача - обработать 30 резюме в день. При этом, насколько я могу судить, ваш HR не работает с соискателями (первичное собеседование), раз такое количество выдаёт за раз.
Этапы, которые очень бы помогли вам:
1. HR смотрит резюме, которые остались после всех фильтров (включая всякие ATS, если пользуетесь), и просеивает их согласно тому, что именно вы ожидаете увидеть (конкретные дополнительные метрики)
2. Оставшимся назначается встреча только с HR, где он знакомит базово с компанией, описывает приблизительный pull задач, выясняет дополнительные пункты метрик, которые помогут отсеять еще больше кандидатов (от 30 минут)
3. Оставшихся уже направляет к вам.
А то складывается ощущение, что при 8 часах непосредственной работы HR менеджера, получаем по 16 минут общения с одним кандидатом (8 * 60 / 30 = 16). За это время можно только очень коротко рассказать о компании, еле успеть задать пару вопросов, а ведь еще надо, чтобы сам кандидат о себе рассказал, поговорить о задачах, подготовиться к другому кандидату (хотя бы посмотреть резюме, с кем будет общение, чтобы задать нужные вопросы).
Вывод: вам точно стоит пересмотреть данную область, так как складывается ощущение, что HR не проводит второй пункт, а сразу переходит к третьему, при этом перекладывая всю ответственность на вас. С таким подходом - именно вы выполняете его работу, а он просто получает зарплату так, будто выполнил всю работу сам.
И не увидите в большинстве случаев, так как человек работает на работе и там NDA на любые гитхабы, а после работы семья, заботы и тд, и на пет-проект времени нет.
В основном пет-проекты ведут те, кто имеет достаточно свободного времени вне работы.
Но вам тут не про пет-проект говорят, а про расположение вашего тестового задания на гитхабе, где человек может сделать fork, выполнить его, и прислать вам ссылку на готовое решение. А вы, как тимлид, можете провести code-review с указанием фидбека
Да, именно так и нужно делать. Вы провели общение, выявили слабые стороны, из-за которых отказываете, так проследите за тем, чтобы это было донесено до HR, а от него до кандидата. Так как, написать "{ФИО кандидата} нам не подошел, так как у него слабые показатели в использовании {название библиотеки / функции}" или же любой другой оцениваемый показатель - займет одну-две-три минуты.
От вас не требуется подробно описывать все слабые стороны, а возьмите только критические для вашей вакансии.
К тому же, на ваш взгляд не равно реальное ожидание у кандидата, он ждет, а вы его игнорируете, или даёте, если вообще даёте, шаблонный отказ "Мы не можем пригласить вас на следующий этап".
То есть, может вы и говорить о причинах отказа, только они не доходят до соискателя, а потом "Ой, никто не хочет работать", "Не можем найти", и прочие высказывания подобные по духу.
А ведь причина тут, на поверхности: кандидат не знает, чего именно от него будут ждать на собеседовании (кому-то важно техническое понимание выбора той или иной технологии, кому-то умение объяснять логику решения и тд и тп).
Как пример, вы идете в ночной клуб на мероприятие, и вас не пускает face-контроль, который прямо скажет, почему вы не проходите. И только в самых крайних случаях вам откажут "без причины", что будет говорить об сильной неадекватности и вызывающего поведения. А тут - пообщались, и "без причины" разошлись....
React, Redux Frontend developer совсем не про то, как работает ваш Redux под капотом. Это совсем лишняя информация, которая не пригодится в реальных проектах и задачах. А вот зачем он нужен, и чем он лучше и/или хуже другого state менеджера - это уже ближе к правде (реальной работе).
Иначе, если судить по акценту, который вы делаете на вопрос "Как работает Redux под капотом?", можно подумать, что вы спрашиваете у человека как работает код данной библиотеки, а не то, какие проблемы он решает, и, тем более, не какие проблемы он может создать при неправильном использовании.
То есть, возможно проблема в том, как именно задавать вопрос? Ведь, каков вопрос - таков и ответ :)
Не о том вам говорят.
ХРюшами называют не всех специалистов HR, а именно тех, кто действительно ХРюша:
1. Отказ без объяснения
2. Игнорирование с обратной связью или ответом
3. Размытое тело вакансии
4. Опоздание на встречи
и прочее, прочее, прочее
Работа HR заключается в том, чтобы пройтись по всем отобранным вакансиям, дать ответ тем, кто не подходит (не тыкать шаблоном отказа "Вам отказано.", а именно дать ответ), найти среди подходящих более достойного (или достойных) кандидата. Быть полностью ответственным и дотошным специалистом. Именно в этом и заключается работа HR, а не в бездумном отсеивании. Ему как бы за это и платят...
Узкая специализация работы с оборудованием Cisco, и широкая специализация с Frontend. В любом случае, не возможно всё сразу вспомнить, так уж устроен человек....
Попробовал погонять вот так это всё дело, ну как-то получается, что цикл быстрее, чем два
.map, а если использовать только один map, то случается периодически, но не всегда, что цикл отстаёт от map (в примере я его не указывал, но попробовал).... :)Но, если смотреть в сухом остатке, то можно спокойно использовать
.map, если так хочется, ничего сильно трагичного не случится, тут зависит только от объектов и их "глубины" и code-style, а то можно запутаться можно будет в объектах и циклах, если они начнут вложенными быть один в другой, чтобы корректно обработать тот или иной case, необходимый в рамках задачи :)Я понял посыл автора данной статьи, и вот что я могу сказать по этому поводу (ИМХО и только):
В вашем случае можно использовать тот же dayjs, luxon, momentjs (или любую другую библиотеку), и будет вам счастье, но в остальном - неправильное использование Date не повод для того, чтобы его "хоронить", а повод посмотреть документацию непосредственно к нему, где черным по белому написано - почему month не 1, 2 или 3 (и т.д.), а 0, 1 или 2 (и т.д.).
Лично я во всех проектах, где принимал участие и используется Date, дополнял небольшими dateUtils, в которых хранил helper функции для работы с Date и только те, что необходимы в рамках данного проекта. Без усложнений кода, его читаемости и прочего.
К тому же, не стоит забывать, что есть пользователи со старыми устройствами, где тот же Temporal работать не будет (Chrome до 144 версии, welcome, как пример), особенно устройства Digital Signage, где ES6-то не везде поддерживается и нужно через кучу polyfill пропускать код, а если и поддерживается, то обязательно найдется то, чего он не знает, так как там версии Chromium отстают от актуальных. Как пример: устройство Samsung Digitial Signage 2025 года поддерживает Chromium 120 версии и не выше... (ссылка тут, с указанием года выпуска модели и версии Chromium, что лежит внутри)
Как итог моего монолога:
Выбирайте то, что необходимо вам в рамках ваших задач и целевой аудитории, но никогда не навязывайте своё мнение другим, так как у других могут быть другие задачи и другая целевая аудитория.
А пока Temporal не имеет широкой браузерной поддержки, то пока не достоин столь пристального внимания. Лучше будет обратить на него внимание тогда, когда он будет поддерживаться всеми современными браузерами, и то, с точки зрения интереса "Что за зверь?"...
Мира, любви и жвачки вам :)
Это не проблема Linux (Ubuntu, Mint, и так далее), а проблема создателей данных приложений (Яндекс и Mail Group соответственно)...
Говоря другими словами, отсутствие того или иного "привычного Windows пользователю" приложения в том виде, с которым данный пользователь привык работать, не относится к проблемам или минусам Linux операционных систем.
К тому же, в последнее время, некоторые производители программного обеспечения начинают адаптировать или выпускать приложения, чтобы в том и или ином случае, у пользователя возникло меньше проблем с адаптацией к другой операционной системе.
Плохой пиар - тоже пиар ))
Черный пиар - тоже пиар ))
И тд ))
@nin-jinа можно уже перестать продвигать ваши решения, как единственно верные?.. Хотят использовать Moment.js (или любую другую библиотеку), то пусть используют, так как в большинстве своём это продиктовано руководством, или другой иной причиной ))
---------
По статье: большинство решений можно написать самому без использования каких-либо сторонних библиотек, что в некоторых случаях может снизить итоговый вес исполняемого файла, а также снизить риск в контексте "вдруг автор библиотеки сделает что-то неприятное" ))
Спасибо за пример, и небольшое пояснение.
Смотря на то, какой именно код вы используете в своём примере, сугубо по моему личному мнению, есть подозрение, что данный пример сильно "притянут за уши". И, на основе личного опыта, есть вопрос: а почему нельзя использовать useEffect на каждое из состояний в отдельности?
Пояснение вопроса: у нас есть несколько состояний нашего условного компонента, и каждое состояние, по написанной логике, отвечает за определенное поведение компонента, и мне не очень понятно, почему по одному изменению пропса должны меняться все состояния в совокупности разом, если каждое из данных состояний должно порождать то или иное дальнейшее поведение. То есть: category -> порождает обновление ссылки -> ссылка порождает fetch -> результат ответа (response / catch) на запрос порождает изменение либо data с обнулением error, либо error с обнулением data -> наличие которых уже порождает изменение isLoading, что в свою очередь позволяет держать актуальные состояния и ошибки в текущем моменте, а не держать их из "прошлого".
ну как бы: https://learn.javascript.ru/import-export#dovod-protiv-eksportov-po-umolchaniyu
Попробуйте через голосового робота записаться на приём в поликлинику при дефектах речи (раза с тьсатого у вас получится, а при разговоре с оператором - с первого). И это полностью аналогично звонку в банк.
Ситуации бывают настолько разные, что шаблонов ответов и действий на них нет, из-за чего и необходима возможность связаться с оператором, который уже сможет, даже спустя некоторое время, найти решение, либо соединить с тем, у кого хватает квалификации и/или опыта в решении именно данной ситуации
И это касается, как голосовых, так и текстовых ботов/помощников, которые оперируют только шаблонами, и не подразумевают под собой воздействие человеческого фактора, как при получении той или иной услуги, так и при предоставлении услуги.
Поэтому, у всех ботов/помощников должна быть кнопка "связаться с оператором", либо "обратиться в поддержку"
Не появится эта кнопка, у всех "топ-менеджеров" только "экономия" пополнения кармана )
...
PS: Всегда всё пытаются взвалить на сотрудников, при этом забывая, что сотрудник продуктивен в том случае, если для этого созданы все необходимые условия, о которых в своё время не одну статью здесь публиковали
PPS: ТОП-26 программ
мониторингатотального слежения для мнительных работодателейКто вам сказал, что менять
propsэто замечательно и так нужно делать всегда? Вы не меняетеpropsдля компонента, к сожалению, вы меняетеstate, если судить по примеру, который вы привели.никогда с таким, лично, не сталкивался, сколько бы проектов не было за плечами.
TypeScript- не зло, которое нужноненавидеть, но "на вкус и цвет..."Как это логично, не справились вы - но вините в этом инструмент. Это звучит так, "У меня не получилось забить гвоздь, виноват молоток" :)
"Смешались в кучу кони, люди..." (с) М. Лермонтов. Бородино
На пункте "Special elements" я устал читать заметку автора о том, что "молоток не забивает винты, а отвертка не закручивает гвозди"... :)))
Это дело автора, его личное мнение и личная позиция, с которой спорить не буду, но дам один маленький, ничтожный совет: "Наполните заметку полноценными примерами как во Vue, так и на Svetle, чтобы у читателей была возможность в сравнение"
Сам по себе WebSocket никакого влияния не оказывает. Оказывает только умением им пользоваться для отображения данных, полученных, например, от сервера в момент опроса поисковыми ботами.
Никак. Они реагируют только на данные/контент.
Рекомендую к ознакомлению, с примерами, интерактивными решениями.
По порядку (сугубо моё личное мнение и видение данной ситуации):
Утечка информации всегда есть, даже на моменте создания реестра. Всегда стоит только вопрос в размере материального обеспечения к созданию данного риска - чем выше размер, тем выше шанс. И, какой бы закон, указ и/или постановление не вводилось для борьбы, то всегда будет тот/те, кто будет игнорировать данное ограничение, в особенности, учитывая размер штрафных выплат.
Правовые риски могут в дальнейшем сыграть обратную роль, и, вместо того, чтобы полностью оправдывать решение о непредоставлении услуги, они создают минимум один претендент на полное обжалование, что повлечет за собой:
Снижение доверия к государственным органам
Снижение доверия к банковской организации
и любые дальнейшие шаги, опирающиеся на данные выше пункты
Прежде, чем вводить что-то, принимать на том и/или ином уровне, необходимо продумать все возможные случаи, с которыми может столкнуться действие этого чего-то, а не "сначала вводим, разбираемся потом", как это делается последние n-десятков лет.
Скажу за свой опыт: мне попался очень хороший репетитор, который за месяц занятий обучил меня понимаю грамматики в сотни раз лучше, чем преподавали в школе )