Не самая холиварная тема, но разобрать имеет смысл. Без пропаганды, 1С нам не платит, а жаль :)
Итак, сейчас параллельно живут две среды разработки в 1С – старый добрый Конфигуратор и странная штука 1С:EDT.
Понятно, что если Вы разрабатываете из дома – вопрос “что выбрать” не стоит.
Однако, представим себе компанию на 20-30 разработчиков – и уже не все так однозначно. Даже если Вы только планируете туда трудоустроиться :)
Начнем с самого интересного – со скорости.
Если есть вопросы – пишите в комментариях. Поехали!
Скорость
Те, кто уже использовал в своей практике EDT, ругались на скорость – “медленно, долго, обновление проектов приходится прямо ждать” и прочее.
Так ли это? – Да. Именно так.
Но почему?
Казалось бы, EDT, в отличие от конфигуратора, способна в параллельность, почему тогда она такая медленная?
А давайте посмотрим.
Вот простой пример – скачайте обработку Vanessa Automation и откройте ее в конфигураторе.
Там есть управляемая форма, откройте ее, внесите в нее какое-либо изменение – и нажмите сохранить.
Сколько времени она будет сохраняться? – около 3-5 секунд. Немного, правда? Для формы, где 40 000+ строк кода.
Однако, давайте зайдем в настройки Конфигуратора и поставим вот такие галочки:
Теперь также – сохраним форму, и ждем… ждем… ждем…
Есть. Сохранилось. Но это заняло 210 секунд. 210 секунд!!!
И в нашем примере они как раз есть, об этом чуть ниже.
Теперь перейдем в EDT и импортируем обработку туда. Приводить все этапы не будем, статья не об этом…
Главное – сколько это займет времени в EDT?
Не более двух минут (создать проект, импортировать и т.д.), а сам bin файл компилируется за секунды.
Но даже это не главное.
Почему мы так акцентируем внимание на проверках? – потому что есть нюанс.
Ошибки
Мы взяли проект Vanessa Automation…
В нем Конфигуратор не находит НИ ОДНОЙ ошибки на 40 000+ строк кода, даже в расширенном режиме!
А что покажет EDT?
300 ошибок на старте!
Давайте пробежимся по некоторым.
Первая:
Что здесь не так?
Система говорит, что функция должна вернуть значение – и у нас есть Возврат! Но дело в том, что возврат-то стоит внутри условия НЕ ВебКлиент. И если это будет веб клиент – функция ничего не вернет, точнее вернет Неопределено!
Это критично?
Может быть и нет, возможно, где-то далее кто-то проницательный и поставил дополнительную проверку.
А может, не поставил :)
В любом случае, если здесь прописано условие, то предполагается, эту функцию могут вызвать и с веб клиента. И даже если Конфигуратор это игнорирует – тут есть что поправить…
Идем дальше:
Вроде все корректно.
Но это же модуль объекта! И тут эти функции работать не будут, это просто копипаста.
И последний пример:
Вот что тут не так? Кто скажет?
А вот EDT говорит, что мы пытаемся оперировать переменной Стр, когда она была еще не определена. А по факту тут вообще должна стоять не Стр.
И если бы еще стоял плагин BSL LS, то он бы нас отругал за то, что у нас нет случая Иначе, и за то, что у нас код в двух условиях идентичный, и предложил бы два условия свернуть в одно.
По итогам простого анализа на пару минут создан тикет, который можно отслеживать и понять, были ли это реально ошибки или просто невнимательность – или же наши подозрения были избыточными.
При этом смотрите, Vanessa Automation – это специальный продукт для тестирования решений на базе 1С. И сам этот продукт тестируется так, как не тестируется, наверное, ни один другой.
Но даже тут можно найти всякие косяки, которые оставались незамеченными, как, например, мерцающая ошибка с путями, которая вероятнее всего приводила к тому, что если пользователь указывал путь без “/” в конце, то система не работала, а если указывал – все было Ok.
Даже если вы не планируете переходить на EDT – как минимум загрузите в него ваш текущий проект и просто проанализируйте ошибки. Я думаю, что вы найдете много чего интересного :)
А если нашли что-то уж очень интересное – делитесь находками в комментариях.
Ok, с тем, как нам EDT помогает по ошибкам – мы разобрались, круто.
Идем дальше…
Обработки, отчеты, расширения
Усложним теперь немного задачу – представим, что у нас есть внешние обработки, отчеты, расширения и прочее.
Какие плюшки нам дает EDT?
Про это смотрите видео ниже, в нем как раз видно, что разрабатывать в Конфигураторе код сложного продукта довольно не просто. Особенно, с мнимой “помощью” нашего любимого Конфигуратора.
Если же в проекте несколько разработчиков, то проблемы, связанные с функциями / процедурами / переименованием объектов / реквизитов, будут регулярными.
Но это не значит, что расширения плохи, это просто особенность среды разработки.
Да, можно сказать, что все это не особо критично, так как мы стараемся не переименовывать модули / функции, не менять количество параметров.
Тут можно продолжать – в EDT есть нормальный редактор запросов, внятные комментарии с типизацией объектов, определение типов “на лету”, все Обработки и Отчеты в одном месте – все это нам помогает, так как мы всегда работаем в одном контексте.
Только вернемся к вопросу о пропаганде – если мы просто “ведем бухию, пилим пару доработок, не используем расширения и накатываем обновления, работаем в одно лицо”, Конфигуратор – отличный вариант, мы к нему привыкли, не нужно переучиваться, а в остальном будем просто осторожнее. В этом кейсе EDT никаких глобальных плюсов не принесет, а переход – это затраты времени и, следовательно, денег.
Все логично :)
Но давайте продолжим…
Исходники
Одна из “плюшек” EDT относительно Конфигуратора – подход, когда база данных отвязана от конфигурации.
Точнее наоборот: вы работаете с исходниками, которые вообще никакого отношения к базе данных не имеют, а потом вы заливаете эти изменения в нужную вам базу данных.
Когда это удобно?
Например, когда у вас одна конфигурация в разных базах на разные организации и вы ведете по ней разработку.
При этом в одной базе организация работает по своим бизнес-процессам и правилам, а в другой – по своим. А конфигурация в идеале – одна, чтобы не накатывать и откатывать доработки и обновления в каждую отдельно.
Сейчас приходится писать код в одной базе, потом переносить код или cf в другую базу. Если что-то поломалось – делать обратную операцию и т.д.
И это, хотя и привычно – все-таки неудобно. Даже для двух баз. Представьте, что Вы сопровождаете хотя бы пару десятков.
В случае EDT – мы можем просто обновить две базы, запустить обе базы в режиме отладки, остановиться в одном и том же месте и исследовать стек вызова в каждой базе отдельно. Выглядит это так:
Что это значит? – Вы работаете с одними исходниками, но отдельно в контексте каждой базы. В каждой базе могут быть свои отдельные данные, по которым вы, например, можете прогонять свои тесты.
Еще пример – есть РИБ (распределенная информационная база) и в одной базе документ проводится, в другой – выдает ошибку.
Это РИБ, там базы по умолчанию идентичны. Но вы должны брать две базы, заходить в два конфигуратора, синхронно переносить код и проверять, чтобы ничего не сломалось. И EDT здесь выручает.
Подписки на события
Что можно использовать, чтобы посмотреть в какой подписке находится нужный вам объект?
Для этого в Конфигураторе есть… Аж ничего…
В лучшем случае можно сделать ссылки на объекты, так как имени подписки верить нельзя, там иногда реально чудят.
Но допустим, мы вычислили все подписки… Теперь надо в каждой из них пойти и проставить точку останова, чтобы понять, какая подписка что-то меняет в Документе.
В общем, это время и деньги.
Как это делается в EDT?
Нажимаем правой кнопкой на Проекте и выбираем подписки. Нас встретит вот такое окно:
Мы сразу видим, какие подписки есть вообще, нажимая на верхний уровень подписки – видим, что входит во все подписки ниже, то есть все документы или справочники, регистры и т.д. Нажав на конкретный уровень подписки, мы видим, что входит в конкретную подписку.
Но что, если нужно остановиться на всех подписках? Тогда нажимаем кнопку справа вверху и нам открывается вот такое окно:
И здесь можно указать, какие подписки мне нужны, на какие объекты, поставить галочки в тех подписках, где мы хотим поставить точку останова.
Но давайте ускоримся :)
Наши любимые RLS
Для начала – именно из-за RLS у нас основные проблемы с размером базы данных, с тем, что EDT долго импортирует объект, и, конечно же, это причина очень больших объемов и долгих загрузок конфигураций.
Кстати, по этой причине и не только, мы в свое время выпиливали роли напрочь и написали отдельный механизм, который позволяет роли вынести в Расширения и анализировать их, если кому интересно – вот ссылочка.
Однако в случае работы с ролями, к плюсам EDT можно отнести то, что есть возможность настраивать список выводимых колонок с правами, видеть все права в списке и более гибко настраивать фильтры:
Плюс, делать групповое добавление ролей к нужным объектам:
А вот Конфигуратор выигрывает в том, что он позволяет копировать шаблоны ролей.
Кстати, обратите внимание, что в Конфигураторе роли идут в столбцах, а права в строках, что обычно делается тогда, когда архитектурно мыслишь, что у тебя колонок будет меньше чем строк:
Вообще, 1С разработала новый стандарт именования ролей и принципы создания ролей (новые относительно того, что было в ранних конфигурациях, например, УТ 10).
И выглядит это сейчас в Конфигураторе довольно непрозрачно, так как все роли называются Чтение, Добавление и т.д., и в итоге – ничего не понятно, так как заголовки таких ролей обрезаются до Чтение…, Изменение… и т.д., что приводит к почти полной бесполезности этого механизма анализа ролей в Конфигураторе.
Это проблема?
И да и нет. Если речь про настройку пары ролей – не проблема вообще. Если нужно синхронно изменить несколько десятков или пару сотен – придется изобретать костыли.
Но ладно, идем дальше, давайте посмотрим на нашу любимую процедуру обновления конфигурации.
Обновление конфигураций
Прекрасно здесь то, что когда меняется какое-то свойство на форме – нам предстоит весьма интересный квест по поиску “того самого места”.
Давайте возьмем две разные версии Vanessa Automation и сравним их.
Что нам показывает конфигуратор:
Так, ладно, мы видим что изменилась форма, но насколько критично?
Ok, понятно.
Но если мы не хотим, чтобы новый заголовок применялся? Или чтобы кнопка удалялась?
Что надо делать?
Правильно. Нужно идти и править это все после объединения ручками. Ну или до объединения в той обработке, которая прилетает вторая.
А если это конфигурация, то нам нужно будет запускать повторное сравнение и т.д.
А теперь, что нам показывает EDT:
Обратите внимание – все в одном месте, вся конфигурация, все формы.
Мы можем чуть ли не любое изменение подтвердить, или наоборот – отклонить.
Не надо ничего выдумывать, мы работаем здесь и сейчас. Сразу видим, например, что будет удалено, причем не этими “стрелочками”, которые всегда ввергали в ступор и вечно путали – а нормально, четко и ясно.
Наглядно видно все – и в то же время у ребят из EDT уже записано пожелание скрывать типы изменений по фильтрам, чтобы можно было фокусироваться на ключевом.
А вот сравнение кода в EDT выглядит не очень привычно. Хотя и вполне логично – но непривычно:
EDT – зайчик?
Но все ли прям хорошо?
В EDT хватает своих “тараканов”.
Например:
- Есть версия Проекта (это не версия совместимости) и эта версия Проекта жестко связана с версией Платформы, причем Платформа должна быть строго этой версии (например, 8.3.18) и если у вас будет на компьютере версия выше или ниже – работать вы не сможете.
- EDT, чтобы понимать, что ваш Проект соответствует конфигурации в базе данных, хранит кеш версии базы данных. И – в теории – при изменении обновляется только та часть, которую вы изменили. Т.е. требуется буквально пара секунд, но нередки случаи, когда надо базу обновлять целиком, а это может занимать массу времени.
- Иногда (чаще, чем хотелось бы) надо делать очистку Проекта – это специальная операция, которая пересобирает Проект, что на больших конфигурациях и слабых компьютерах может выполняться довольно-таки долго. Прямо совсем не кофе попить.
- Вам надо будет регулярно смотреть в лог EDT на наличие ошибок, если что-то пошло не так.
Но тут есть хорошая новость – есть официальный Tg-чат по EDT от самих разработчиков, где они прямо в телеграмме выслушают и помогут. Канал находится тут https://t.me/e1c_edt.
А еще у EDT появился ОФИЦИАЛЬНЫЙ баг трекер по EDT, где каждый может не просто зарегистрировать ошибку, но и проследить за ней https://github.com/1C-Company/1c-edt-issues/issues!
Так что никаких v8@1c.ru, со стандартными отписками и требованиями всяких номеров партнеров и прочего. Это возможно, так как EDT – абсолютно бесплатна. И скачать ее может любой, кто просто зарегистрирует учетку на сайте 1С.
Итоги
Это – достаточно беглый обзор, он не претендует на анализ ВСЕХ плюсов/минусов EDT относительно Конфигуратора.
И если у вас сложилось впечатление, что мы продаем EDT и призываем забыть про страшный старый Конфигуратор и наслаждаться жизнью, то вы – абсолютно правы.
Шутка :)
Все проще – все медленно, но верно разворачивается к тому, что в “промышленной разработке” произойдет миграция на EDT.
Поэтому обязательно посмотрите в сторону этого продукта, хотя бы как помощника. Пусть даже только на первых порах и не постоянного, а эпизодического.
Но это не значит, что это нужно прямо всем.
Если вы не хотите использовать EDT в повседневной практике (а причин реально может быть много, от старого железа / старой конфигурации до отсутствия групповой разработки в принципе) – Ok, это точно не проблема.
Все меняется тогда, когда над продуктом работает несколько человек и все нужно технологизировать.
Причем сам по себе EDT – тоже не предел. Когда вы решитесь перейти в git, а в дальнейшем – внедрите DevOps методики, то станет понятно, что ограничивать себя простой разработкой в Конфигураторе – это уровень все-таки очень базовый.
С другой стороны, важно избежать импульсивных решений, типа – вот, меня убедили, я ушел в EDT и теперь буду делать все только там, так я быстрее привыкну.
В этом есть свой фан, но нужно понимать – EDT еще имеет ряд проблем, которые НЕ позволяют просто так, за две минуты в него переехать и забыть про Конфигуратор.
Но что можно сказать точно: EDT дозрел и им уже можно пользоваться. Не всем. Но тем, кто в командной разработке, – вариантов немного.
И когда EDT будет являться у вас одним из элементов цепочки методологии DevOps, то даже со всеми его проблемами, местами – неудобствами, багами – вы будете открывать Конфигуратор со странным ностальгическим чувством :)
Хорошая статья. Раньше сомневался стоит ли попробовать EDT, теперь точно знаю что не стоит.
Когда-то все боялись “восьмерки”, потом управляемых форм, потом мобильников – все везде было не то и не так. Но ограничивать себя в знаниях – личное дело каждого.
“Без пропаганды” – а что так? И потом, кого стесняться. “1С нам не платит, а жаль :)” – а кто платит? Впрочем, вопрос не корректный, а жаль :)
Заказчики, конкретные потребители 1С, четко расскажут о своих задачах, проблемах. Но кому это интересно, эдак они будут решены и все. А как же мы дальше будем харчеваться? Нет, нам нужны проблемы долгой загрузки, ошибки наложения обновлений, коллизии расширений и все в таком духе. Их мы можем обсуждать годами, “решать” и за это получать денежки. Совсем другое дело. Вот и появилась очередная, новая приблуда на которую можно развести клиента, ой, то есть предложить приобрести новую, современную систему, а еще курсы по обучению, ну и так далее. Не удивлюсь если права на эту разработку принадлежат не 1С а нашим “партнерам”. Не для них ли правильный, понятный “партнерам” язык 1С поставили? Еще хотелось бы интересный момент отметить на видео, когда программа не показывает ошибки, нужно выгрузить проект, тогда очистится кэш, загрузить проект, и тогда показывает. Это ли не танцы с бубном? Но их мы будем устранять в следующей приблуде. Жизнь не останавливается на достигнутом.
Ну тут все просто, значит у вас нет проблем, которые решает EDT. С чем могу вас поздравить. И вобще – в 7.7 не было проблем с публикациями баз, с разными версиями субд, и всяких там проблем с линуксом, макосью и т.д. :)
Уважаемый автор, замеченная проблема и правда показывает Конфигуратор не с лучшей стороны, но мне кажется, что Вы в своем видео рассматриваете не реалистичный сценарий доработки. ИМХО, если есть потребность использовать расширения, значит редактировать код самой конфигурации не представляется возможным. В “Боевой” ситуации в таком примере, как у Вас, параметры исходного модуля меняться не будут. К тому же, если дорабатывайте код, который уже в продакшене, то лучше сперва исследуйте его вызовы. Поправьте, если не прав.
Насчет сравнения возможностей контекстной подсказки, тут, конечно, Конфигуратор остается аутистом, хехехе
Это был просто один из примеров. Тоже самое относится и к внешним обработкам, которых сотни могут быть, и вы в конфе поменяли некие вызовы функций, прееименовали, перенесли и т.д. Или это сделал поставщик обновлений. Теперь вопрос – как проверить все сотни обработок? Открывать каждую и проверять? А едт это все вам сразу покажет.
Добрый день!
А у меня вопрос – как вы проверяете сотни внешних обработок?
Насколько я понимаю – они все должны быть подключены к проекту.
В таком случае все эти обработки должны быть в репозитории, и все разработчики обязательно должны добавлять все обработки в проект.
На первый взгляд, всё не так просто, когда обработок много. Для этого должен быть чётко отлажен процесс разработки внешних обработок и других объектов, содержащих программный код,.
Доброе. Для такого количества обработок и разработчиков – обычно используется CI конутр, который сам все это проверяет. Но, можно и просто открыть все обработки и посмотреть, если они в одном проекте.
100 обработок – это не так уж и много, много – это когда их под тысячу, и не просто обработок, но еще и отчетов, которые просто так точно не проверить.
Конфигуратор никуда не денется. Так что выражение “меняет рабочую среду” неприемлемо.
Не знаю, мы у себя вообще конфигуратор не используем, и весь процес до выпуска релиза – не задействует его.
ЕДТ пока низом обращается к агенту конфигуратора, но это тоже не на долго. Так что вполне возможно работать при полном отсутсвии конфигуратора. Другой вопрос, что если вам надо обновить типовую бух, то заводить монстра в виде едт – смысла нет.
Все бы хорошо. Но EDT к сожалению запускает проекты очень медленно, ну просто ужасно медленно по сравнению с конфигуратором. По сути иногда проще 5 раз конфигуратор запустить чем 1 раз EDT. Ну это конечно на одном и том же железе. Вы скажете ставьте себе на рвбочий комп побольше оперативы и все такое. но иногда это не выход. И даже если железо поставить крутое то на нем конфигуратор вообще летает и EDT тупит. Ну и что тогда лучше не понятно. Я думал раньше что EDT будет крутой штукой, но уже прошли годы а она все еще не взлетела. Даже видео уроки обычно почему-то делают в конфигураторе, а это показатель. Была бы EDT хороша ее бы сразу все использовали. Ну а так работать геморно. Вот и все выводы.
Да, и такое есть, но это значит что в ваших случаях – затраты едт не перекрывают его плюшек. Но так не всегда и не везде.
Не понял, а как он определяет тип результата функции? Например, у такой функции:
Функция СвойствоОбъекта(ЛюбойОбъект, ИмяСвойства)
Возврат ЛюбойОбъект[ИмяСвойста];
КонецФункции;
Никак, просто вернет тип Произвольный
А можно ли пользоваться git без 1C EDT?
Да, и этому посвязем 4 модуль полного курса, там про EDT вообще ни слова. Однако, есть ряд проблем с этим.
Однако, 4 модуль про гит в целом на примере конфигуратора, а не про систематическую работу с гитом через конфигуратор.
А пересборка cf сколько времени занимает ?????
Что значит – пересборка cf? Тут cf нет нигде, все работает через xml. И зачем ее пересобирать?
Ну посмотрим как Вы запустите EDT 32-х разрядной Windows. Показанные преимущества сомнительны, они больше демонстрируют недоработки конфигуратора, а не преимущества EDT. Можно также показать недоработки EDT относительно конфигуратора. Основная фишка EDT – проектная разработка, в части обычной разработки лучше Конфигуратор.
Каждому свое. EDT не предназначен для работы “в полях”. Кто-то и в файловых базах работает, но серверные же тоже не зря придумали?
По мне это видео розжиг холивара: тысячу лет, думаю, не я один проклинаю 1С только за то, что они не хотят заменить своё недоинструменто на снегопата. Такое впечатление, что в 1С спят и видят, чтоб мы их проклинали. А этот ЕДТ засуньте себе … куда-то поглубже на диск. Я с виндой обленился с установками, а чтобы поставить ентот ЕДТ, надо ещё кучу инфы вытащить из инета, чтобы поставить кучу приблуд не нужных, да и то ещё эта с… не установится. Надеюсь, что хоть и с матом, но без оскорблений. А, да. Ещё слышал от тех, кто ставил сие чудо, что оно жрёт всё что есть похлеще криво соединённого запроса.
Тут, как говорится – каждому свое. Я готов потратить ресурсы компьютера, вместо своих ресурсов. На то он мне и нужен.
Этот холивар не имеет смысла. Это как сравнивать Word c Notepad, где мы говорим, что лучше бы они из Notepad – сделали Notepad++. Но notepad++ всеравно никогда не будет Word. Однако – есть задачи где Notepad не заменим, но есть и другие задачи.
Не знаю как сейчас но EDT ужасно тормозная и требовательная к ресурсам. Ну а приведённые примеры это не плюсы EDT, а рукопопость разрабов конфигуратора. А уж закрытие платформы после прерывания отладки это особый высший пилотаж.
Да, но это проблема уже разработчиков конфигураций, а не ЕДТ. Если не хотите чтобы платформа закрывалась – делайте деатач отладки, хотя в каких кейсах это надо – не знаю.
А как насчет того чтобы инструмент помогал мне в разработке, а не я прыгал вокруг него, чтобы только он не вылетал
Я думаю – это отличное предложение.
Но с ним – вам надо идти к разработчикам платформы и едт.
А нам остается только выбирать вариант – что перевешивает – удобство разработки и танцы с бубном, или писать код в “нотпаде” зато стабильно.
я предпочитаю комбинировать.
Все бы ничего, но обычные формы еще в работе. а едт их не любит)
да, тут и не поспорить. Однако, если так думать, то и на 7.7 еще многие сидят :)
Итог. EDT лучше понимает и работает с возвращаемыми структурами.
остальное не критично (изменение параметров – ну такое; для корректного описания функций есть спец формат комментария перед функцией, где можно описать типы параметров и зачем они нужны)
Только вот кнфигуратор не следит за тем что вы там написали, и не помогает вам никак в контексте этих типов, в едт – помогает и следит.
Серьезно? 1С меняет рабочую среду, чтобы курсор прыгал внутрь скобочек? Очевидно, что конфигуратор устаревшая среда разработки, но в EDT, несмотря на приятные фишечки, на текущий момент есть свои недостатки. По заголовку думал будет более глубокое сравнение, оказалось – кликбейт
Странно было бы, если бы их не было.
Если вы напишите – что конкретно вам интересно, то, возможно, учтем в следующих материалах. Но надо понимать, что статья – это не курс. Писать статью на 20 часов видео – дело не легкое и не имеет смысла.
Нет, не было бы странно.
Хорошо, что вы свои программы пишете без ошибок, но других таких людей я не знаю.
1С элемент не отдают уже годами, и все плачут, что их только дразнят, а ЕДТ дали раньше – их хают, что там есть баги.
Нормальный разработчик не будет так наплевательски менять количество параметров, он либо добавит этот параметр с значением по умолчанию, либо выполнит глобальный поиск по конфе, расширениям и предварительно выгруженным внешним обработкам.
Я даже не знаю что ответить. Я просто завидую вашему опыту. По белому завидую. Но практика – показывает другое. Увы…
В конфигуратор, достаточно добавить простую функцию, которая пройдется по всем текстам, в том числе и внешних обработок, которые укажет разработчик, увидит что не хватает параметров и сообщит об этом. Одни резработчики, которые делали конфигуратор, не сумели достичь таких высот программирования, сочли это не барским делом, сделали, но отключили и могут объяснить почему, как впрочем и все что угодно тоже могут объяснить. Другие разработчики, не удосуживаются сделать поиск по всем текстам, процедуры в которой сам изменил количество параметров, точно зная что программа выдаст ошибку.
Если такой подход считать за норму, то поможет ли EDT или надо поставить программу в которой нажимаешь любую кнопку и получаешь нужный результат?
Расскажите это ребятами, которые пишут плагин BSL LS. Пусть они расскажут – как это просто сделать. На столько просто, что те спецы, которые пишут этот плагин – уже несколько лет не могут решить проблему с MD классами. Параметры – это самый примитивный вариант, но даже так – а если у вас в функции 3 параметра, а через расширение вы добавили 4, что тогда должа система определить и главное – как, если она просто пройдется по текстам?
Эх, если бы это было так просто…
В конфиуграторе просто поставьте галочку расширенной проверки и остальные связанные с ними галочки, и вы сразу их выключите, когда у вас модуль будет сохранятся по несколько минут, и потом мы вернемся к тому, какая медленная EDT. А это будет всего лишь проверка текстов, причем в ограниченном режиме. А не как в ЕДТ – полный анализ, в том числе и связанных проектов.
Конфигуратор – это однопоточный редактор кода, который ограничен в своей архитектуре на столько, что его даже дорабатывать боятся уже десяток лет. Только мелочь добавляют какую-то.
И именно конфигуратор породил таких монолитных монстров как ERP, так как по другому нельзя было.
У меня было несколько попыток бросить конфигуратор и перейти на ЕДТ, но работать с ним невозможно. То жуткие тормоза, то отладка не запускается, то еще чего…
Да, бывает и такое. Но, когда разобраться со всем – плюсы перевешивают минусы. Плюс – надо базы специально готовить. Работа с едт – это не работа на проде, или копии прода, обычно.
Удобны некоторые моменты. Я не спорю, но когда ЕДТ будет работать независимо от конфигуратора, тогда да. Можно говорить о новой среде разработке, а пока ЕТД зависит от конфигуратора, она останется прокладкой между конфигуратором и базой данных.
Уже ЕДТ умеет работать без конфигратора – через автономный сервер. Хотя, пока это бета режим. Но скорость выше на порядок.
1. Неужели нельзя было просто допилить конфигуратор. 2. Часть указанного (насколько помню) без проблем получается использованием доп софта еще со времен телепата в семерке и снегопата, турбоконфонфа итд в восьмерке. Честно, лучше бы нормально основную среду разработки допилили.
Не согласен. Конфигуратор – это пережиток прошлого века, который “доработать” – не выйдет. Сама логика привязки конфы к базе и работа с объектом в таблице базы данных, а не с внешними файлами – обречена на провал. Да, 20 лет назад это было норм. Но не сейчас.
Конфигуратор нас ограничивает в возможностях. Это тот случай, когда люди пишут под инструмент, а не так, как того требует логика.
Чего стоит только этот ужас с обновлением конфигураций через файлы поставки. Или работа с хранилищем конфигураций?
А сколько раз люди теряли свои разработки после того, как конфигуратор в крит вылетел?
Если бы EDT вышел лет 10 назад, то у нас бы вообще сейчас все было по другому. И не было бы этих монолитов в гигабайты.
Скажите, а как Вы сделали такую тему в EDT? Значки красивые!
Установлена вот эта тема https://www.genuitec.com/tech/darkest-dark/
Добрый день! Эта тема не хочет устанавливаться.
Говорит:
Отсутствующее требование: Genuitec Enhanced Theme 1.11.0.202206271604 (com.genuitec.eclipse.theming.core 1.11.0.202206271604) требует ‘java.package; org.apache.commons.lang3 [3.1.0,3.2.0)’, но его не удалось найти
А на jdk11 от оракл, где все это есть, не хочет запускаться EDT. Что посоветуете?
Попробуйте поставить последнюю версию EDT, там ядро эклипса обновили, может в этом проблема.
Плюс надо поставить все галочки в настройках осайтов обновлений, иначе система не понимает – откуда брать отсуствующие пакеты.
Ну и JAVA надо скачать ИТС, для верности. С ней точно все работает.
Спасибо, а почему в самом конфигураторе нельзя эти фишечки с проверками допилить, ведь это не сложно.
Не реально, конфигуратор делает анализ только метаданных и измененных модулей. Он просто не заточен на многопоточность, плагины и т.д.
Плюс, там столько легаси за столько лет, что, видать, от него решили избавиться :)
Зачем весь код на английском?
Делали статью на том языке, который был под рукой и с которым работает автор статьи. Сакрального смысла в этом нет.
C Eclipse я работал задолго до того, как вообще начал чего-то писать на 1С. Поэтому хотелось бы перейти на что-то подобное (лучше на что-то от JetBrains, т.к. Eclipse никогда не был удобным, но ладно). Но нельзя полагаться на пустое.
– IDE слишком серьезная вещь, чтобы быть надстройкой над конфигуратором. Это все равно как закатить феррари в фургон и радоваться удобным сиденьям и кондиционеру, периодически переливая горючее в бак фургона, а масло в феррари. И изумляясь протечкам.
– Я хочу знать, что все команды разработчиков основных продуктов 1С, хотя бы бухгалтерии, ЗУП, УТ и ERP ведут разработку только под этой IDE, а не исключительно особый отряд под номером 100500.
Все эти очистки проекта, тут можем, тут не можем, под этой платформой работаем под этой нет исключительно отсюда. Это даже не баги разработки – это просто признак отношения к проекту. Одно дело, когда у вас окошечки не того размера или даже надо исполнить танец с саблями при установке и совсем другое, когда разработка неожиданно останавливается т.к. IDE решило, что пора ей почиститься.
Поэтому, читаю я подобные статьи, облизываюсь, т.к. конфигуратор по уровню удобства застыл на уровне 1913 года, а хранилище это “тут несколько непечатных выражений”, но переходить на EDT пока не вижу смысла.
А держать EDT параллельно, но работать в конфигураторе, ну такое себе “красивое”.
P.S. У меня нет инсайда, но я почему-то уверен, что в коде конфигуратора полноценно разбирается “никто”. Поэтому очень бы хотелось, чтобы от него отказались. EDT был бы хорошим поводом, но… предпочли использовать конфигуратор по принципу черного ящика.
Увы, по некоторым пунктам соглашусь. И также, надо понимать, что конфигуратор устарел в ядре. И там такой легаси, что дешевле было все натянуть на эклипс. Я не думаю, что 1С просто проснулась и сказала – ой, а давайте натянем все на эклипс :)
И, самое страшное для ЕДТ – это конфигуратор. Так как именно с ним связано большинство тормозов и медленных обновлений. Но, и тут решили от него отказаться, в пользу нового механизма – автономный сервер. Т.е. конфигуратор, по сути – оставляют только для обновления бухи, грубо говоря. Это мое мнение.
На счет долгих очисток проектов – это да, бывает, но над этим очень сильно работают. И, корень проблем – опять конфигуратор. Так как он позволяет работать только с монолитами. Вот и выходит так, что вместо каких-то подсистем – у нас монолит на сотню тысяч файлов. Например, если взять ERP WE, это то, где из типовой ERP выпилили все законодательство РФ, то очистка проекта там занимает 15 минут, а в типовой – 40-50. Почему? А потому что там куча “мусора”, типо регламентных форм на десятки, а то и сотню мегабайт в одном файле, а такое парсить потоками нельзя. Вот и застревает ЕДТ.
Так что ЕДТ – сейчас решает проблемы, которые не свойственны другим системам, практически не свойственны. Но, тот же автономный сервер позволяет загрузить ЕРП с нуля за считанные минуты, или выгрузить. Но он, пока что, в бете, поэтому его нет в ЕДТ.
Спасибо за быстрый ответ. А не подскажете где почитать про то как автономный сервер заменит конфигуратор? А то я сейчас погуглил, нашел только это, но, вроде как, это про другое?
https://its.1c.ru/db/v8314doc#bookmark:adm:TI000000894
Автономный сервер + ЕДТ, если быть точнее. Автономный севрер умеет работать с базой, в том числе и публиковать и запускать отладку, а ЕДТ умеет все остальное.
Добрый день!
Дмитрий, подскажите, “Обновление конфигураций”. Не ради холивара :)
ЕДТ, работает с исходниками без привязки к базе данных, не совсем понял момент, например, я обновил тестовую базу, проверил, работает. В прод загружается обновление…а как же запуск в режиме предприятия и обновление данных когда 5-6 релизов обновлений делаешь?
Доброе. Ну давайте так, вы когда поднимаете 5-6 релизов, вы можете их поднять в конфигураторе, и только там, не запуская предприятие, а потом просто один раз запустить, и система сама вам обновит все данные последовательно, при помощи встроенных обработчиков. Верно? Так чем тогда отличается в этом случае конфигуратор от ЕДТ.
В крайнем случае, если вы вот прям опоздали на столько релизов, что последующие – выпиливают обработчики старых релизов, то вы можете сделать 5 веток и тогда будет выглядеть так.
Вы подняли релиз с 1.1 на 1.2 – послали в облако, ребята вычитывают, контур проверяет.
И пока там все проверяется – вы в другой ветке, на основе этой же – делаете поднятие 1.2 – 1.3, отправляете в облако – и там опять идут проверки и т.д.
Потом – нашли баги, исправили в одном месте – перенесли во все другие.
Либо просто в одной ветке сразу накатываете 5 релизов разными коммитами и тестируете по коммитам, типо в один комит зашли обновили базу, прошли обработчики, потом другой и т.д.
Но чтобы удалялись предыдущие обработчики – это наверное надо прям очень сильно долго не обновляться :)
Вобщем вариантов куча как это делать. И главное – у вас в истории напротив каждй строки кода будет инфа – эта строка добавилась в 1.2, а этот запрос прилетел в 1.3 и т.д.
А в конфигураторе у нас там как – поднял 5 релизов и можешь сравнить только с типовой, и понять где твой код, а где вендора, без версий и всего прочего. И если вдруг, в последнем релизе есть крутой баг – все, назад не вернешься, а в случае гита – просто сделал ветку от нужного релиза, перекинул теда черипиком коммиты новые, подшаманил их, если надо и вуаля, ты откатился. Но с данными конечно надо будет поиграться.
Вобщем это долгая тема :)
3 раза пытался перейти на EDT, в позапрошлом, прошлом и этом году. Каждый раз делаю одно и тоже: скачиваю liberica и сам EDT и создаю новый проект, импортирую в него самую свежую БСП. И все. Хваленый EDT наглухо зависает, при том что у меня нормальное железо – SSD и много ядер. То есть просто импорт тупо зависает, молчу про сохранение данных и запуск отладки. Зачем изучать поделку, которая ни ЕРП, ни УТ – нормально переварить не может? Ну и про devops – очень спорно в статье. Пользуюсь devops-практиками несколько лет, разрабатываю в конфигураторе, ЧТДЯНТ? И тесты запускаем и синтакс-проверки и т.д. и разветвленная разработка в том числе – с внешними обработками так вообще проблем нет с этим, с конфигураций – надо просто “на берегу” договориться о порядке действий и переходах с ветки на ветку. Из файлов конфигурация прекрасно собирается в cf самим конфигуратором, если все используют одну и ту же версию платформы и у всех git одинаково настроен на рабочих местах (crlf vs lf). Я буду рад, если Вы, Дмитрий, меня переубедите прямо сейчас (может и правда наконец то что-то изменилось в лучшую сторону и я просто отстал от жизни и темы), но пока “извините, но нет”! :)
Начнем с того, что посыл в статье был – начните и попробуйте, пусть едт пока просто побудет рядом и поможет отловить какие-то ошибки. Но в Вашем вопросе есть пара деталей, которые важны.
И прошу отнестись к ним как моему личному опыту, просьба не принимать близко к сердцу.
Не могу выдать диагноз без прикрепленных логов, но есть гипотезы. Я думаю, для вас не секрет, что у конфигуратора есть особенности, например, при копировании объектов формировать битые ссылки, которые конфигуратор скрывает или в динамических списках остаются ссылки на удаленные реквизиты. Это ошибки, которые накапливаются постепенно, в типовых это тоже есть. Плюс мусор от доработок. Просто конфигуратор все это скрывает от нас. В общем, в конфигурации постепенно накапливаются ошибки, они не “убивают” конфигурацию (до поры) – но они есть. И когда мы внедряем на проекте ЕДТ – мы с этим сталкиваемся и начинается этап вычистки конфы от багов конфигуратора. Возможно, у вас этот случай, надо смотреть логи. А может просто криво стоит джава, или еще что-то.
Я работаю с ЕРП и УТ11, что я делаю не так? И не только я. Недавно был закрыт проект, где в ЕДТ затянули УТ11 шести или семи летней давности и работают 20 разработчиков с ней. Или поспрашивайте, например, в официальном чате по EDT https://t.me/e1c_edt, сколько людей уже работают с типовыми. И все норм. Так что мне тяжело понять, что у вас именно не получилось. Мало того, в курсе – 5 модуль именно про то, как развернуть ЕРП в ЕДТ. Я специально выбрал ЕРП, и сделал два замера на виртуалке для двух довольно слабых компьютеров. И даже там, пусть и долго, но ЕРП спокойно себя чувствует. И это прямо видео, где я включаю замеры показателей, и вы можете сами посмотреть, какая нагрузка идет на комп (конечно в ускоренном режиме) – и оно работает. И обновляет, и импортирует, в общем я не сталкивался с тем, что я когда-то не смог что-то загрузить, даже больше – я специально искал такой кейс, чтобы показать на курсе. Я понимаю, что звучит как “у меня такая-же нога, но не болит”, но тем не менее, есть факт – ERP на EDT вполне работает. Да, я помню, раньше были баги, но сейчас их вполне себе пофиксили.
Ну, скажем так, Вы делаете не так только одно – тратите впустую кучу времени ваших специалистов, ваших релиз инженеров, и усложняете людям жизнь. Без обид, но такие “костыли” я видел не раз.
Люди начинают выдумывать какие-то чудеса с внешними обработками, расширениями, или просто забивают – и все пилят в ядре, с фразами “мы не верим внешним обработкам и расширениям”, что забавно, конечно. Т.е. неудобный инструмент в виде конфигуратора заставляет людей ограничиваться только монолитом. И это грустно.
DevOps DevOps’у – рознь. Есть девопс для девопса, а есть девопс для работы. Если есть какие то, процитирую вас:
договоренности, то это не девопс (прошу, без обид, это лично мое мнение).
Почему? Потому что девпос – не про договориться, а потом надеяться на то, что все работают без отклонений. DevOps – это автоматизация и контроль. А когда есть просто договоренности – то это про человеческий фактор, который всегда генерирует ошибки и которые как раз девопс должен автоматически обнаруживать.
Вообще, при нормально развернутом DevOps-контуре человек вообще не должен иметь возможности налажать.
И эта штука не должна зависеть от того, кто именно выполнят работу. Если вы лично помните все правила и их соблюдаете – но завтра покинете эту компанию, а вместо вас возьмут кого-то еще, то компания не должна из-за этого закрыть все эти практики. А такое происходит, когда все держится на одном-двух сотрудниках.
С Вами описанным подходом я могу согласиться при работе с обычными формами, но в случае управляемых – это какое-то изобретение велосипеда с восьмиугольными колесами.
Ну и как предложение, если у вас есть желание, можем договориться о встрече и похоливарить, просто каждую неделю через меня проходит 2-3 компании, которые думают так же, как и вы, и оказывается, что они думают неправильно. Я думаю, что у вас другой случай, и мне было бы очень интересно про него послушать.
Все равно все очень спорно. Не хочу растекаться, но любой тезис можно оспорить. Применять devops можно и без EDT вполне спокойно. Писать тесты разветвленно можно и в конфигураторе, легко и непринужденно и неважно какие формы при этом, а выгоды от веточной разработки самой конфигурации не так очевидны, как Вы позиционируете и далеко-далеко нужны не всем, даже крупным командам. В материнской 1С то еще не все отделы перешли на EDT, а те что перешли, тот же 73-й например, тот самый что и пилит ЕРП – так как-то не особо это на качестве кода в ней сказалось… Просто сейчас все кому не лень произносят волшебное слово devops и народ бежит смотреть, что же там за зверь такой, а потом выясняется, что зверь этот им не в кассу ни разу. Ну да ладно, речь не об этом. Вы на курсе разбираете все эти проблемные моменты – неожиданные краши, что может их вызвать (какие действия) вылеты с нехваткой памяти, покажете где логи читать, сколько яве памяти дать и т.д.- вот это все будет? Краткая выжимка из “официального канала”, грубо говоря?
Сразу определимся – курс не про то, как настраивать девопс. Хотя, курс про то – как к нему прийти и то, как это будет выглядеть в конце, когда девпос уже есть.
Т.е. все тезисы которые я освещаю на курсе – я стараюсь потдтвердить результатми, которые вы достигните потом. Т.е. как бы подготовка к девопсу.
Краши, котрые я смог словить и воспроизвести – я показываю и рассказываю. Конечно, в курсе говорится про необходимую память, как ее изменять, смотреть. Где логи, как их найти и как их читать.
Но увы, у меня не получилось воспроизвести ни один критический баг EDT. А те что получалось – уже были исправлены в тестовых версиях, поэтому писать про них не было смысла.
С другой стороны, по разветвленной разработке – буквально сегодня общался с компанией где всего лишь 5 разработчиков и ерп на борту. И они пришли к нам именно из-за необходимости в разветвленной разработке, и это одни из десятков.
Давайте так, хранилище – это по сути SVN, в SVN можно реализовать концепцию веток – безусловно. Но когда появился git – от svn начали избавляться максимально быстро, прям за пару лет git занял 80% рынка. Почему?
Стоимость создания веток в хранилище – очень высокая, вот прям капец какая высокая, это и объем хранилища, и его подготовка и объем его бекапов, и отсутствие кода ревью (на простом уровне).
Т.е. мы сами, как двигатели 1С – рассказываем клиентам о том, что переходите на управляемые формы, там вам и мобильный клиент, и веб клиент, и не нужны это RDP, а сами при этом, с точки зрения разработки – сисдим на 7.7. И тут вопрос – 7.7 плохая? Нет. На ней можно вести учет – да. Но почему на ней уже почти никого не встретишь?
Очень хорошо все расписали, до этой статьи и не думал запускать EDT, а теперь обязательно пробую!
Спасибо за высокую оценку работы наших авторов. Надеемся, Вам была полезна статья и пригодятся новые знания.
Добрый день. Курс меня заинтересовал. Но для его прохождения какие требования к компьютеру и среде для работы? Смогу ли я, например, просматривать видио на неттопе (курсы купленные у Вас ранее на нем идут, но у Вас плеер обновляется). И какие минимальные требования к рабочему компьютеру на котором будут выполняться задания.
На счет видео, сказать мне сложно, пусть коллеги дополнят.
А на счет остального – смотрите просто на страницу минимальных требований ЕДТ. Работать можно и с демо конфигурацией (которую можно скачатьс ИТС в разделе платформы), для выполнения ДЗ и повторения действий.
Но если брать прям минимальные – то это наверное 4 ядра и 4 Гб RAM. Но, можно и меньше, однако, надо будет готовится к тормозам :)
Дмитрий, день добрый! Сейчас планирую апгрейд, нужно железо (ноут), которое потянет EDT (с учётом его немалых аппетитов). Что будет лучше для этого – core i7 10 или 11 gen (мобильные версии) или AMD Ryzen 7 PRO 4750U 8 x, обязательны ли 32 Гб оперативки?
Доброе. Смотря с какими конфигурациями будете работать.
У меня компьютер на Core i7 6700, и 32Гб оперативки, но крутится все в виртуалке где 16 Гигов. И ЕРП тянет без проблем.
Главное диски должны быть NVMe :)