Как стать автором
Обновить
15
0
Ingvar Vilkman @ZEEGIN

Программист

Отправить сообщение

В 1с можно наследоваться от базовых классов, в данном примере Организация, Контрагент и ФищЛицо это классы унаследованные от базового класса Справочник. Или проще — это справочники.


В каких случаях для какого решения надо от каких классов базовых наследоваться можно почитать в стандарте:
https://its.1c.ru/db/v8std#content:683:hdoc


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

Ну прям очень странно так говорить.
Открываешь справочник внедренных решений, содержащий отчеты от фирм партнеров и смотришь.


Любому клиенту или внедренцу можно позвонить и спросить действительно ли это так.


http://1c.ru/rus/partners/solutions/search.jsp?q=&Version=8&workingMode=2&dbServer=2&small=&big=&smallDbConns=&bigDbConns=&smallThinClientConns=&bigThinClientConns=&smallWebClientConns=&bigWebClientConns=&labelgeo_id=&geo_id=&DateSince=&DateTill=&isArchive=1&showParams=0

Вы были на последнем инфостарте?
Сейчас про докер едт и системы сборки не знает только совсем темный и ленивый.

Архитектура и паттерны не относятся к java. Это фундаментальные знания.
Байт код мидлу нахер не нужен.
Принципы построения многопоточности во всех языках похожи.
Библиотеки всегда учатся только те, которые нужны. В целом одна дополнительная библиотека осваивается от 2 часов до недели.
Градл мавен докер надо понимать, но чем это
отличается от других сборщиков? мидлу не обязательно лезть в дебри. Надо уметь настраивать сборку и понимать последовательность. В 95% случаев за сборки отвечают более опытные разработчики, чем среднестатистический мидл. Ну а докер вообще к яве не относится. Предполагается что ты его уже знаешь! Все ведь запускали 1с и edt в докере, нет?


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

Как показывает практика нормальный 1Сник осваивает java на уровне хорошего мидла за неделю.
Смотреть здесь https://github.com/1c-syntax/bsl-language-server

Как много IT компаний обеспечивают трехразовое питание за счет компании, пусть даже в не очень хорошей столовой? :)

На самом деле все не совем так, давайте рассмотрим типоой сценарий:


  1. Есть 1С некоторая, допустим УТ или УНФ.
  2. Есть портал самообслуживания, допустим самописный на питоне.

Надо сделать интерацию.


Как делать правильно?


  1. Описать протокол обмена, спецификацию пакетов, потоки данных, описать сценарии сущностей базы для автоматического разрешения конфиликтов.
  2. Написать 2 адаптера, один из 1С в формат и второй из питона в формат. Т.е. тупо сериализатор и десериализатор, без какой-то бизнес логики.
  3. Написать тесты, которые автономны и которые тестируют только сериализатор и десериализатор на эталонных пакетах.

Почему надо делать так? Потому что обычно команды разработчики — разные. Обычно — владельцы (по скраму) баз данных 1С и сайта тоже разные. Обычно, кроме проектов интеграции есть очень много внутренних проектов, которые не должны влиять на обмен никоим образом.


Как доработать обмен?
Надо открыть техпроект доработки, уточнить спецификацию, доработать два адаптера каждой из сторон.


Как доработать 1С?
Просто доработать, но если будет затронуты объекты участвующие в обмене — достаточно только внутри 1С адаптер уточнить, благо тесты по нему уже написаны. И это самое важное! Не нужно дорабатывать вторую сторону.


Что предлагаете сделать Вы?
Не использовать адаптеров. Вместо спецификаций использовать описание объектов базы данных 1С. Данный подход хорош только в случае, когда 1С никода не будет дорабатываться, потому что в случае доработки объектов метаданных спецификация принимающий стороны на сайте станет отличаться от того, что есть в 1С. Даже после простого обновления 1С на новый релиз могут возникнуть множественные переименования, что моментально потребует доработку сайта, потому что изменилась спецификация. И чаще всего эту доработку будут вынуждена делать группа не 1сников. Т.е. для элементарной задачи обновления 1С нужно будет привлечь группу вебберов для решения последствий этих обновлений.


Потому очень важно контракты оставлять "за 1С". Потому Odata не любят для решения задач иных кроме грабберов данных. Потому 1С в свое время придумал EnterpriseData. Потому обмен с сайтом делают не прямыми вызовами а соблюдая протокол CommerceML.

Первое:


