Прикольно, но не понятно для чего велосипед в виде web-фрейморка, когда есть python начиная с bottle (для запуска которого нужно ПЯТЬ, КАРЛ, ПЯТЬ строк) заканчивая django. Типа на 1с подобном языке? p.s. Парни молодцы, что написали все это. может os и вырастет когда-то в python, но не при нашей жизни ) размер комьюнити, как сказал автор, как и все маленький!
Чтобы понять, как ей пользоваться достатояно прочесть документацию. Чтобы понять, как она работает - надо залезать в код. Если коротко - на рефлексии. С помощью саецивльного объекта Рефлектор, который есть в оскрипте и нет в платформе, анализируется состав классов, доступных к использованию, сохраняется информация об их методах, свойствах, аннотациях, зависимостях. Метод НайтиЖёлудь или ЗапуститьПриложение начинает разматывает все зависимости и инициализирует нужные объекты в правильной последовательности.
Зачем напрягать глаза чтением, можно же просто послушать и посмотреть. Может кто то плохо читает и читать 10 листов у человека занимает дней 10, а видео посмотреть за день можно.
@@Jimmo910 обычно в видео опускают многие моменты, описанные в документации, теряя важные для понимания работы особенности. Либо это будет видео с полным чтением документации. Может в нейросеть можно загнать, сгенерить, но я уверен, что в случае просмотра примеров кода это будет менее удобно. Скорость чтения может не подойти, останавливаться и возвращаться к уже рассказанным моментам не удобно, поиска нет вообще, обновлять такую видеодокументацию намного сложнее, а значит, она постоянно будет неактуальной. Ну и зачем такое нужно? Вот было это видео с обзоркой на 2 часа. И вам все равно что-то не понятно. Посмотрите вы доклад Никиты на ИЭ, мастер класс или лекцию в Лектории. И все равно что-то останется непонятно. А времени потратите ощутимо больше.
Мне кажется, ценность курса Евгения и его ментора как раз в том, что там подобные концепции рассматриваются в призме реального 1С. Надеюсь на это. Недавно, на волне хайпа вокруг курса решил все-таки начинать становиться программистом (да, 1С программисты - не программисты, их никто не учил программировать, потребности не было...), купил литературы соответствующей, читаю. Плююсь на свое профильное образование, на котором этому не учили и эту литературу не давали. В принципе, на примерах ООП понятно. Но вот как многое из того, о чем читаю, переложить на 1С пока что не понятно. Ладно, классов в 1С произвольных нет. Ну, типа, есть обработки и форму можно получить на клиенте (закроем глаза на серверный вызов, ага), но это бред. Нет произвольных классов - нет сокрытия. Вообще. Все на договоренностях и контрактах строится. Вот сделал я свою имитацию класса на структурах данных. Написал к нему общий модуль - программный интерфейс, чтобы с ним работать. И при этом еще и вынужден в особо критичных моментах проверять, а не нарушил ли клиент (потребитель) котракта и не ковырялся в моем "классе" напрямую как в структуре данных. DI, вот. На процедурном языке программирования - хрен сделаешь нормально. Можно синтетикой усложнять, да. Создавать "имитации" классов на структурах данных, к ним "имитации" конструкторов, подкидывать в "поля" (свойства в глубине этого контейнера) зависимости. В принципе, так и делаю. Сам сомневаюсь, читаем ли вообще такой код. И обязываю клиента слишком много правил соблюдать при работе с этим (для типичного 1С). Просто, повторюсь, мне кажется, создавать для "класса" экземпляр Обработки - это слишком. Накладные расходы, плюс доступность только на сервере. Я много кода пишу КлиентСерверного контекста и создаю много контейнеров-структур, к которым отношусь как к классам. Ну да, методы положил отдельно, рядышком. А как иначе то в 1С? На курс пока не попасть, но там было бы интересно услышать мнения по этому поводу. Если они у авторов есть.
Все правильно пишешь. Что касается DI и процедурного Программирования, то абсолютно верно. В 1С не возникает тех проблем, которые IoC контейнер призван решать. У нас событийно ориентированное программируем и мы просто вписываемся в точки, которые предоставляет нам платформа. Не бывает задач в 1С, где нужно в одном серверном вызове управлять 50 объектами. Поэтому проще через Новый создавать и не париться. А вот пример с инжектом в параметры методов это хорошо и это надо делать
Слабо связанный код тоже имеет ряд своих недостатков, учитывая что код 1С это по-большей части код однопоточного исполнения, применение этого паттерна разработки в 1С только значительно усложнит отладку и чтение кода, при этом такой подход никак не влияет на производительность конечного решения, в ваших простых примерах это незаметно, но если кусочки слабо связанного кода в типовой ЗУП начнут выносить в расширения и что-то в них менять, а после этого перестанет заполняться какой-нибудь регл отчет, вот тут начнется вешалка для всего отдела разработки, который этой хеpнeй занимается.
Без DI в хотя-бы какой-то мере, становится почти невозможно писать unit-тесты. Я свечку не держу, но сомневаюсь, что разработчики ЗУП эти тесты пишут. Советуется искать некую золотую середину путем того что подумать, а как бы я стал писать тест на свою новую функцию. Пример с печатной формой в начале видео - хороший. Если мы пишем тест на функцию создания табличного документа, мы не хотим косвенно во время него опираться на логику получения данных. Мы хотим получение данных отдельно тестировать. Поэтому данные неплохо было бы передать в параметр метода. И тому подобное.
@@LosashExote золотая середина это выкинуть 1С к х..м и писать на другом. Если начинаешь использовать тесты, DI, CI зачем тогда вообще 1С? проще взять какой нибудь зрелый язык и его использовать. Потому как иначе получается каша из топора.
