Transcription
Мы в эфире. Всем привет. Жень, привет. Сегодня мы >> Привет, привет. >> Сегодня мы собрались на радио Инвар для того, чтобы поговорить о том, а какие есть библиотеки в 1нс, какие есть библиотеки в мире и почему всё происходит именно так, как оно происходит. А с нами сегодня гость - это Евгений Кузнецов. один из крутейших разработчиков компании Биотех. Жень, привет. Расскажи себе.
>> Привет- привет. Меня зовут Дженя Кузнецов. Я старший инженер отдела исследования разработки в компании Bioteотеchnologies. А среди прочего мы разрабатываем нашу собственную БСПшку корпоративную, ну и занимаемся различными исследовательскими задачками. И там подружить Одинску с какой-нибудь неведомой штукой.
>> Угу. Отдел RНD - это прямо исследование разработки.
>> Да. Да. Периодически поступают задачки формата. Нам нужно подружить Одинаску с чем-то там. Мы её дружим. Различные волтыки, клаки и так далее. До того, как это стало мейнстримом, начинает появляться на инфостарте. Так или иначе, мы сталкиваемся с подобными задачами.
>> В том числе благодаря вам попадает на инфостарт в виде докладов, которых от биотека бесчисленное множество. Да, да. Ну тот же янит был разработан же внутри нашей команды Лёшей >> и тоже >> капятиным >> и RД, естественно, >> и Red тоже разработан биотехом. Як конечно потрясающий инструмент и в очень достаточно популярный же >> популярнейший инструмент примит for oneeg.
>> Угу.
>> Нашим форком, по-моему, тоже пользуется много народу. Ещё не особо >> ДТ рипер ещё >> с ним. Честно, я видел его только в списке наших репозиториев. Что это такое? Даже не представляю.
>> Ну я использую прямо активно. Очень-очень интересненький и хороший инструмент. Он мэптит между собой правила едтэшных проверок и формата Санаровского для загрузки в Санар.
>> А, ну да, я вольновольно пользуюсь им, когда получаю отцена. Замечание. О просто работает. [смех]
>> Оно просто работает, да.
>> Оно просто работает, да.
>> Так вот, давай чуть-чуть поговорим о библиотеках. Что такое вообще библиотеки? Зачем они нужны? Ну вот как-то же возникает задача, да, создать библиотеку. И вот тут я даже на заставку поставил библиотека имени Ленина. Какую именно мы библиотеку имеем в виду? Расскажи что-нибудь про библиотеки.
Ну, в нашем случае мы библиотеке шарим некий функционал, который пользуется в достаточно большом количестве различных эсных баз. Ну, какие-то наши бизнес-фичи, присущие нашей компании. То есть помимо общего функционала, типа общего назначения модуля, там типовой БСП, а у нас в библиотеку идут, э, механизмы, которые именно внутри нашей компании используются, какие-то определённые интеграции, специфичные, интеграции с каким-то специфичным по какие-то справочники универсальные. Там у нас есть справочник константы.
>> [смех]
>> Мне кажется, сложно найти компанию, которая бы не делала свой справочник констант. Ты просто не видел его размера.
>> Видел >> или или видел?
>> Я я же работал в биотехе >> до того, как устроиться в 1нс. Я же работал в биотехе, потом увидел.
>> Ну тогда ты, да, примерно представляешь.
>> Правда, это, ну, давно было, сколько лет уже прошло. Это получается, слушай, ну, 10 лет прошло, да, как я ушёл из пятьх, уже много прошло времени. лет много-много.
Так, мм, давай мы с тобой пошутили, посмотрели, что библиотеки они такие. А в целом они нужны для того, чтобы какой-то общий функционал переносить между разными конфигурациями. Вопрос. То есть получается, это всё нужно только тем, кто как бы разрабатывает свои библиотеки. Это нужно только тем, кто разрабатывает много своих продуктов.
Ну, если это речь идёт о библиотеках внутри компании, то да. Но мне кажется, всё-таки бо большая часть библиотек в других языках, она openсорсная. История такая. То есть мы своей библиотекой её не шерим, мы закрываем наши потребности.
>> Для это библиотек, на самом деле, их, ну, не так-то и много.
>> Вот из таких публичных мы там знаем, пока все знают, да, БСП, там есть библиотека технологий сервиса БИП, >> да, библиотека электронных документооборотов, библиотека рекчётности, всякие интеграции, вот эти МДЛП, вот это вот ещё куча разных непонятных словосочетаний. интеграция с документами, но это же всё-таки содержит в себе огромное количество функционала. То есть, ну, библиотеки в других языках, они не настолько огромные, >> они какую-то маленькую функцию выполняют.
>> Мне кажется, этот вопросик надо задавать не мне. [смех]
>> Ну хорошо, а у вас библиотека большая?
>> Мм. М, не маленькая, блин, я не знаю, сколько у нас.
>> Ну, достаточно. То есть у нас её развивает на текущий момент примерно четыре человека нон-стопом. Что-то в ней дорабатывает, улучшает.
>> Угу.
>> Поэтому достаточно объёмная под наша задача.
В чате сразу спрашивают: "А а как же библиотека 1Sконнектор, которая от Бондаревского? Она же маленькая.
>> Она великолепна, я считаю.
>> Мне кажется, выделить всё, что только можно, и упаковать это в один модуль для того, чтобы поставлять только один модуль, это просто гениально и просто, >> да, это классно. Он ещё и написано.
>> Добиться добиться такого эффекта очень сложно. И возможно это только для каких-то таких вот абстракционных подсистем, которые чистые SДК и то, где тебе не нужно ничего промежуточно у себя хранить. Вот если бы в той же коннекторе нам пришлось что-то сохранять внутри, например, в какой-то наш собственного формата лог, либо интеграцию с какой-то внутренней подсистемой делать того же журнала регистрации, которой в коннекторе очень не хватает, потому что коннектор дампит журнала регистрации всём подряд. в том числе чувствительные данные. А эти данные потом уже администратор может прочитать, да? А это на секундочку уязвимость, от которой нужно избавляться, потому что должна быть маскировка чувствительных данных до записи в журнал регистрации. Вот. Или когда какой-нибудь объект нужно преобразовать с поиском по базе, например, даже подсистема мм какого-нибудь нечёткого поиска, ты просто так её уже не сделаешь. За тебе запросы по базе нужно фигачить. Ты очень много должен знать о конфигурации. и не упакуешь её. А если тебе поставлять какой-то объект нужен, это ещё больше.
>> Ну это да, но это же всё-таки, ну, по большей части упирается в какие-то требования уже крупных компаний, а, ну, подавляющему большинству пользователей, которых полностью коннектор устраивает, они его себе залили и используют. как бы им не нужна вот эта вот вся история с маскированием данных, логированием в какие-то внешние таблицы, накруткой ещё каких-то там правил безопасности поверх этого. Просто клиенту закинули коннектор и спокойно интегрируешься с различными HTP-сервисами вообще без каких-либо проблем.
>> А то, что когда произойдёт ошибка, это всё в журнал запишется, а потом из журнала можно достать, >> это уже не проблема. Ну, будем объективны, насколько кому-то нужен какая-то конфиденциальная инфайлерка, который продаёт что-то там, не знаю, магазин на маркетплейсе, у тебя там идёт какая-то выгрузка твоих товаров. Ну, господи, кому нужны твои логи? То есть это же надо целенаправленно запариться там атакой на компанию, там как-то долезть до базы, стянуть её себе. Ну не знаю. Мне кажется, подавляющему большинству это не смотри, там проблема-то не в том, что ты должен делать какую-то атаку на базу. Мы сейчас, конечно, от библиотек, да, отошли, резко пошли вот в infфобес, но там суть не в том, что ты можешь должен делать атаку на компанию, вообще проникать в её контур. Тут проблема в модели нарушителя, то, что человек, который вводит данные о паролях, это может быть не тот, кто имеет право читать журнал регистрации. И читать журнал регистрации - это более широкая роль, чем роль администрирования безопасных данных. Вот в чём суть. В этом плане возможно, да, >> коннектортека, >> да, конечно, конечно, она предоставляет какой-то общий функционал и позволяет достаточно легко себя встроить в систему, конечно, библиотека. Я вот помню отлично, что самые-самые свои первые встройки и вообще там на разработке какие-то на БСП я делал, как я открывал один конфигуратор, второй конфигуратор и просто перетаскивал объект с одного окна в другое окно. Он копировался и заводился. После этого вычитывал код, проверял, что он работает. Мм, сейчас всё делается чуть-чуть по-другому. Что ты думаешь о том, как сейчас поставляются библиотеки?
>> У нас >> в 1С или вообще >> вообще [смех] в других языках есть великолепные механизмы типа менеджеров пакетов, где есть возможность всё это автоматически скачать, включая зависимость и так далее, как бы. А мы, ну, в том числе я вынужден работать вот с этими огромными монолитами библиотеческими >> и перетаскивать из окна в окно.
>> Ну, примерно, да.
>> Ну, то есть у нас получается основной сценарий - это мы смотрим, как сделано в примере, и пытаемся к себе скопировать, изменить на ходу.
>> Да, ну, на самом деле, мы не так уж много копируем чего-то. Всё, что мы хотели скопировать, наверное, уже давно было скопировано. Сейчас в основном это разработка какого-то нового функционала, доработка старого, выпиливание старого. То есть не помню, когда я последний раз сидел и копировал бы что-то откуда-то.
>> Обычно что-то новое.
>> Обычно что-то новое, конечно. А >> вот когда эту библиотеку будут встраивать в >> уже готовое решение, они будут твоё копировать?
Ну, у них есть мы выдаём им поставку, они вольны использовать нашу поставку, чтобы обновиться. Но на самом деле это достаточно часто сталкивается с суровой реальностью, когда ребята вынуждены там сидеть сравнением, объединением, там учитывать доработки на доработке, на доработке на БСП, на нашу. Вот поэтому такая история, мне кажется, у нас, ну, в рамках нашей компании, я могу только за неё судить, ээ, достаточно часто ребята, как им удобно, так и обновляются. То есть у всех какие-то свои приколы, у всех разные версии Одински, у всех разные интерфейсы, там обычные управляемые. Э, опять же, мы выпускаем там несколько разных версий BSP. У нас есть BSP, которая, э, полная. У нас есть БСП, которая подразумевает встройку в какие-то типовые конфигурации, у которых есть своя БСП.
Что >> иногда приходится решать вот эти вот Да, да, чтобы общего назначения модуль не конфликтовал с модулем общего назначения. [смех]
>> Зачем вообще модуль общего назначения нужен? Ну, если ты не знаешь, куда засунуть метод, ты суёшь его назначения. [смех] Несу его. Несу его. Вообще >> не. У нас в правилах написано в общем назначении ничего не совать. Мы его наоборот потихонечку, потихонечку растаскиваем по другим модулям. И периодически из этого рождаются там какие-нибудь модуля в стиле модуль универсальной коллекции, там модуль строковый и так далее. Конкретно, когда я работал, мы стараемся потихонечку растаскивать, да, >> общего назначения и строковые функции - это те вот модули, за которые я отвечал, да, там разработку вот этих самых получения реквизитов объекта, вот это вот, да, там сократить массив и вот это вот всё. И м >> так и есть, >> что я думаю, я думаю то, что очень плохо то, что общего назначения - это такой очень большой модуль, который вообще существует. Это очень сильно сбивает с толку. И плохо, когда в модуле очень много функций разного назначения. Они там разделены, разделены по каким-то областям, но тем не менее это разделение по областям хоть чуть-чуть помогает быстро найти, что там есть. Вот. Но тем не менее хочется иметь много разных модулей, более маленьких, чем один гигантский.
>> Да, так и есть. Ну, опять же говорю, у нас задача просто, скорее всего, ревью не пройдёт. Если ты захочешь насвенячить модуль общего назначения с каким-то новым методом, тебя скорее потом заставят ещё распиливать это общего назначения вместе с твоим методом новым.
>> Ну раз залез, значит [смех] быть готов.
>> Ну это вообще база, типа ты потрогал модуль, будь добр и справь всё, что ты в нём нашёл плохого. Очень помогает держать относительный порядок. Ну вот смотри, вот на мы получается вот как раз вот этот конфликт мы сейчас и потрогали, что с одной стороны общего назначения он большой, он один, им пользоваться неудобно, потому что всё вместе, но если мы начнём его дробить, у нас получится очень-очень много модулей, которые нужно вместе каким-то образом поставлять. А поставлять их вместе это неудобно, потому что тебе нужно много чего миржевать через поставку, что в итоге оказывается лучше иметь один модуль, которым не очень удобно пользоваться, но который легко обновлять, или иметь много-много модулей, которые сложнее обновлять, но при этом пользоваться ими будет удобней, >> мне кажется, что так, что так. Какие-то свои проблемы у всех. Потому что, когда у тебя много маленьких каких-то модулей, то у тебя функционал может быть завязан абсолютно на разные версии этого модуля. То есть вот этот вот dependency hell, который возникает в других языках.
>> Что это такое? Это когда у тебя огромное количество зависимостей, когда у тебя одна библиотека зависит от другой библиотеки, которая в свою очередь зависит от трёх других, которые в свою очередь зависит от 10трех. И это всё превращается в какое-то огромное количество библиотек. А ещё все они между собой зависят по диапазону версии, а не просто так, [смех] >> да, >> потому что с повышением какой-то одной версии у тебя часть цепочки отваливается и строится другая цепочка, потому что кто-то где-то >> Я скорее больше наслышан об этой проблеме. Я скорее больше наслышан об этой проблеме, чем я персонально сталкивался с ней. Вот. Но тем не менее проблемы существует, и от неё никуда не денешься. А у нас сразу в одной поставочке всё затащил, всё на месте. Всё нужных версий. 200 м джаваскрипта груз текста 300 байт. Я что-то не очень понял. Что ты имеешь в виду? Александр Янк там пишет. Ты имеешь в виду то, что после того, как всё скомпилируется, у тебя так получается? Ну, наверное, >> а про dead dependenнcy hell, что они ценят про то, что в зависимости куча ценнится.
>> В итоге получается очень интересная ситуация. У нас есть библиотека, в которой под сотню разных функциональных подсистем, но при этом каждая из этих подсистем, она вроде как почти независима, но внутри она тоже может зависеть от каких-то других подсистем. И пока они поставляются одной версией, вот эти все внутренние зависимости, на них просто можно положить и не мучить людей, которые её используют, потому что ты поставляешь их вот таким скопом, одним объектом. Вот этот тебе релиз, он внутри работает нормально. Это похоже на то, как м ты можешь там Убунту дайте и сказать: "Ребята, вот поставьте пакет, у тебя там всё, что в репозитории, оно между собой совместимо". Вот. А с другой стороны у тебя получается, что тут есть 100 подсистемы с БСП, ещё там 70 подсистемы с бипа ещё там в итоге общей сложности может быть 400 подсистемо. А если каждую из них поставлять независимо, то это будет 400 разных версий, которые все между собой связаны по зависимостям где-то. Причём зависимость у тебя будет удобнее. Поставлять.
>> Да ну, ты типа просто подшаманил свою маленькую библиотечку, выпустил новую версию, а что там у кого сломается, ну, типа, сами разберутся.
>> Ну, это удобно для тех, кто что-то маленькое только и делает.
>> Ну, разобра >> для тех, кто большое что-то делает. Сейчас такое дерево зависимости. За этим приходится самостоятельно следить на текущий момент. Плюс ещё возникает такая проблема, что, а, ребята могут, ну, пользователи наших библиотек, ну, так как я хожу в офис, общаюсь с людьми, так или иначе, ну, бывают такие ситуации, когда люди там какой-то критичный функционал вот они получили по БСП ну, ээ, из нашей библиотеки, но он их там чем-то не устроил. А бюрократическая машина достаточно медленная, релизный процесс очень большой, и ребятам бывает проще просто пропачить наши модуля, добавить какой-то своей логики и дальше с этим жить. Вот. Потом они ещё парочку раз забивают обновление релиза. И дальше возникает уже вот та вот сложность. Не то чтобы Dependency Hell, но тем не менее, когда они получают какие-то изменения, которые зависят от версии модуля бспэшного, который они поменяли, он у них выглядит абсолютно по-другому. И в итоге это всё тянет за собой проблемы вот именно ребят на местах, которые обновляют эти библиотеки.
>> А ты сам пробовал обновлять библиотеку >> нашу?
>> Конечно. [смех]
>> Нет, нет, спасибо. Раньше, по-моему, эта обязанность была на нашем отделе, но я пришёл, когда с насли >> Мне кажется, то, что, чтобы писать хорошо библиотеки, ты обязательно должен её внедрять, потому что именно тогда ты понимаешь всю боль и начинаешь делать для других очень хорошо. Когда я делал библиотеку распознавания документов, я вот конкретно процессов встройки в бухгалтерию её делал, потому что это как раз очень-очень сильно, знаешь, заставляет тебя делать её получше для встройки. Насчётн Hell и вообще вот этого расчёта Dependcy.
>> Если посмотреть на чисто BSP, на самом деле в БСП уже в рамках её внутренних вот этих подсистем, а дерево dependency есть. Есть обработка первоначального внедрения. И когда ты её запускаешь, у тебя оказывается, что вот это дерево зависимости, оно встраивается, но оно встраивается тебе в режиме, когда тебе первое внедрение БСП показывает, как безопасно выбрать, какие подсистемы ты можешь использовать, чтобы у тебя после этого БСП не развалилось. Ну, то есть от вот этой подсистемы, если я откажу, делают частичное внедрение БСП, да, я помню этот >> огромный документ, который говорит, что тебе нужно ещё подшаманить, чтобы оно завелось. Ну >> вот прямо в обработке они сделали несколько уровневое вот это дерево, которое тебе показывает, что если ты вот эту подсистему отщёлкиваешь, вот эти у тебя тоже отщёлкиваются. А если ты эту добавляешь, он ещё и зависимости добавляет автоматически. М. И тут получается такая интересная штука, что за счёт того, что они все у тебя в рамках одной поставки, тебе между собой их согласовывать можно легко. Разные подсистемы. Есть такая интересная штука, которая называется, а, условный вызов. Вы у себя используете условные вызовы? Это когда ты сначала проверяешь, существует ли подсистема. Если она существует, только тогда её дёргаешь.
>> О, нет, нет, мы избавлены от этого, потому что, ну, всё-таки наша библиотека тиражируется не такое большое количество систем, как библиотеки фирмы 1С. И мы можем позволить себе определённые вольности, типа мы просто внедряем всю БСП. Никаких делений на подсистемы, типа просто всё. тяните. Вот если вы что дотянули, ну, этим планом, живите с этим, [смех] >> типа полностью или не так.
>> Ну, типа, ну, типа, почему бы и нет? Наверное, ещё стоит отметить, что наша библиотека, она не привносит каких-то, ну, какого-то большого м количества интерфейсных деталей.
>> Угу.
>> Вот. Если ты типовую БСП внедряешь, там огромное количество каких-то интерфейсных штук, у тебя там появляются подсистемы, какие-то интерфейсы, настройки и так далее, у нас это в меньшей степени. У нас все настройки сконцентрированы, условно в одном месте, откуда можно там походить по соседним и, ну, это не вызывает перегрузки интерфейсов под системами. Можно просто всё тянуть и не париться. Угу. С другой стороны, ну, допустим, даже если бы мы внедрили такое деление на подсистемы, вот это вот частичное внедрение, ну, блин, это же нам потом придётся поддерживать, а это опять же люди, ресурсы.
>> Просто очень часто я слышу, >> уже больше вопрос, как как это ещё бизнесу продать. Библиотека слишком большая, даже делая частичное внедрение, в ней много кода, который на самом деле не нужен, да, потому что он делает те самые условные вызовы, проверяет подсистему, которая не в итоге не существует в твоей поставке, потому что ты её вырезал. И за счёт этого у тебя получается много вот этого мёртвого кода, который, ну, вроде как не нужен.
>> Ну, он лежит, есть, не просит. Почему бы и нет? На фоне объёма баз. Есть такое отношение у некоторых программистов, что код должен быть чистым, даже код библиотечный, который ты используешь. И когда ты что-то к себе перетаскиваешь, ты должен это прямо очень-очень сильно вычистить. Как ты к этому относишься?
Ну, как бы наши желания и реальность очень часто расходятся. Мне тоже хочется видеть везде чистый код, но как бы его же не организовать везде, потому что всё равно остаются какие-то старые шмётки, там что-то ты не можешь просто взять там и перефигачить какую-то подсистему, потому что на неё там у кого-то целая куча завязана, и ты там у себя, ты такой весёлый, заходишь в модуль, себе какие-то мелкие методы перелопатил, тебе хорошо, они там стали симпатичные, красивые, а потом ребята тянут это обновление себе в базу. У них там регрессионное тестирование на сотни часов после изменения этих модулей, как бы. Ну, тоже нельзя просто так взять и всё сделать по красоте. Приходится, >> ну, если мы будем давать просто весь наш код открытый, чтобы его полностью так, как хотят, вызывали, мы себе руки свяжем на то, чтобы потом что-то поменять.
>> Ну, мы же сейчас это регулируем нашими областями. Пишем программный интерфейс. Пожалуйста, его используйте. Все остальные области на свой страх и риск.
>> Ты сейчас про программный интерфейс?
>> Я сейчас Ну да, про программный интерфейс.
>> Угу.
>> А до этого мы говорили про пользовательский интерфейс. Мы его частично зацепили.
>> Там люди пишут >> о том, что а после обновления библиотеки не должно ничего ломаться, ведь интерфейсы же не должны меняться, контракт должен сохраниться. Разве не так? Вот мы сейчас говорим про программный интерфейс, который является контрактом, >> но при этом у тебя очень сильно идёт разница между пользовательским интерфейсом, который библиотека поставляет, >> да, и программным интерфейсом, которые библиотека тоже поставляет. И у тебя есть какие-то подсистемы, которые поставляют вообще фрагменты пользовательского интерфейса в виде программного интерфейса. Ты должен в свою форму его как-то по-особенному вызывать. А ещё и как-то по-особенному потом выбирать, как это обновлять. Потому что если что-то меняется в программном интерфейсе, который рисует пользовательский интерфейс, то у тебя всё может взорваться вообще в любой момент. Я просто периодически вижу такие изменения, как мы изменили формат функции, теперь сюда передавайте не этот объект, а вот, пожалуйста, элементы. И после этого у тебя бабах, и половина форм перестали открываться.
Ну мы опять же, как ээ мы же сами пишем БСП, мы не придумываем себе лишние проблемы в поддержке, поэтому вот таких интерфейсных частей у нас немного. Там условно динамически подключаемые команды, адреса и прочие мелочи. Они не сильно объём. Ну, они совершенно не настолько объёмные, как в типовой БСП. То есть мы всё-таки больше занимаемся именно программными интерфейсами, которыми в дальнейшем разработчики пользуются.
>> Эти программные интерфейсы по большей части что-то над интеграционными такие SDK.
>> Ну, ты можешь развернуть? Я, ну, они абсолютно разные бывают.
>> Ну, вот чтобы, например, мм, есть какая-то интеграция, ну, скажем, там, с джирой, да, и вместо того, чтобы каждому говорить: "Ну вот restджиры, вот тебе коннектор, вызывай его". ты делаешь какой-то общий модуль, который м у тебя в терминах бизнесовых, да, объявляет действия, которые ты сделаешь над жирой. И вот такой вот модуль, который >> делает бизнесовое представление, пряча под собой клиент какого-то интеграционного механизма. Вот такие штуки, они называются SDK. Ну, типа, мой software development kit. Фу, какая-то интеграция.
>> Нет, я понял тебя. Ну да, да, так и есть. На самом деле у нас не то, чтобы часто разрабатываются подобные интеграционные программные интерфейсы, потому что, ну, не так часто требуется. Тут больше речь про там какое-нибудь логирование. То есть у нас есть логирование, которое логирует те или иные действия и позволяет эти логиружать, например, во внешние системы. То есть можно ли это SDК назвать? Ну сомнительно.
>> Почему?
>> Вот. Ну вот, например, cнри официально поставляет SDK для разных платформ своей библиотеки, которые там её задействуют. Более того, у неё есть даже гайд по разработке собственного SDK и на сайте.
>> Ну то есть это всё-таки занимает какую-то меньшую часть. Вот добавить вызовы внешних методов той же Джиры, а каких-то внешних систем. Это, ну, не большая часть разработки. Тебе всё-таки нужно сначала построить архитектуру тех же программных интерфейсов, как они будут взаимосвязаны, как они будут взаимосвязаны с уже существующими подсистемами. Вот поэтому, ну, непосредственно интеграции вот этот SDK, о котором ты говоришь, ну, по сути, просто адаптер к какому-то сервису, к какому-то программному обеспечению, он занимает, ну, не то чтобы большую часть времени разработки.
Вопрос от зала. Назови топ-три правила регламента при разработке библиотеки. Тут интересно, наверное, что-нибудь такое вспомнить, что при разработке >> имена метаданных и ну имена просто имена. Вотда >> главное име Нет, просто имена, имена методов, имена переменных, имена метаданных. Просто это, мне кажется база.
>> Например, префикс устарело. Как долго живёт метод с таким префиксом? У вас вообще есть устарелы в вашей библиотеке?
>> Аа у нас ээ ну условно этот префикс, если добавляется, то в виде просто комментария к документирующему. У нас для этого есть специальная штука depricate. Ну, у нас есть специальные методы, которые позволяют деприкейтить другие методы. То есть и, например, если мы вешаем deкеate, то при попытке вызова на продуктивной системе этого метода там буквально, ну, ещё на стадии тестирования будет просто выскакивать плашка на весь экран, что, ребята, вы
используете устаревший метод, используйте, пожалуйста, вот тот вот другой. Вот. Ну и, соответственно, обратная совместимость. То есть мы на новый метод наши интерфейсы переводим тихонечко, чтобы никто не заметил, >> пытаясь сохранить контракт. Ну, контракты иногда меняются, но крайне редко. И обычно об этом сигнализируется везде там, что вот мы поменяли контракт. Вот у нас такой формат, как бы. А на тему устарело у меня есть доступ ко всем репозиториям компании, поэтому у меня всегда есть опция просто поискать как часто и где используется этот метод, и уже на основании этого решать, принимать решение, там я его деприкейчу или я могу просто снести его молча, там одному чуваку, написав в личку: "Пожалуйста, поменяй вызов". Вот тут вот. >> Ну это преимущество того, то что это библиотека компании. >> Да. Да. несомненно, мы лишные воспитываем многих минусов. >> Если бы библиотека публичная, так бы уже не особо получилось, потому что тебе публично оповещать всех. >> Даже если ты какой-то чатик в Телеграме сделаешь, это не очень получится. >> Мы себе оставили только самую интересную часть работы. Самую неинтересную мы себе не оставляли. Вот. А так по топ-три, ну, конечно же, это имена. Ну, хорошо выбирать имена переменным, чтобы разработчики вообще могли в дальнейшем найти, что там что-то появилось и что-то можно сделать с этим. >> А как-то отслеживаете, что как что-то вообще добавлено новое в программный интерфейс или что-то изменилось в нём автоматически? Ну, конечно, у нас же, когда выпускается релиз, у нас пишется описание релиза, какие-то релизы, какие-то моменты, которые потребуются при обновлении на этот релиз. Ну, естественно, у нас всё готовится. >> Вот вообще для тех, кто делает какие-то можно в Джире открыть списочек и посмотреть, какие там таски попали. >> Угу. в этот релиз >> в БСП прямо есть обработочка, которая генерирует описание программного интерфейса для контроля поставки. Там можно выбрать даже для какой библиотеки, если это всё по стандарту описано программный интерфейс вот этими документирующими комментариями, >> то потом можно делать такую интересную наке, >> да, на релиз там выгрузил куда-то в гиIT, на следующий релиз выгружаешь и сравниваешь, у тебя там нотация изменилась или нет. описаний процедур, функций, либо типы >> у нас какого-то отдельного отслеживания. Ну, вот именно проверить, в каких версиях, как нельзя, но программные интерфейсы у нас тоже выгружаются на твике, и их там всегда можно в документа, ну, у нас, в принципе, очень большое внимание уделяется документации. То есть если ты какую-то новую функциональность добавляешь, будь добр. Там, если это программный интерфейсы, задокументируй нормальные методы публичные. Вот если это добавляет какие-то инте, конечно. Да, естественно. Вот. И, соответственно, если это требует ещё какой-то сверху настройки или в UI что-то потыкать, то со скриншотами полная документация описана, как этим пользоваться. И параллельно с этим есть автоматическая выгру выгрузка программных интерфейсов. Тоже на страничке Твики там можно полазить, поискать, посмотреть. >> Угу. вот этого контроля, что вот что-то случайно где-то в программном интерфейсе убили, добавили, а после этого не описали. Вот этого нету. >> Этого нету. >> Это просто есть отдельная сложная сложная задача, потому что очень >> у нас есть список ошибок релизов. То есть, если вдруг кто-то когда-то там с какой-то ошибкой сталкивается после релиза там новой версии библиотеки, у нас есть там публичная страничка, на которой висят таски с описанием этих ошибок там и исправлена она, не исправлена, в каком релизе будет исправлена. Ну, типа бакборд такой на минималках. >> Ну да, >> вот. Ну да, без этого никак. Ну мы не часто косячим, смею надеяться. Что-то так случайно опа и какой-нибудь программного интерфейса методы раз и грохнул. Что бы нет. [смех] >> Ну, ну нет, такого вряд ли такое вряд ли случится. Всё-таки у нас достаточно строго контролируются реквесты по задачам. То есть обязательное ревью. Не всег даже иногда не один человек, а несколько всё это проверяют. Поэтому таких досадных оплошностей, как снести программный интерфейс, чего-то нет, не быва. Ну, на моей памяти не бывало. Расширить его так, чтобы у всех всё поломалось. Ну, например, не обязательно параметры добавить и всё. Все, кто тебе вызывали с ограниченным количеством параметров, они сразу попадают. Нет, такого тоже не делали. >> Ну это такой просто частый случай, когда могут случайно не взначая взять и поломать программный интерфейс- это добавить обязательный параметр конец вместо необязательного. Вот необязательные можно добавлять, обязательные нельзя. >> На самом деле я бы не сказал, что супер часто приходится менять программные интерфейсы. То есть это такая не очень частая задача. И всё-таки к этим областям достаточно высокое внимание проявляется, и ты не можешь просто взять и перелопатить параметры программного интерфейса. То есть, ну, как минимум ожидается, что сотрудник перед тем, как меняет этот программный интерфейс, он озадачился и посмотрел там, кто, например, использует эти программные интерфейсы хотя бы внутри нашей же библиотеки. Те же значения реквизитов объекта при мне только несколько раз изменяли свой программный интерфейс. Сначала переименовывались, да, из получить значение просто в значение. После этого переопределяемые название предопределённого элемента вместо ссылки можно было передавать, скармливать. А потом ещё и добавили параметр, с помощью которого можно было получать из мультиязычной строки конкретную строку для вот этих всех конфигураций. когда ты там наименование номенклатуры можешь там на трёх языках вести, ты можешь выдернуть конкретное в языке представления. Вот. И все они должны быть, конечно же, обратно совместимы. Ну, как я уже говорил, она мы избавлено от достаточно большого количества подобных проблем. Скажи, что ты думаешь о том, чтобы запускать библиотеки через расширение? >> Ну, просто расширение они вроде как Да, там, >> ну, просто поставлять библиотеку расширения, >> да. Я очень часто вижу, как многие интерфейсы. Это чему >> я очень часто вижу, как многие прямо вот реально делают библиотеки расширением. Их выкладывают, чтобы сказать: "Вот смотрите, у меня тут куча много нового функционала". Вы прямо берёте библиотеку и накатываете её на типовую, и у вас это работает. Вопрос: почему это называют библиотекой? Они просто раз бы нет. В принципе, слушай, я в целом отношусь вот к этому шагу, что ты какой-то свой код берёшь и выкладываешь на публику. Это уже настолько крут, что в целом даже не особо важно, что ты выкладываешь. Типа, если ты какую-то свою лигу людям даёшь, то там формат неважен, ты уже крутой чувак. >> Продаёшь, >> а продаёшь? >> Да. >> А не продают. Я вот периодически вижу, [смех] да, вижу, как люди продают библиотеки. >> Да не знаю, если работает в расширении и есть, не просит, почему бы и нет. Конечно же, проще всегда работать, когда у тебя всё это встроено внутрь конфигурации. Есть очень интересный пример, это библиотека технологии сервиса. Они смогли между собой совместить эти два подхода. Они в поставке дают методы, которые возвращают заглушки для коробки, а накатывая и фактически программный интерфейс. Вот они дают программные интерфейсы, в котором заглушки для коробки. Но когда ты накатываешь расширение технологии сервиса, он подменяет реализацию всего этого программного интерфейса. Фактически они изолируют всё, что у тебя служебное, так чтобы, знаешь, ручки разработчика не дотянулись до служебных методов вообще. С одной стороны, с другой стороны, они фиксируют программный интерфейс, который разработчики конфигурации могут вызывать и имеют возможность очень легко подменять реализацию этого программного интерфейса, просто накатывая новое расширение, которое подменяет эту реализацию. И если тебе нужно накатить какую-то вот менеджер сервиса, да, новый формат выпустил обмена и конфигурация, новый формат обмена, да, через и там какую-то очередь между собой, программный интерфейс остаётся одним и тем же на уровне бизнецовых объектов. Они просто в менеджере сервиса версию подняли и по всем нодам раскатали расширение типовых конфигураций и и вдруг опа у тебя всё сразу везде заработало на старой версии конфигурации новой версии библиотеки. Вот такой вот интересный приём использует БТС. И я считаю, что это вообще будущая библиотека в Одинесе и лучшее из того, что можно сейчас придумать. >> Ну это прикольно. Но ребята же, создавая этот механизм, решали какие-то свои собственные проблемы. >> Ну, конечно, быстро обновлять библиотеку, причём, когда это тебе нужно сделать, прямо вот очень-очень быстро и по всему фрешу. Ну, представляешь, насколько сложно раскатывать обновление по фрошу. >> Нет, я не сталкивался с фшом. >> Это прям очень-очень такая непростая задача. Там же прямо сильно используется м красно-чёрный режим, когда ты сначала там 5% обновил, потом 25%, у тебя ноды распределены, да, ты постоянно отслеживаешь, где что, как у тебя ходит. М. Эпределены, где какая версия платформы, где какая версия конфигурации. Твои области, они могут быть в разных нодах между собой. просто так ещё не связать их. Вот тому задача обновить что-то на фрышке - это прямо очень сильно сложная задачка. Смотри, такой вот у меня вопрос интересный записан. Зачем разрабатывать вообще свою библиотеку, если можно просто взять чужой готовый код? Ну, с точки зрения там того же DZD, м, разработка какой-то библиотеки, это вообще для бизнеса, да, для процессов разработки, это что-то такое базовое, что на что лучше вообще не тратить деньги. Ну, потому что зачем что-то разрабатывать Generриic, что-то разрабатывать универсальное, когда нужно разрабатывать то, что приносит деньги, вместо того, чтобы делать что-то универсальное. Есть единственный с точки зрения бизнесовой, да, вообще архитектуры продажи софта. Единственный принцип, когда тебе выгодно разрабатывать библиотеку, когда ты продаёшь библиотеку, когда твой продукт - это библиотека. Если это не твой финальный продукт, да, лучше вообще всегда брать готовое. Почему иногда требуется всё-таки разрабатывать своё и знаю то, что это действительно что-то очень сильно изолированное и оторванное от всего остального? >> Может, просто нету готового. Конец. >> Почему это не отдать на аутсорс? Как ты себе представляешь отдать на аутсорс разработку? Ну нет, я примерно представляю, как выглядит, но тогда я тебя не понимаю. >> Типа это же не твоё коры. Зачем? Ну, в смысле, мы же так или иначе вынуждены, как разработчики, продавать бизнесу всякую штуку, которая важна именно разработчикам, а не бизнесу. Там тоже тестирование, тоже синтаксический контроль. Э, точно так же и в библиотеке. То есть, ээ, мы упрощаем жизнь разработчикам другим. >> Угу. Позволяем им писать меньше кода, позволяем им, ну там, вместо того, чтобы пять разных разработчиков в пяти разных базах разрабатывали один и тот же функционал, каждый по-своему, каждый заразное время, мы, возможно, потратим на этот же функционал чуть больше времени, там, чем один или даже два разработчика, но при этом это будет какой-то универсальный механизм, который переиспользуют вот эти все пятеро сейчас, плюс, возможно, ещё десяток потом. То есть это вопрос вот, ну, диверсификация. >> А если кто-то вот конкретно придёт и скажет: "Мне вот это лень писать, сделайте это в библиотеке". >> Пожалуйста, пожалуйста, приходите. У нас есть специальный в Джири раздел, куда любой желающий может запостить свою таску, >> и она какой-то там будет отлеживаться. >> Да, Да, она даже не обязательно будет отлёживаться. Они на самом деле достаточно быстро реализуются. Иногда людям рассказываешь, ну, типа что-то не хватает, но создай заявку. Они такие смотрят на тебя вот такими глазами. >> А что, так можно было? Это же библиотека. [смех] Так можно было. >> Да, да, да, да. >> Это же библиотека, что-то фундаментальное, но никак она не меняется. >> Да, иногда просто кажется, что люди некоторые привыкли вот как к типовым библиотекам. Ну, блин, я же не бу Ну вот я даже себе в голове эту картину рисую, и она выглядит мне абсурдной, что я буду писать одинаясником с просьбой добавить какой-нибудь универсальный метод в БСП. >> А почему нет? >> Не знаю. Вот у меня это сложно в голове укладывается. А в случае нашей библиотеки буквально можешь меня там в чатике найти, там в общем мессенджере рабочем и сказать: "А мне нужна вот такая вот штука в библиотеке. Ну я же нафиг не пошлю правильно. Я выслушаю, там какую-нибудь таску создам. Это классно. >> На чатике партнёрском, который вот форум, да, который партнёрстм V8 1S.ru, там же есть отдельный большой форум BSP. Вот я в своё время был тем, кто вот этот вот как раз раздел и разгребалпшный. Обычно всё, что туда пишут, после этого реализуется. Ты просто пиши, что ты хочешь, да? создай топик, что я хочу в БСП вот такой вот функционал. Вот БСПшники посмотрят, скажут: "О, прикольно, а мы про это не знали". Ну, сейчас доделаем, а там через полгода сделают. >> Ну вот не знаю, у меня, я умом понимаю, что это нормально, но у меня всё равно какая-то мысль в голове выглядит абсурдно, типа, но там я сейчас попрошу, они там это привезут в каком-нибудь свежем релизе БСП примерно через полгода. Я на этот релиз ещё через 5 лет обновлюсь только. Главное, чтобы привезли в том виде, котором тебе надо, котором ты попросил, а не переосмысленное. >> Мы тоже так иногда делаем. Ну это нормально. [смех] Мы тоже часто подобные, ну не часто, но бывает, что какие-то задачки, которые к нам приходят, мы их переосмысливаем, ну просто в сторону больше универсальности. >> Угу. Ну в этом, наверное, задача ресё-то и есть, >> конечно, >> Рнди. То есть, ну, мы же всё-таки, если мы видим перспективу к общему, >> да, то есть, если видно какую-то перспективу у данной конкретной задачи, конечно же, мы попробуем сделать её так, чтобы она удовлетворила не только заказчика конкретного, а потенциально намного больше людей, чтобы этим было удобно пользоваться, там комфортно, приятно, там добавить больше функционала. Ну или иногда отговорить, что нет, ребята, мы этого делать не будем. Давай чуть-чуть поговорим про разработчиков. Есть такая сейчас очень интересная штука, которая называется Team Topg. Оно она описывает м что А, во-первых, у нас есть м такой интересный закон. И то интересное, и то интересное. Но всё началось с закона, который говорит, что организационная структура модулей внутри конфигурации, внутри вообще программы софтверной, она повторяет организационную структуру компании, которая ведёт разработку этой свого самого софта. И получается, смотри, как интересно, то добавляя какую-то библиотеку, ты фактически добавляешь, а изоляцию этой библиотеки внутри кода за счёт того, что его делает изолированная команда. Но при этом, если ты сделаешь библиотеку, в которой будут разрабатывать не выделенные разработчики, а будут разрабатывать совокупность людей, которые вместе организовались, но при этом делают что-то, работая в разных командах, да, внутри компании, у них не будет эта библиотека цельно выделена. Они каждый для себя какой-то модуль будет делать, который по чуть-чуть интегрирован соседними. Ну, фактически она повторяет топологию той структуры, которая есть организационная. И что здесь получается интересного? То, что управлять архитектурой, выделять правильно все модули, которые есть, это очень сложно, потому что нужно очень много знать. Ты должен постоянно свои мозги переключать с одного режима на другой разработки. Вместо этого можно управлять административной структурой команд разработки, так, чтобы команда разработки была тем самым модулем внутри кода. Как тебе такая идея? И тогда получается самый программный интерфейс - это получается то самое общение между двумя разработчиками двух команд разработки, которые между собой договариваются. >> Замудрённо, да? >> Идея прикольная и мне не Идея прикольная, я про неё слышал уже. Э, и мне кажется, это классно канает, когда у тебя действительно, э, там какая-то команда занимается какой-то отдельной своей там веткой бизнеса, типа это, да, это канает, но мы же как разработчики библиотеки внутри компании, как мне кажется, мы чуть ниже по абстракции спускаемся. То есть для нас-то мы как компания внутри компании. То есть мы же разрабатываем не для конечного заказчика какие-то бизнесовые там домены, а у нас свои домены, но уже для разработчиков. >> Угу. >> Мы, конечно же, там внутри команды у нас есть там условно какое-то отделение, там кто-то там одни блоки сопровождает, кто-то другие блоки сопровождает. Вот. Ну, типа, мы не можем на бизнесовые блоки делить задачи. У нас с заказчиками выступают, по сути, другие разработчики. И под них Тим Тополонже, она как раз и выделяет четыре основных типа типов команд, что у тебя есть команды, которые вот тим тополже звучит круто, но подразумевает, что у тебя есть тим, а не когда ты сидишь а не когда ты сидишь в одну дудку, разрабатываешь там интерфейсы. в пятидесяти модулях. >> Ну почему? Это тоже теория теория круто ложится, когда у тебя там сотни разработчиков, куча команд, которые отвечают за каждую свою бизнес фичу какую-то там развивают и одного разработчика не больше одного модуля. Да. >> Да. У нас три разработчика. Один в отпуске, второй на больничном, третий сидит, поддерживает все бизнесдомены компании. Ну, тут надо как-то всё-таки немного приземлить эту теорию. Но самое интересное-то это то, что типы команд тоже там выделяются разные. Есть команда людей, которые работают мм наском, чтобы быстро-быстро что-то на потоке сделать, родить новое и запустить. Да, есть команда, которая с периодическим циклом работает, чтобы, не дай бог, ничего не поломать. Очень сильно согласовывает каждое изменение, которое есть, которое работает над тем, что работает в продуктиве и что-то релизное, да, одна такая сильно ресёчивая команда, которая мпишки создаёт, да, один подход вообще к разработке. Второе - это не поломать, да, привнести новые фичи, но не поломать. Это второй подход. Третий подход - это вот как раз платформщики. Платформщики - это те самые ребята, которые делают для всех остальных инструменты и разные модули, которые они могут дёргать. [смех] Вот. Ну и четвёртый тип тоже интересный. Это эксперты, которые финальный код вообще особо не пишут, но притом приходят и помогают в проблемах остальным трём. Ну блин, ну оно же ложится на большие команды. >> Ну на большие компании, где много команд разработки. Эксперты. У нас вот сидит ведущий, который в роли и эксперта, и платформщика выступает. >> Просто так почему-то очень часто получается, что >> платформщики они и есть эксперты. Чаще всего так получается. >> Ну да, да, так и есть. Так и есть. Просто потому что это скорее люди с более широким кругозором, более опытные. >> Ну и потому что приходится думать не только про конкретное внедрение, а про все возможные типы внедрений. >> Да. Да. Ещё и про то, как с этим дальше жить после внедрения >> и как это потом обновлять. Да, >> есть же ещё один очень важный процесс, который все почему-то забывают. Это процесс, а, в ухода от программного обеспечения, вывода его из строя. В случае, когда нужно уйти от какой-то подсистемы библиотеки. Как обычно такая штука происходит? Мы, по-моему, уже обсуждали. Это вот как раз касается устаревших. Ну, >> ну это конкрет конкретные устаревшие методы. А вот если мы >> там полностью какую-то подсистему хотим вырезать, >> ну, по сути, точно так же это работатить будем. В какой-то в какой-то момент мы начинаем, ну, для начала мы просто принимаем решение, что нам нужно выпилить какой-то механизм из конфигурации. А первое, с чего мы начинаем, естественно, ищем тех людей, которые этим пользуются. У нас же есть такая возможность поста найти, >> да? Но для этого есть все остальные шаги. То есть, если мы находим тех, кто этим пользуется, мы их предупреждаем, что, ребят, не пользуйтесь. пожалуйста. Аэ, при первом обновлении, после того, как мы такое решение приняли, мы деприкетим все методы, которые уедут ээ в комментарии пишем огромный комментарий вместе с деприкейтом, по какой причине, в рамках какой заявки и что там, например, с начала следующего года эта подсистемо будет выпилена. Вот. И в зависимости от того, как много людей этим пользуются, просто постепенно выпиливается там какой-то функционал медленно, аккуратненько в течение там трёх-четырёх релизов. Каждый раз всех вот так вот с табличкой ходишь чуть ли не по офису и показываешь, что это будет выпилено. Но такое не супер часто случается. У нас всё-таки нету каких-то, >> да, у нас нету каких-то прям супер подсистем, которые бы все использовали, и мы решили внезапно её выпилить. То есть это всё-таки речь скорее либо про какой-то там очень устаревший функционал, если не ошибаюсь, больше 10 лет БСПшки нашей. То есть есть какие-то устаревшие функции, там что-то по безопасности перестало проходить. >> У вас только одна библиотека. >> Ну, в смысле, вот есть процесс, который, >> ну, мы занимаемся одной библиотекой, то есть и я не слышал про другие. >> Тут видишь, что интересно? Интересно то, что а тех же типовых библиотек их много. И когда ты ставишь зависимость сразу там двух библиотек, например, БСП и БИП одновременно, у тебя оказывается, что есть две конфигурации поставщика. При этом у тебя в бипе могут быть какие-то объекты, которые являются объектами БСП, просто потому что, ну, она ссылается внутри на метаданные, да? Ссылки на метаданные тебе нужны, чтобы организовать хранение метаданных бипа. тебе нужны какие-то метаданные БСП, потому они вынуждены добавлять объекты БСП в свою поставку тоже. И у тебя получается уникальная ситуация. Ты сначала а запускаешь установку БСП, у тебя всё хорошо, у тебя все объекты появились, ты запускаешь установку бипа, и у тебя показывается, что бспэшные объекты на поддержке сразу у двух библиотек. И в этот момент, если что-то сделать не так, то очень сильно всё ломается, потому что конфигуратор он не показывает, какой версии у тебя текущий объект на замке. И ты обычно стараешься БСП поставить поновее, чтобы у тебя самый-самый крутой был, да, последняя версия со всеми исправленными ошибками. А в поставке, например, того же Бипа, там БСП будет как можно более старая, да, той же там версии разрядности, но она будет как можно более старая, потому что м тебе нужно обеспечить поддержку бипа на как можно более старую БСП. И тебе нужно, получается, в момент, когда ты устанавливаешь бип или обновляешь его, случайно при этом не обновить БСП. И в определённый момент у тебя оказывается такая интересная ситуация, что у тебя объект находится на замке, но на чьём замке, ты не понимаешь, и у тебя просто оказывается, что единственный способ проверить - это сделать выгрузку в XML. После этого сделать выгрузку в XML BSP, выгрузку в XML бипа и построчно сравнивать хэши вот этих самых модулей, которые у тебя выгружены, чтобы понять у тебя какая вообще версия есть. И весь этот механизм с поставками, кажется, он, ну, придумывался для поставки чего-то супер независимого друг от друга, а не такого, что ты будешь одновременно ставить одну библиотеку, а потом вторую, зависящую от первой. Что делать-то с этим? Из-за того, что у вас одна библиотека, получается, у вас такой проблемы вообще в принципе нету. [смех] Да, да, у нас такой проблемы нет. Очень надеюсь, что наши пользователи подобным не занимаются прибно. >> И это, видишь, очень хорошо то, что зная в этой проблеме, если вдруг кто-то захочет, ребята, сказать: "Давайте создадим вторую библиотеку", ты такой: "А стой, может быть, всё-таки не будем". У нас есть, ну, наша основная BSP, и параллельно с ней у нас поставляется BSP mini, что называется, из которой выпилены, а, ну, которая буквально подразумевает свою стройку в какие-то типовые продукты, там Zoom, бухгалтерия и так далее, достаточно современные. И есть задача, чтобы функционалы, ну, хотя бы имена объектов метаданных библиотеки нашей, библиотеки типовой не совпадали. Вот. Но я, к сожалению, наверное, подробнее про это рассказать не могу. Это лично Валера занимается. >> Угу. >> Вот этой формирование поставки БСП мини и её поддержкой. Вот я этого не сильно касаюсь. Как вообще разработчики библиотек, что они делают для того, чтобы было проще внедрять библиотеки? У вас есть какой-нибудь механизм типа автообновления библиотеки? Вот поставки БСП от 1 у них есть механизм первого внедрения, механизм автообновления в случае, если у тебя поднимается четвёртая цифра, ты вот просто нажимаешь, а он у тебя сам формирует правила мержа, да, твоей конфигурации на ту, которая новая, и подтягивать. Тебе после этого нужно просто открыть конфигуратор, бочку нажать. Вот. А вот >> я очень с сомнением отношусь вот историям просто открыть конфигуратор, бочку нажать. Обычно она не так работает. [смех] >> Обычно что-то разламывается. >> Да-да-да. Нет, у нас подобных механизмов нету, наверное, в том числе и потому, что у нас не такие объёмы изменений, как у типовой БСП. То есть это всё-таки такая точечная история. Там четыре человека не могут там за релизный цикл там условные там максимум 3 месяца налобать столько функционала, чтобы это требовало какого-то особого подхода при внедрении. Вот. А если оно какого-то особого подхода требует, обычно про это пишется огромная документация, как сделать так, чтобы было хорошо. >> Угу. Вот в основный, ну и основные проблемы с обновлениемто возникают обычно у тех, кто влезает в наши модуля и пишет что-то своё. >> Ну это просто считаем сам себя злобной Буратиной. >> Да, да, так и есть, как бы. Ну доработали вы модуль, но будьте добры, обновляйте его самостоятельно. Ну, это, кстати говоря, прямо очень правильный подход, потому что эти очень многие разработчики, которые не касаются разработки библиотек, они такие: "Ну, тут что-то мне не нравится, я и доработаю, да, БСП, БПО, что там будет". Потом как это обновлять, не особо думают, >> да? Ну, тут, ээ, скажем так, человек, который обновляет библиотеку в конфигурации, он не то, чтобы часто меняется, то есть обычно всё-таки есть какое-то ответственное лицо, там какой-то ведущий разработчик, у которого его регулярная задача там обновить версию БСП в своей конфигурации, за которую он отвечает. как бы и зачастую это человек уже, ну, понятно, что первый раз это боль, страдания и очень сложно, но каждый последующий у него уже есть информация о том, что изменено, что менять не стоит, что можно поменять и так далее. Вот, чем чаще они обновляют релизы, тем и проще. >> Угу. >> Надеюсь, этих людей нету на стриме, чтобы они как потом ко мне с вопросиками не пришли. [смех] Ну, понятно. Да нет, на самом деле мы просто стараемся писать код хороший. Вот это всё, что мы можем сделать для удобства обновления. Ребята в чатике притихли, что-то там прям очень сильно буро обсуждалось, а вот сейчас каких-то новых вопросов нету. Писать свою библиотеку или использовать готовую? Это святой граль Халивара пишут. Вот >> что ещё раз использовать готовую или писать свою? >> Да. Да. писать свою или использовать готови. >> Ну, если тебе в 1С нужно использовать какую-то библиотеку, и она есть готовая, то ты счастливчик. Ну, объективно, если ты можешь себе что-то такое притянуть. Вот. Плюс, опять же, есть ограничение. Мы там не можем просто взять, притянуть какую-то библиотеку себе в продуктивную базу. Ну капец. У нас там на каждом модуле свои копирайты стоят. там куча всяких бумажек там на авторство и так далее. И просто там взять тот же коннектор, притянуть, но нет, это нереально. В таких случаях лично мы вынуждены просто писать свой функционал, даже если, казалось бы, он был, >> ну, по тем же причинам коннектора нету и там в составе типовых. Если бы это было просто взять и добавить, его бы, наверное, добавили. Ну, объективно одинасники могли бы и сделать что-то типа коннектора. >> Прямо вот >> на больное даришь. Да, >> вообще, на самом деле, >> вот кто-то в чатике справедливо замечает, что >> если даже если найдёшь что-то готовое, то хз, как оно работает. Вот это тоже, блин, проревьюить что-то, что ты собираешься затащить себе, тоже такая нетривиальная задача. Иногда им получается проще открыть что-то готовое и копировать построчно код к себе, при этом понимая, проводя, да, вот то самое ревью, высматривая все детали реализации, как они устроены. При этом ещё и очень-очень хорошо начинаешь разбираться в том, как это действительно работает. Но это не быстрый процесс. Часто иногда оказывается прямо излишне, небыстрым. Да ну нет, я если там дома что-то делаю там для себя и что-то нахожу готовое, но это всегда приятно, когда кто-то за тебя уже подумал, что-то сделал, и оно ещё и работает. Это вообще фантастика. Ты видел такую библиотеку, как Open Integrations? Да, конечно, конечно. Я активно слежу. >> У неё прямо свой коннектор внутри почему-то. Вот они коннектор не стали брать, а написали свой внутри. >> Почему бы и нет? >> Мне кажется, очень многие, да, начинают с того, что пишут какой-то свой коннектор просто потому, что интерфейс платформы по запросам неудобный. >> Да. Да. Если это не первая и не пятая твоя интеграция с каким-то аж типичным сервисом, то рано или поздно ты задумаешься о том, чтобы написать что-то относительно универсальное. Это, мне кажется, как это с с консолей запросов, типа каждый одиночник должен свою консоль себе сделать где-то там в начале карьеры. >> Я не делал. >> Не делал. >> Ты делал? >> Ну да, что-то пытался. Я не делал консоль запроса и консоль исполнения кода тоже не делал. Я даже тасктреткер не делал сед наденности. [смех] Что там ещё очень популярно? >> А то там все говорят: "Вот нужно там тасктрекер себе сделать, да, там консользу написать свою. Что ещё нужно себе точно написать? А это 1S деньги своё написать. Вот один на деньги я пытался, я попробовал делать это мобильным приложением. Мне это очень не понравилось, как выглядит, и я это всё за тебе бросил. Что мне нравится >> ча чатикл. >> Что мне нравится в разработке библиотек, это то, что тебе на самом деле не очень много работы с пользовательскими интерфейсами. Тебе нравится работать с пользовательскими интерфейсами? >> Да, >> нравится. >> Не особо, скажем так, не особо. Не особо. Ну, лично у меня, в принципе, не очень хорошо получаются интерфейсы. Я всё мечтаю о том, чтобы пройти какой-нибудь курсики по UIUX, чтобы они найти какой-нибудь нормальноки по >> Вот. Ну, конечно же, программные интерфейсы намного приятнее писать, там намного меньше ограничений, чем у юзер интерфейсов. Как интересно. Ты говоришь то, что чати кожела. Я почему-то это не видел. Походу у меня эта вкладка вообще полностью залипла. Сейчас попробую. На на стриме сижу сам. >> Ты сам себя слышишь? >> Ну нет, конечно. Я же отключил микрофон, точнее аудио стрима. >> Паша пишет: "Мы свою подсистему интеграции писали, но коннектор взяли". Тут опять вопрос: а куда дальше эта подсистема едет? В каком формате? Что делать с копирайтами вообще? Насколько там люди запариваются насчёт копирайтов? То есть в нашем случае, возможно, даже если теоретически ты можешь затащить себе какую-то библиотеку, это моментально возникает у тебя ворох вопросов в голове, что тебе вот это вот всё нужно сейчас собрать, взять там наши какие-то копирайты, взять копирайты, которые указаны там лицензия у этой библиотеки, со всем этим добром пойти к юристам, чтобы они там что-то начали смотреть. в какой-то момент в это ещё влезут господа безопасники, которые тоже заинтересуются тем, что ты тащишь внутрь компании. Вот. И это уже на просто на моменте раздумий вызывает скуку в голове, которой ты точно не хочешь заниматься. >> Копировать построчно проще. >> Да, да, да, абсолютно. Заодно и ревьюшечку сделаешь, и что-нибудь подшабанишь, как тебе комфортнее, приятнее и так далее. Я тоже думаю, что осторожно-то забирать сильно проще. Ещё и детально разберёшься. Так, новых вопросов практически нету. Давай, наверное, будем потихонечку закругляться. >> Да, давай. >> Как, в принципе, какое-то резюме по работе с библиотеками. Скажи, насколько тебе вообще нравится такая работа платформщика? >> Великолепно. Получаю просто невероятное удовольствие от работы. >> Я вот просто знаю то, что ты до этого Я сейчас тебя, Секунду, секунду, я тебя сейчас просто перебрю. Я просто знаю то, что до этого ты работал в ОДНС Вьетнам, у тебя даже вон там кружечка есть оттуда. [смех] >> Вот. А задвинул потихонечку, >> да? Было >> платформ платформщикам работать нравится больше, чем разрабатывать типовые конфигурации? >> Да, конечно. Тут, ээ, больше, наверное, канает тот вопрос, что ты, по сути, ты с заказчиком на одной волне. Вот это очень классно. >> Угу. >> То есть, ээ, ты как разработчик делаешь что-то для других разработчиков. Это очень сильно драйвит. Типа ты, ну, смею надеяться, что я понимаю, что хочет разработчик получить от библиотеки, и стараюсь это реализовать. Это классно. Ну, опять же, это определённая свобода в творчестве. >> Так получается, что разработчикам всегда чуть-чуть проще найти общую волну, чем с бизнесовым заказчиком. >> Конечно, конечно. Вы как минимум разговариваете на одном языке. Спасибо тебе, Жень, что пришёл на стрим. Очень много чего интересного, хорошего рассказал. полезного. А спасибо всем в чате за то, что послушали и вот это вот всё пообсуждали. Ещё увидимся. Пока-пока. Всё, спасибо. Давай, пока-пока.