Все, теперь понял. Наверное, безумно удобно сидеть в чешско-кирпской компании и спамить в грубой форме в русскоязычный портал о технологиях. Довольны своим карьерным успехом? Почему не хотите рвать связь с русским профессиональным сообществом? Почему не бережете репутацию, все же оставаясь на связи в комментах? Ваши руководители вообще знают, чем вы занимаетесь в рабочее время?
В линкедине, кстати, численность указана в 50-200 сотрудников. На порядок отличается от "тысяч сотрудников в монорепозиториях" и очень далеко от "кровавого энтерпрайза".
Эх, я надеялся на конструктивную беседу и более уверенную и аргументированную позицию, а не на ожесточенное отбрехивание какахами. Правда было интересно, почему у вас настолько безапелляционная позиция без видимого основания, идущая вразрез с общим мнением.
Я упоминал специфику 1С с несколькими средами и поставками вендора. Образовалась ситуация, когда типовая версия поставщика безнадежно устарела и из-за режимов совместимости конфигурации и несовместимости между собой версий новой IDE, поддерживающей гит, невозможно было впрямую актуализировать продукт. Была проделана немного неприглядная, но давшая результат операция, сравнимая в хирургии с выращиванием носа на лбу из складок с задницы и последующей пересадкой его на лицо. В терминах системы управления версиями разворачивались отдельные репозитории и сериями последовательных сравнений вычищались конфликты, мешающие обновлению. Потом готовый артефакт бережно переносился в основной репозиторий, как будто это изначально было сделано там. Через среду это делать было бы довольно затруднительно, у нее эклипсовская основа с неродным гит-плагином. Здесь еще вмешивается оперирование несколькими проектами в рамках одной рабочей задачи, и у эклипса есть тоже свои нюансы, ну банально нельзя два проекта с одинаковыми именами держать в рабочей области.
В одной из команд используется сломанный гит-флоу. Постоянно возникают конфликты слияния, которые необходимо разрешать на стороне клиента и через форс опцию переписывать центральный репозиторий. Через ту же среду, кстати. Это не очень этично по отношению к разрабам, но поменять процесс невозможно по административным причинам. Плюс сотрудники продолжают иногда перетирать результат работы других и приходится восстанавливать свои внезапно исчезнувшие правки.
Есть проект статической документации на mkdocs, там vscode справляется, ок, но мне не очень наглядно сравнивать куски кода общим списком в паре популярных расширений, другие не смотрел.
Была проблема с внутренней самописной компонентой доступа к кафке. Автор был недоступен, пришлось ставить студию и резко разбираться в C#, чтобы внести небольшую правку. Опыт в студии у меня нулевой, встроенным плагином совместной разработки не владею, да и не хочу, пока принципиально не принял решения менять стек на дотнет.
Плюс есть небольшие менторские активности в виде обучения с нуля, где код и обучающие материалы хранятся вместе, а язык, и соответственно, среда, обучающимися не выбраны окончательно.
Во всех этих ситуациях использовал Sublime Merge, как один универсальный инструмент, не зависящий от среды, для меня это было критично. Плагин от студии мне не подходит.
С гитлабом возможно действительно поспешил, в тех простых скриптах с которыми я работал, действительно нет прямого упоминания гита. Но что-то мне говорит, что на полноценной должности девопса такая необходимость появиться может и не будет чем-то выдающимся.
Я не настаиваю на конкретном инструменте, но не согласен с мнением, что есть возможность и настоятельно рекомендовано оставаться в рамках плагина определенной IDE и избегать изучения самой технологии гита в отрыве от ее реализации в виде плагина или инструмента, приводя в защиту своей позиции аргументы, похожие на самооправдания.
То-то я гляжу, вы только одним пользуетесь, в одной среде. Времени, наверное, нет бегать по средам, ах да, вы же скрипты за девопсов пишите.
понтов за край, а уверенности нет
Вы по причине кажущейся вам неуважительности от понтов переходите на личности и агрессию? Или из-за неуверенности в собственной позиции?
У нас как-то не принято для каждой фичи хреначить пару сотен серверов
А по TBD принято, и TBD используется много где, в том же Тинькове, например. Там энтерпрайз не просто кровавый, а с содомом и расчлененкой.
те самые, которые способны задачу на пару часов растянуть на неделю
Сочувствую вашему опыту. Мне же попадались люди, у которых много чему полезному можно научиться. И на удивление, они все избегали безапелляционной категоричности и примитивных жаргонизмов в обсуждениях.
Я до сих пор не вижу конкретного примера
Я до сих пор не вижу, какая методология используется в ваших монорепозиториях. Ну и метрики в отношении численности команд, частоты коммитов, наличия переходных процессов, если можно.
Все баги были решены. Последний клик по клавиатуре поставил жирную точку в этом модуле. Я снял палец с левой кнопки мыши - все было закоммичено. Напоследок системные часы в трее судорожно моргнули. Биения кварцевого кристалла передавались счетчику секунд и походили на удары сердца, складываясь в слоги: во-сем-над-цать-ноль-ноль. Люблю круглые числа, пора идти домой. Я накинул куртку... "ги-и-ит", - послышался голос на краю сознания. "Мой любимый плагин...", - вяло откликнулся я, погруженный в свои мысли. "Гии-и-и-и-иит", - уже громче и протяженнее прозвучал голос. "ГИТ!", - он резко превратился в крик и грянул как окрестр, составленный целиком из одних медных труб.
Я очнулся и взглянул на экран с окном видеоконференции. Часы снова моргнули и показали 14:48. Собеседование шло уже 15 минут, если не считать тех трех, на которые опоздал мой наниматель. Какая вопиющая непунктуальность.
– Простите, что вы сказали? – неожиданно произнес мой собственный голос. – Вы когда–нибудь использовали гит? – спросил интервьювер. – Вы имеете ввиду плагин в студии? – уточнил я. – Нет, я имею ввиду чистый гит. Давайте так, опишите своими словами, как сами понимаете, что происходит, например, во время операции коммита. – Ну, я обычно нажимаю кнопку, а плагин делает все сам, – обрадовал его я. "Кто в современном мире вообще учит чистый гит, – промелькнула мысль, – опять попался какой–то идиот, который спрашивает по анкете из интернета". – Хм. Понятно... А какие вообще команды знаете? – не отставал собеседник. – Вам надо настроить свой приватный гит–сервис? – я попытался перехватить инициативу. – Нет, у нас используется GitLab, пока его возможностей хватает. – А тогда зачем команды? – почти искренне удивился я. – Хорошо, принято... Давайте перейдем к следующему вопросу.
Тот день изменил все. Мне опять никто не перезвонил, и я решил наконец скачать шпаргалку с командами. Не то, что бы я реально вкурил, как они работают, но по крайней мере, рекрутеры сразу увядают, как двойка перед королевским джокером, после того, как я говорю "ребэйз" и "черри–пик". Мне даже выставили пару хороших офферов, но там не было моей любимой среды с шикарным плагином, и я отказался. Но прошло время, и теперь я уже сам иногда сомневаюсь, не стоит ли начать писать свои скрипты по-другому, чтобы заранее скачивать код с гитхаба, например, так – git clone ...
Ну нет, так нечестно) Хоть он и не к вам был изначально, но мой вопрос про методологию уже в который раз остался без ответа. "Методология не нужна" не принимается. Сначала ответьте, как у вас, прежде чем мы продолжим обсуждение)
расскажите, что это были за проблемы и как решались
Я же их описал. Все четыре приходилось решать.
не нужно про методологии спрашивать - возьмите свою
Не нужно пользоваться пакетным менеджером в вашей любимой среде. Пишите свои библиотеки.
нужно оставить за скобками и не рассматривать
С самого начала написал, что вопрос в зоне ответственности. Если вам так легко в рассуждениях отбросить как перечисленные вами и мной сценарии, так и те, которые остались за кадром, и о которых вы не подозреваете, значит у вас просто не очень большая зона ответственности. Это нормально, но подход "я не выхожу из среды лишний раз" - как раз следствие, что за вас кто-то очень сильно и много подумал и реализовал, и не только разработчики среды, а даже в том числе и в вашей собственной компании.
Если правильно вас понял, то достичь простоты, ощущать дзен и быть понятным - как раз, наоборот, самое сложное в карьере разработчика)
Для этого надо иметь очень широкий кругозор, многогранный опыт, быть открытым и толерантным к новым подходам, идеям и чужому мнению и владеть фундаментальными основами. Использование сырого гита релевантно всем пунктам)
Ок, если кратко - плагина не хватает там, где нет GUI.
Если вы работаете в кровавом энтерпрайзе, у вас наверняка есть девопсы/SRE. Если вы наблюдали за их работой тоже, могли заметить, что они пишут скрипты для CI/CD, в котором гит вызывается, внезапно, консольно. Если контура многогранные и процессы поставки сложные, скрипты тоже будут сложные, а не просто "гит пулл".
Про методологию спросил тоже не просто так. TBD предполагает разворачивание feature-контуров, отдельных виртуалок под тестирование атомарных функциональных задач. Что тоже удобно скриптуется и тоже требует консоль.
Наконец, плагин в одной среде - ок. А вот если плагины в разных средах, пусть это будет например, IntelliJ + Studio + VSCode + еще что-нибудь, то для человека в кросс-командной роли, который прыгает между разными командами, стеками, средами и репозиториями, вроде как удобнее использовать один внешний инструмент, а не конкретный плагин, чтобы не переключаться между нюансами использования в разных реализациях. Такие люди в компаниях есть, обычно это амбициозные, не боящиеся изучать новое сотрудники, которых привлекают к поднятию с нуля новых или разгребанию старых закостеневших процессов.
Про 1С, 2 языка, 3 IDE, особенности сравнения xml-фалов (для тех же правил конвертации), наверное, не буду рассказывать, чтобы не триггерить вас лишний раз. Как минимум, заверю вас, что плагин там хоть и стабильный, но не очень неудобный.
Не будете, плиз, столь любезны в ответ рассказать про вашу инфраструктуру и методологию? Хочется понять, почему вы отвергаете инструменты, кроме плагина и избегаете чистого гита.
Можно поинтересоваться, на каких методологиях выстроены монорепы (GitFlow, TBD)? Были ли в процессе вашего наблюдения смена методологии в командах? Стек тоже, получается, у всех общий?
Вопрос в зоне ответственности, численности команды, и с какой стороны код-ревью находишься. Чем дальше, тем больше непростых сценариев, связанных с организацией работы большой команды, параллельными обновлениями вендором программного продукта, коллизий с одновременной разработкой функционала. Тут уже желательно погибче владеть инструментом, чтобы наладить работу. Пусть и не обязательно прямо через консоль (есть удобные графические оболочки), но и на плагине уже не выедешь.
О, спасибо за выжимку! Так основная мысль доносится быстрее. Спасибо, что прислушались и начали исправляться!
Но мой посыл остался тем же, - вы пользуетесь плодами революции, чтобы с извращенным кайфом описывать несовершенство системы в этой же самой системе, попутно обвиняя инструментарий и подходы революции, приведшие к созданию этой системы. И не готовы при этом подстроиться со своей стороны и поступиться частью убеждений, например, не писать ненужные подробности в отзывах. Это забавно)
После прочтения статьи больше задумался о границе между принципиальностью и занудством. Ненужное графоманство в отзывах на торговой площадке - прям хороший маркер. И с выводом не согласен, - наоборот, такая революция нужна. Люди теперь могут удовлетворять свои некомфортные для других потребности в суррогатных беседах с компьютером, не мешая остальным. Это ли не чудо прогресса?
Интерактивным сравнением/объединением. Эта возможность доступна как при слиянии веток, так и при сравнении разных конфигураций между собой. Это специальный инструмент (команда, окно, форма) edt, экранирующий внутренний формат хранения. Вы правда не знали про него?
То есть про делегацию сложности вы проигнорировали. Остался только страх...
По большому секрету скажу, что у 1С есть собственное окно сравнения, которое учитывает всю специфику своих же xml. И я не зря упомянул про возможность локального разрешения конфликтов. То, что вы лезете в формат исходников - исключительно ваша осознанная воля, а может, даже и провокация.
Вы бы хоть матчасть подтянули, прежде чем аппелировать к тому, что считаете больным местом. В кажущихся вам выдуманными мирах это не представляет такой сложности.
Мне кажется, довольно поспешно и недружелюбно с вашей стороны называть мою реальность выдуманной.
Хотелось бы услышать агрументированную и заслуженную критику без прилагательных в превосходной степени сравнения.
На моей стороне успешный опыт использования предложенной выше схемы, понимание преимуществ гита, делегация сложности нового формата хранения исходников edt собственно самой edt, и нейтральное спокойное принятие подходов к переиспользованию кода от авторов типовых конфигураций. Что может предложить ваш мир, кроме страха перед спагетти?
Как же вам, должно быть, сложно ловить собеседника на выдуманных ограничениях, искусственно раздувать проблему и потом героически переводить разговор в обсуждение того, что умеет и как бы тут пригодился lsfusion.
Давайте я отвечу по существу вместо автора статьи. Проект переносится в git и EDT, за первоначальный коммит берется конфигурация поставщика, от ствола ответвляется ветвь с чистой конфигурацией поставщика и периодически обновляется поставкой и вливается в основной ствол репозитория. Git уже на этом этапе разрешает всевозможные конфликты слияния кодовой базы. Если не решает - слияние выносится в локальный репозиторий, проводится на локальных ветвях, и EDT, с учетом специфики метаданных и платформы, с помощью платформенного сравнения добивает оставшиеся конфликты. После чего локальное разрешение конфликтов отправляется в удаленный репозиторий.
Это чисто на уровне гита. А на уровне разработки выбор просто широчайший – методы-заглушки, перенаправления на свои методы в начале типовых методов, отдельные подсистемы, общие реквизиты, регистры с любыми объектами в измерениях и многое другое.
Таким образом, никакой код нельзя назвать лишним, потому что, употребляя ваши просторечные обороты, он "спокойно лежит и каши не просит", и никому не мешает. Исправленный код спокойно сольется при описанной выше схеме.
Если будете предлагать стандартный набор возражений, что EDT сырая, требует много памяти, зачем 1С две среды разработки, зачем переводить проект в гит и прочий абсурд, то лучше давайте сразу не продолжать обсуждение, потому что в итоге можно все свести к гиту, а против него и его возможностей спорить бесполезно.
Все, теперь понял. Наверное, безумно удобно сидеть в чешско-кирпской компании и спамить в грубой форме в русскоязычный портал о технологиях. Довольны своим карьерным успехом? Почему не хотите рвать связь с русским профессиональным сообществом? Почему не бережете репутацию, все же оставаясь на связи в комментах? Ваши руководители вообще знают, чем вы занимаетесь в рабочее время?
В линкедине, кстати, численность указана в 50-200 сотрудников. На порядок отличается от "тысяч сотрудников в монорепозиториях" и очень далеко от "кровавого энтерпрайза".
Эх, я надеялся на конструктивную беседу и более уверенную и аргументированную позицию, а не на ожесточенное отбрехивание какахами. Правда было интересно, почему у вас настолько безапелляционная позиция без видимого основания, идущая вразрез с общим мнением.
Спасибо за ответ! Тогда к обещанным примерам.
Я упоминал специфику 1С с несколькими средами и поставками вендора. Образовалась ситуация, когда типовая версия поставщика безнадежно устарела и из-за режимов совместимости конфигурации и несовместимости между собой версий новой IDE, поддерживающей гит, невозможно было впрямую актуализировать продукт. Была проделана немного неприглядная, но давшая результат операция, сравнимая в хирургии с выращиванием носа на лбу из складок с задницы и последующей пересадкой его на лицо. В терминах системы управления версиями разворачивались отдельные репозитории и сериями последовательных сравнений вычищались конфликты, мешающие обновлению. Потом готовый артефакт бережно переносился в основной репозиторий, как будто это изначально было сделано там. Через среду это делать было бы довольно затруднительно, у нее эклипсовская основа с неродным гит-плагином. Здесь еще вмешивается оперирование несколькими проектами в рамках одной рабочей задачи, и у эклипса есть тоже свои нюансы, ну банально нельзя два проекта с одинаковыми именами держать в рабочей области.
В одной из команд используется сломанный гит-флоу. Постоянно возникают конфликты слияния, которые необходимо разрешать на стороне клиента и через форс опцию переписывать центральный репозиторий. Через ту же среду, кстати. Это не очень этично по отношению к разрабам, но поменять процесс невозможно по административным причинам. Плюс сотрудники продолжают иногда перетирать результат работы других и приходится восстанавливать свои внезапно исчезнувшие правки.
Есть проект статической документации на mkdocs, там vscode справляется, ок, но мне не очень наглядно сравнивать куски кода общим списком в паре популярных расширений, другие не смотрел.
Была проблема с внутренней самописной компонентой доступа к кафке. Автор был недоступен, пришлось ставить студию и резко разбираться в C#, чтобы внести небольшую правку. Опыт в студии у меня нулевой, встроенным плагином совместной разработки не владею, да и не хочу, пока принципиально не принял решения менять стек на дотнет.
Плюс есть небольшие менторские активности в виде обучения с нуля, где код и обучающие материалы хранятся вместе, а язык, и соответственно, среда, обучающимися не выбраны окончательно.
Во всех этих ситуациях использовал Sublime Merge, как один универсальный инструмент, не зависящий от среды, для меня это было критично. Плагин от студии мне не подходит.
С гитлабом возможно действительно поспешил, в тех простых скриптах с которыми я работал, действительно нет прямого упоминания гита. Но что-то мне говорит, что на полноценной должности девопса такая необходимость появиться может и не будет чем-то выдающимся.
Я не настаиваю на конкретном инструменте, но не согласен с мнением, что есть возможность и настоятельно рекомендовано оставаться в рамках плагина определенной IDE и избегать изучения самой технологии гита в отрыве от ее реализации в виде плагина или инструмента, приводя в защиту своей позиции аргументы, похожие на самооправдания.
Наши девопсы не переваливают свои задачи на нас)
То-то я гляжу, вы только одним пользуетесь, в одной среде. Времени, наверное, нет бегать по средам, ах да, вы же скрипты за девопсов пишите.
Вы по причине кажущейся вам неуважительности от понтов переходите на личности и агрессию? Или из-за неуверенности в собственной позиции?
А по TBD принято, и TBD используется много где, в том же Тинькове, например. Там энтерпрайз не просто кровавый, а с содомом и расчлененкой.
Сочувствую вашему опыту. Мне же попадались люди, у которых много чему полезному можно научиться. И на удивление, они все избегали безапелляционной категоричности и примитивных жаргонизмов в обсуждениях.
Я до сих пор не вижу, какая методология используется в ваших монорепозиториях. Ну и метрики в отношении численности команд, частоты коммитов, наличия переходных процессов, если можно.
Все баги были решены. Последний клик по клавиатуре поставил жирную точку в этом модуле. Я снял палец с левой кнопки мыши - все было закоммичено. Напоследок системные часы в трее судорожно моргнули. Биения кварцевого кристалла передавались счетчику секунд и походили на удары сердца, складываясь в слоги: во-сем-над-цать-ноль-ноль. Люблю круглые числа, пора идти домой. Я накинул куртку... "ги-и-ит", - послышался голос на краю сознания. "Мой любимый плагин...", - вяло откликнулся я, погруженный в свои мысли. "Гии-и-и-и-иит", - уже громче и протяженнее прозвучал голос. "ГИТ!", - он резко превратился в крик и грянул как окрестр, составленный целиком из одних медных труб.
Я очнулся и взглянул на экран с окном видеоконференции. Часы снова моргнули и показали 14:48. Собеседование шло уже 15 минут, если не считать тех трех, на которые опоздал мой наниматель. Какая вопиющая непунктуальность.
– Простите, что вы сказали? – неожиданно произнес мой собственный голос.
– Вы когда–нибудь использовали гит? – спросил интервьювер.
– Вы имеете ввиду плагин в студии? – уточнил я.
– Нет, я имею ввиду чистый гит. Давайте так, опишите своими словами, как сами понимаете, что происходит, например, во время операции коммита.
– Ну, я обычно нажимаю кнопку, а плагин делает все сам, – обрадовал его я. "Кто в современном мире вообще учит чистый гит, – промелькнула мысль, – опять попался какой–то идиот, который спрашивает по анкете из интернета".
– Хм. Понятно... А какие вообще команды знаете? – не отставал собеседник.
– Вам надо настроить свой приватный гит–сервис? – я попытался перехватить инициативу.
– Нет, у нас используется GitLab, пока его возможностей хватает.
– А тогда зачем команды? – почти искренне удивился я.
– Хорошо, принято... Давайте перейдем к следующему вопросу.
Тот день изменил все. Мне опять никто не перезвонил, и я решил наконец скачать шпаргалку с командами. Не то, что бы я реально вкурил, как они работают, но по крайней мере, рекрутеры сразу увядают, как двойка перед королевским джокером, после того, как я говорю "ребэйз" и "черри–пик". Мне даже выставили пару хороших офферов, но там не было моей любимой среды с шикарным плагином, и я отказался. Но прошло время, и теперь я уже сам иногда сомневаюсь, не стоит ли начать писать свои скрипты по-другому, чтобы заранее скачивать код с гитхаба, например, так – git clone ...
Ну нет, так нечестно) Хоть он и не к вам был изначально, но мой вопрос про методологию уже в который раз остался без ответа. "Методология не нужна" не принимается. Сначала ответьте, как у вас, прежде чем мы продолжим обсуждение)
Я же их описал. Все четыре приходилось решать.
Не нужно пользоваться пакетным менеджером в вашей любимой среде. Пишите свои библиотеки.
С самого начала написал, что вопрос в зоне ответственности. Если вам так легко в рассуждениях отбросить как перечисленные вами и мной сценарии, так и те, которые остались за кадром, и о которых вы не подозреваете, значит у вас просто не очень большая зона ответственности. Это нормально, но подход "я не выхожу из среды лишний раз" - как раз следствие, что за вас кто-то очень сильно и много подумал и реализовал, и не только разработчики среды, а даже в том числе и в вашей собственной компании.
Если правильно вас понял, то достичь простоты, ощущать дзен и быть понятным - как раз, наоборот, самое сложное в карьере разработчика)
Для этого надо иметь очень широкий кругозор, многогранный опыт, быть открытым и толерантным к новым подходам, идеям и чужому мнению и владеть фундаментальными основами. Использование сырого гита релевантно всем пунктам)
Ок, если кратко - плагина не хватает там, где нет GUI.
Если вы работаете в кровавом энтерпрайзе, у вас наверняка есть девопсы/SRE. Если вы наблюдали за их работой тоже, могли заметить, что они пишут скрипты для CI/CD, в котором гит вызывается, внезапно, консольно. Если контура многогранные и процессы поставки сложные, скрипты тоже будут сложные, а не просто "гит пулл".
Про методологию спросил тоже не просто так. TBD предполагает разворачивание feature-контуров, отдельных виртуалок под тестирование атомарных функциональных задач. Что тоже удобно скриптуется и тоже требует консоль.
Наконец, плагин в одной среде - ок. А вот если плагины в разных средах, пусть это будет например, IntelliJ + Studio + VSCode + еще что-нибудь, то для человека в кросс-командной роли, который прыгает между разными командами, стеками, средами и репозиториями, вроде как удобнее использовать один внешний инструмент, а не конкретный плагин, чтобы не переключаться между нюансами использования в разных реализациях. Такие люди в компаниях есть, обычно это амбициозные, не боящиеся изучать новое сотрудники, которых привлекают к поднятию с нуля новых или разгребанию старых закостеневших процессов.
Про 1С, 2 языка, 3 IDE, особенности сравнения xml-фалов (для тех же правил конвертации), наверное, не буду рассказывать, чтобы не триггерить вас лишний раз. Как минимум, заверю вас, что плагин там хоть и стабильный, но не очень неудобный.
Не будете, плиз, столь любезны в ответ рассказать про вашу инфраструктуру и методологию? Хочется понять, почему вы отвергаете инструменты, кроме плагина и избегаете чистого гита.
Можно поинтересоваться, на каких методологиях выстроены монорепы (GitFlow, TBD)? Были ли в процессе вашего наблюдения смена методологии в командах? Стек тоже, получается, у всех общий?
Вопрос в зоне ответственности, численности команды, и с какой стороны код-ревью находишься. Чем дальше, тем больше непростых сценариев, связанных с организацией работы большой команды, параллельными обновлениями вендором программного продукта, коллизий с одновременной разработкой функционала. Тут уже желательно погибче владеть инструментом, чтобы наладить работу. Пусть и не обязательно прямо через консоль (есть удобные графические оболочки), но и на плагине уже не выедешь.
О, спасибо за выжимку! Так основная мысль доносится быстрее. Спасибо, что прислушались и начали исправляться!
Но мой посыл остался тем же, - вы пользуетесь плодами революции, чтобы с извращенным кайфом описывать несовершенство системы в этой же самой системе, попутно обвиняя инструментарий и подходы революции, приведшие к созданию этой системы. И не готовы при этом подстроиться со своей стороны и поступиться частью убеждений, например, не писать ненужные подробности в отзывах. Это забавно)
После прочтения статьи больше задумался о границе между принципиальностью и занудством. Ненужное графоманство в отзывах на торговой площадке - прям хороший маркер. И с выводом не согласен, - наоборот, такая революция нужна. Люди теперь могут удовлетворять свои некомфортные для других потребности в суррогатных беседах с компьютером, не мешая остальным. Это ли не чудо прогресса?
Фух, хорошо, что Таро обошли стороной, карты вне подозрений!
Интерактивным сравнением/объединением. Эта возможность доступна как при слиянии веток, так и при сравнении разных конфигураций между собой. Это специальный инструмент (команда, окно, форма) edt, экранирующий внутренний формат хранения. Вы правда не знали про него?
То есть про делегацию сложности вы проигнорировали. Остался только страх...
По большому секрету скажу, что у 1С есть собственное окно сравнения, которое учитывает всю специфику своих же xml. И я не зря упомянул про возможность локального разрешения конфликтов. То, что вы лезете в формат исходников - исключительно ваша осознанная воля, а может, даже и провокация.
Вы бы хоть матчасть подтянули, прежде чем аппелировать к тому, что считаете больным местом. В кажущихся вам выдуманными мирах это не представляет такой сложности.
Мне кажется, довольно поспешно и недружелюбно с вашей стороны называть мою реальность выдуманной.
Хотелось бы услышать агрументированную и заслуженную критику без прилагательных в превосходной степени сравнения.
На моей стороне успешный опыт использования предложенной выше схемы, понимание преимуществ гита, делегация сложности нового формата хранения исходников edt собственно самой edt, и нейтральное спокойное принятие подходов к переиспользованию кода от авторов типовых конфигураций. Что может предложить ваш мир, кроме страха перед спагетти?
Как же вам, должно быть, сложно ловить собеседника на выдуманных ограничениях, искусственно раздувать проблему и потом героически переводить разговор в обсуждение того, что умеет и как бы тут пригодился lsfusion.
Давайте я отвечу по существу вместо автора статьи. Проект переносится в git и EDT, за первоначальный коммит берется конфигурация поставщика, от ствола ответвляется ветвь с чистой конфигурацией поставщика и периодически обновляется поставкой и вливается в основной ствол репозитория. Git уже на этом этапе разрешает всевозможные конфликты слияния кодовой базы. Если не решает - слияние выносится в локальный репозиторий, проводится на локальных ветвях, и EDT, с учетом специфики метаданных и платформы, с помощью платформенного сравнения добивает оставшиеся конфликты. После чего локальное разрешение конфликтов отправляется в удаленный репозиторий.
Это чисто на уровне гита. А на уровне разработки выбор просто широчайший – методы-заглушки, перенаправления на свои методы в начале типовых методов, отдельные подсистемы, общие реквизиты, регистры с любыми объектами в измерениях и многое другое.
Таким образом, никакой код нельзя назвать лишним, потому что, употребляя ваши просторечные обороты, он "спокойно лежит и каши не просит", и никому не мешает. Исправленный код спокойно сольется при описанной выше схеме.
Если будете предлагать стандартный набор возражений, что EDT сырая, требует много памяти, зачем 1С две среды разработки, зачем переводить проект в гит и прочий абсурд, то лучше давайте сразу не продолжать обсуждение, потому что в итоге можно все свести к гиту, а против него и его возможностей спорить бесполезно.
Вот дураки, за лицензии 1С платят, когда опенсурс есть. Полстраны дураков.
Вот дураки, надо было lsfusion покупать. Там же ноль противоречий.