Когда делают интеграции, обычно стараются выделять программный интерфейс, апи, то описание протокола передачи, которое будет неизменно и документированно для систем интеграции. Обычно это или описание пакетов не важно в каком формате, xdto, xsd, или спецификации для построения rest. А может быть это описания пакетов для RabbitMQ или Apache Kafka. Главное, что это описание есть.


Зачем это нужно? Для того чтобы внеся изменения в одну из сторон обмена не нужно было вносить синхронно изменения в другую сторону. Для того чтобы доработку обмена надо было делать техпроетом доработки, когда это реально нужно, а не всякий раз когда одну из систем обновляешь на новый релиз (внутренний или внешний).


Второе:


Вызов на сервере произвольного кода с клиента — это нарушение безопасности и нарушение стандартов разработки 1С. https://its.1c.ru/db/v8std#browse:13:-1:36


И не важно клиентом тут является тонкий или веб клиент 1С или Soup клиент подключенный к веб-сервису. Позволять вызывать произвольный код нельзя. По крайней мере надо хотябы безопасный режим устанавливать.


Третье:


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


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

Да это и грустно и смешно)
То, что в этой статье представляется как что-то новое реально в 1С используется уже 20 лет)) А потом говорят они, на русском пишут, на русском))

Представляю как вы удивитесь, когда увидите, как в 1С модели бэкенда, фронтэнда и в бд меняются синхронно в конструкторе описания объекта, вообще без изменения кода ;)

Реализована возможность анализа метаданных, расположенных в файлах .cf или .cfe. Реализован конструктор для объекта ОбъектМетаданныхКонфигурация.
Реализована возможность получения имени конфигурации, номера версии и поставщика на основании файлов .cf или .cfe. Реализован объект ОписаниеКонфигурации.


Реализована возможность получить из файла .cfu список версий конфигурации, которые могут быть обновлены данным обновлением, а также версию конфигурации, которая получится в результате обновления. Реализован объект ОписаниеОбновленияКонфигурации.


Источник: http://downloads.v8.1c.ru/content//Platform/8_3_14_1494/1cv8upd_8_3_14_1494.htm#788ec9ef-0bf9-11e8-a3f7-0050569f678a

Я имею ввиду возмодность читать дерево метаданных прям из файлов cf и cfe во встроенном языке в 8.3.14.

В 2011 (судя по скриншоту) это было актуально. Сейчас — кажется не очень.

Вы же знаете о сонаре? У них отличная политика, есть бесплатное использование, есть платное. В платной разумные ограничения которые нужны кровавому энтерпрайзу.
https://www.sonarqube.org
https://sonarcloud.io


Вообще иметь бадж на пвс онлайн с результатом проверки и отчетом будет здорово.

Для сведения: Группа стандартов разработки 1С в телеграмме @v8std


Участились случаи, когда поставщики своих расширений в инструкции по установке предлагают снять типовую конфу с поддержки и отключить режим совместимости с платформой.

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

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

Делать такое для экспериментов в лаборатории — ОК. Для продуктовой базы — слабоумие и отвага.

А на линии консультации вам ответят типовой формулировкой про несоответствие условий эксплуатации заявленным требованиям.

Не ведитесь.

Наверное разработчикам конфигурации надо быть экстарасенсами, чтобы угадать как в новой версии платформы будет назван какой-нибудь новый метод.


Конфигурацию рассчитанную на работу с 8.3.10 писали в 2016 году. 8.3.12 появилась в 2017 году. Как разработчики могли в 2016 узнать имя метода, которое появилось в 2017?


Дайте ссылку на документацию битрикс, я им напишу об ошибке у них.

В документации
Форматы навигационных ссылок


<адрес хоста ИБ>#<внутренняя ссылка>


<адрес хоста ИБ> = ПолучитьНавигационнуюСсылкуИнформационнойБазы()


<внутренняя ссылка> = e1cib/data/<путь к метаданным>?ref=<идентификатор ссылки>
<идентификатор ссылки> = СправочникСсылка.<Имя справочника>.УникальныйИдентификатор()


Например,
e1c://filev/C/1c/db/trade/master#e1cib/data/Справочник.Партнеры?ref=aca00015e9b8c48d11dd4412f8fa030d


Лол, как можно так тупить.
В версии 8.3.10 не было ПобитовоеИ, в версии 8.3.12 есть ПобитовоеИ.
В версии 8.3.10 не конфликтует. В версии 8.3.12 конфликтует.
Не надо менять режим совместимости чтобы не допускать возможных конфликтов.
У разработчиков типовой все в порядке. Они заявили что работает в 8.3.10. В 8.3.10 она и работает. В 8.3.12 работу никто не обещал.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность