Никита, спасибо большое, отличный и наглядный пример. Классный стрим, посмотрел с удовольствием, пойду читать про оскрипт
@СергейВикторович-и7т11 ай бұрын
Магия на желудях))
@Jimmo91011 ай бұрын
прошу "мини" курс по Осени... нефига не понял как она работает...
@СергейВикторович-и7т11 ай бұрын
Поддерживаю, очень интересно и хочется разобраться
@nixel200711 ай бұрын
Чтобы понять, как ей пользоваться достатояно прочесть документацию. Чтобы понять, как она работает - надо залезать в код. Если коротко - на рефлексии. С помощью саецивльного объекта Рефлектор, который есть в оскрипте и нет в платформе, анализируется состав классов, доступных к использованию, сохраняется информация об их методах, свойствах, аннотациях, зависимостях. Метод НайтиЖёлудь или ЗапуститьПриложение начинает разматывает все зависимости и инициализирует нужные объекты в правильной последовательности.
@yellow_club11 ай бұрын
@nixel2007 чтооооооо документацию ещё читать ???? Ты в своём уме ?)
@Jimmo91011 ай бұрын
Зачем напрягать глаза чтением, можно же просто послушать и посмотреть. Может кто то плохо читает и читать 10 листов у человека занимает дней 10, а видео посмотреть за день можно.
@nixel200711 ай бұрын
@@Jimmo910 обычно в видео опускают многие моменты, описанные в документации, теряя важные для понимания работы особенности. Либо это будет видео с полным чтением документации. Может в нейросеть можно загнать, сгенерить, но я уверен, что в случае просмотра примеров кода это будет менее удобно. Скорость чтения может не подойти, останавливаться и возвращаться к уже рассказанным моментам не удобно, поиска нет вообще, обновлять такую видеодокументацию намного сложнее, а значит, она постоянно будет неактуальной. Ну и зачем такое нужно? Вот было это видео с обзоркой на 2 часа. И вам все равно что-то не понятно. Посмотрите вы доклад Никиты на ИЭ, мастер класс или лекцию в Лектории. И все равно что-то останется непонятно. А времени потратите ощутимо больше.
@НикитаИванченко-х6я11 ай бұрын
Были вопросы в чате стрима про отладку. Отладка в оскрипте есть 👍
@alexorgnet10 ай бұрын
А что скажет по этому вопросу Борис Нуралиев ?
@НикитаИванченко-х6я10 ай бұрын
Какому именно? Концепция di или существование оскрипта ?
@ОлегЛитвиненко-о5з4 ай бұрын
DI на ОСени на стальной броне. Рев моторов глушит шум дождя.
@Jimmo91011 ай бұрын
30 минута - нефига не понятно.... Что такое инджект....
@yellow_club11 ай бұрын
Это нормально) не переживай
@alexorgnet10 ай бұрын
1С это про бухгалтерию. А это какие то секстанты! Отход от линии партии Нуралиевых
@НикитаИванченко-х6я10 ай бұрын
Не совсем верно. 1с это Фреймворк для построения приложений и систем ведения учёта.
@alexorgnet10 ай бұрын
@@НикитаИванченко-х6я правильно, для приложений и систем ВЕДЕНИЯ УЧЕТА. Все остальное сделать там невозможно либо не имеет смысла
@Guitar820211 ай бұрын
Слабо связанный код тоже имеет ряд своих недостатков, учитывая что код 1С это по-большей части код однопоточного исполнения, применение этого паттерна разработки в 1С только значительно усложнит отладку и чтение кода, при этом такой подход никак не влияет на производительность конечного решения, в ваших простых примерах это незаметно, но если кусочки слабо связанного кода в типовой ЗУП начнут выносить в расширения и что-то в них менять, а после этого перестанет заполняться какой-нибудь регл отчет, вот тут начнется вешалка для всего отдела разработки, который этой хеpнeй занимается.
@LosashExote11 ай бұрын
Без DI в хотя-бы какой-то мере, становится почти невозможно писать unit-тесты. Я свечку не держу, но сомневаюсь, что разработчики ЗУП эти тесты пишут. Советуется искать некую золотую середину путем того что подумать, а как бы я стал писать тест на свою новую функцию. Пример с печатной формой в начале видео - хороший. Если мы пишем тест на функцию создания табличного документа, мы не хотим косвенно во время него опираться на логику получения данных. Мы хотим получение данных отдельно тестировать. Поэтому данные неплохо было бы передать в параметр метода. И тому подобное.
@ivan_lebedev10 ай бұрын
@@LosashExote золотая середина это выкинуть 1С к х..м и писать на другом. Если начинаешь использовать тесты, DI, CI зачем тогда вообще 1С? проще взять какой нибудь зрелый язык и его использовать. Потому как иначе получается каша из топора.
@АндрейАндрей-н3у6м11 ай бұрын
Ржунемогу) труба все выдает этих конфигуристов😂🎉🎉
@ОлегЛитвиненко-о5з4 ай бұрын
Внедрение зависимостей в 1С. DI не возможен. Расходимся. Можно не тратить полтора часа своего времени
@LosashExote11 ай бұрын
Мне кажется, ценность курса Евгения и его ментора как раз в том, что там подобные концепции рассматриваются в призме реального 1С. Надеюсь на это. Недавно, на волне хайпа вокруг курса решил все-таки начинать становиться программистом (да, 1С программисты - не программисты, их никто не учил программировать, потребности не было...), купил литературы соответствующей, читаю. Плююсь на свое профильное образование, на котором этому не учили и эту литературу не давали. В принципе, на примерах ООП понятно. Но вот как многое из того, о чем читаю, переложить на 1С пока что не понятно. Ладно, классов в 1С произвольных нет. Ну, типа, есть обработки и форму можно получить на клиенте (закроем глаза на серверный вызов, ага), но это бред. Нет произвольных классов - нет сокрытия. Вообще. Все на договоренностях и контрактах строится. Вот сделал я свою имитацию класса на структурах данных. Написал к нему общий модуль - программный интерфейс, чтобы с ним работать. И при этом еще и вынужден в особо критичных моментах проверять, а не нарушил ли клиент (потребитель) котракта и не ковырялся в моем "классе" напрямую как в структуре данных. DI, вот. На процедурном языке программирования - хрен сделаешь нормально. Можно синтетикой усложнять, да. Создавать "имитации" классов на структурах данных, к ним "имитации" конструкторов, подкидывать в "поля" (свойства в глубине этого контейнера) зависимости. В принципе, так и делаю. Сам сомневаюсь, читаем ли вообще такой код. И обязываю клиента слишком много правил соблюдать при работе с этим (для типичного 1С). Просто, повторюсь, мне кажется, создавать для "класса" экземпляр Обработки - это слишком. Накладные расходы, плюс доступность только на сервере. Я много кода пишу КлиентСерверного контекста и создаю много контейнеров-структур, к которым отношусь как к классам. Ну да, методы положил отдельно, рядышком. А как иначе то в 1С? На курс пока не попасть, но там было бы интересно услышать мнения по этому поводу. Если они у авторов есть.
@yellow_club11 ай бұрын
Все правильно пишешь. Что касается DI и процедурного Программирования, то абсолютно верно. В 1С не возникает тех проблем, которые IoC контейнер призван решать. У нас событийно ориентированное программируем и мы просто вписываемся в точки, которые предоставляет нам платформа. Не бывает задач в 1С, где нужно в одном серверном вызове управлять 50 объектами. Поэтому проще через Новый создавать и не париться. А вот пример с инжектом в параметры методов это хорошо и это надо делать
@Lebowski8411 ай бұрын
Если ты не программист, не обобщай на всех 1с-ников.