Комментарии
Избранное
Подписка
Сортировка:
Древо
Немного покритикую
1) Если использовать выгрузку в гит, то можно не указывать комментарии в своих модулях и не указывать кучу комментариев если код был изменен по нескольким задачам, а просто оставить одно обрамление, что это не типовой код, а наш. Просматривать историю и искать авторов в гите конечно чуток сложнее, чем по комментариям восстановить, но зато код намного чище, да и искать виновника обычно нужно не так часто, если выполняется код-ревью. Код-ревью в гите, кстати, вообще сказка
2) Если использовать сторонние программы для сравнения (я , он вроде как бесплатен для небольших команд) то быстро понимаешь, что зря не пользовался ими раньше при обновлении. Обновление модулей становится проще в 10 раз. И тут всплывает ньюанс. Такие программы сравнивают построчно, а не попроцедурно, и если что то было закомментировано, а в поставке добавили пробел - получили двойное изменение. Поэтому я предпочитаю по максимуму код от типовой не трогать, а решать только добавлением новых строчек - возврат, окружать Если Ложь Тогда итп
3) Для префиксации очень удобным оказался префикс "_" и "*" для синонимов. Они коротки и они выводят новые объекты вверх при сортировке, а обычно новые объекты нужны чаще, чем типовые. Для разработки коробочного решения такая префиксация не подходит, конечно.
4) Предопределенные элементы стоит добавлять только в те объекты, где их до этого не было, иначе если с новой типовой придет новый предопределенный объект, будет весело в любом случае. Тут ждем 8.3.11. Если все таки пришлось изменить предопределенные, то оставляю комментарий в корневом объекте, чтоб при сравнении объединении было видно и 1. что набор предопределенных изменений конфликтует 2. комментарий к объекту был изменен
5) Не понимаю этого фанатизма в использовании подписки для изменения логики в одном документе. В случае обновления если использовать п.2 проблем не возникает вообще, а вот убить кучу времени на выяснение логики работы документа при проведении, когда часть вынесена в подписки - это вообще запросто
1) Если использовать выгрузку в гит, то можно не указывать комментарии в своих модулях и не указывать кучу комментариев если код был изменен по нескольким задачам, а просто оставить одно обрамление, что это не типовой код, а наш. Просматривать историю и искать авторов в гите конечно чуток сложнее, чем по комментариям восстановить, но зато код намного чище, да и искать виновника обычно нужно не так часто, если выполняется код-ревью. Код-ревью в гите, кстати, вообще сказка
2) Если использовать сторонние программы для сравнения (я , он вроде как бесплатен для небольших команд) то быстро понимаешь, что зря не пользовался ими раньше при обновлении. Обновление модулей становится проще в 10 раз. И тут всплывает ньюанс. Такие программы сравнивают построчно, а не попроцедурно, и если что то было закомментировано, а в поставке добавили пробел - получили двойное изменение. Поэтому я предпочитаю по максимуму код от типовой не трогать, а решать только добавлением новых строчек - возврат, окружать Если Ложь Тогда итп
3) Для префиксации очень удобным оказался префикс "_" и "*" для синонимов. Они коротки и они выводят новые объекты вверх при сортировке, а обычно новые объекты нужны чаще, чем типовые. Для разработки коробочного решения такая префиксация не подходит, конечно.
4) Предопределенные элементы стоит добавлять только в те объекты, где их до этого не было, иначе если с новой типовой придет новый предопределенный объект, будет весело в любом случае. Тут ждем 8.3.11. Если все таки пришлось изменить предопределенные, то оставляю комментарий в корневом объекте, чтоб при сравнении объединении было видно и 1. что набор предопределенных изменений конфликтует 2. комментарий к объекту был изменен
5) Не понимаю этого фанатизма в использовании подписки для изменения логики в одном документе. В случае обновления если использовать п.2 проблем не возникает вообще, а вот убить кучу времени на выяснение логики работы документа при проведении, когда часть вынесена в подписки - это вообще запросто
(1)
Ну что ж, отвечаю:
1) Гитом не пользуемся. Наверное стоит попробовать, но пока хватает и хранилища. Если наш код становится уж совсем "зеленым", то делаем рефакторинг. В этом случае, весь старый, уже точно не имеющий смысла закомментированный код удаляем. В крайнем случае, остается история в хранилище.
2) У нас тоже есть разработчики, которые для сравнения используют сторонние программы. Но лично я пользуюсь типовым функционалом из-за попроцедурного сравнения.
3) Часто бывает, что эту же конфигурацию модифицирует еще кто-то (например сторонняя организация или же свои специалисты). Тогда префикс "_" не подойдет. А в целом, почему бы и нет.
4) Не понял, почему не надо добавлять предопределенные элементы? При сравнении проблем нет. Если приходит предопределенный элемент из новой конфигурации поставщика, то проблем тоже не вижу. Наши объекты добавлены с префиксом, совпадения имен быть не может.
5) Ну тут дело привычки. У нас все разработчики знают и используют правила, поэтому время на разбор и понимание логики не тратится. Подписка то всего одна, а уже в ней по каждому типу документа вызываются необходимые обработчики.
6) Абсолютно согласен. Типовые роли не трогаем (или только в самом крайнем случае). Это стало особенно актуально в конфигурациях на БСП 2, где на каждый объект, как правило, есть одна или две роли. В этом случае на все свои добавленные объекты также создаем отдельные роли. А дальше уже идет настройка профилей и групп пользователей.
8) Наверное вы правы, но вроде как пока хватает и просто функции ВТ().
9) Согласен. Это очень хорошая мотивация. Но вот только беда, что стажеру или молодому специалисту не очень то доверишь обновление конфигурации. Тут только строгое соблюдение правил и обязательное код-ревью.
Ну что ж, отвечаю:
1) Гитом не пользуемся. Наверное стоит попробовать, но пока хватает и хранилища. Если наш код становится уж совсем "зеленым", то делаем рефакторинг. В этом случае, весь старый, уже точно не имеющий смысла закомментированный код удаляем. В крайнем случае, остается история в хранилище.
2) У нас тоже есть разработчики, которые для сравнения используют сторонние программы. Но лично я пользуюсь типовым функционалом из-за попроцедурного сравнения.
3) Часто бывает, что эту же конфигурацию модифицирует еще кто-то (например сторонняя организация или же свои специалисты). Тогда префикс "_" не подойдет. А в целом, почему бы и нет.
4) Не понял, почему не надо добавлять предопределенные элементы? При сравнении проблем нет. Если приходит предопределенный элемент из новой конфигурации поставщика, то проблем тоже не вижу. Наши объекты добавлены с префиксом, совпадения имен быть не может.
5) Ну тут дело привычки. У нас все разработчики знают и используют правила, поэтому время на разбор и понимание логики не тратится. Подписка то всего одна, а уже в ней по каждому типу документа вызываются необходимые обработчики.
6) Абсолютно согласен. Типовые роли не трогаем (или только в самом крайнем случае). Это стало особенно актуально в конфигурациях на БСП 2, где на каждый объект, как правило, есть одна или две роли. В этом случае на все свои добавленные объекты также создаем отдельные роли. А дальше уже идет настройка профилей и групп пользователей.
8) Наверное вы правы, но вроде как пока хватает и просто функции ВТ().
9) Согласен. Это очень хорошая мотивация. Но вот только беда, что стажеру или молодому специалисту не очень то доверишь обновление конфигурации. Тут только строгое соблюдение правил и обязательное код-ревью.
(7) 1) Если у вас постоянно проходит код-ревью, то очень рекомендую поупражняться с выгрузкой в гит
2) Я тоже очень долго был консервативен, а потом попробовал и внезапно стало очень удобно, чем по типовому. Рекомендую себя пересилить и еще раз попробовать.
4) Вроде при двойном изменении можно только или все взять из поставки или оставить как есть, объединить не получается, как и с типами
8) Очень рекомендую использовать при разработке инструменты разработчика. Прям вот самое первое, что я делаю на любом проекте - подключаю ИР, вкрячивая в конфу или через внешние файлы. А теперь еще можно и как расширение подключать.
2) Я тоже очень долго был консервативен, а потом попробовал и внезапно стало очень удобно, чем по типовому. Рекомендую себя пересилить и еще раз попробовать.
4) Вроде при двойном изменении можно только или все взять из поставки или оставить как есть, объединить не получается, как и с типами
8) Очень рекомендую использовать при разработке инструменты разработчика. Прям вот самое первое, что я делаю на любом проекте - подключаю ИР, вкрячивая в конфу или через внешние файлы. А теперь еще можно и как расширение подключать.
(1)
Поддерживаю полностью. Использую KDiff3, пробовал разные, этот самый удобный и функциональный, посимвольно сравнивает + поддержка трёхсторонего сравнения.
2) Если использовать сторонние программы для сравнения (я использую P4, он вроде как бесплатен для небольших команд) то быстро понимаешь, что зря не пользовался ими раньше при обновлении. Обновление модулей становится проще в 10 раз.
Поддерживаю полностью. Использую KDiff3, пробовал разные, этот самый удобный и функциональный, посимвольно сравнивает + поддержка трёхсторонего сравнения.
6) Типовые роли лучше вообще не трогать. Сколько раз менял, столько раз имел проблемы. Если и менять, то прям в комментарии к объекту писать что именно изменено. РЛС в типовых не менял ни разу, видимо изза того, что я так и не смог раскурить что происходит в БСП или в документообороте.
7) Обработка инициализации по правильному вроде называется миграцией данных, но это не точно.
8) Про справочник предопределенных значений хорошая идея, утащу к себе. У нас есть похожий механизм под кодовым названием "Экспериментальные функции". Если есть старый алгоритм чего то и мы разработали новый, но не очень в нем уверены, то старый не удаляем, а переключаем с помощью значения в предопределенном элементе в справочнике, типа так Если Справочники.ЭкспФункции.ИспользоватьНовыйАлгоритм.Включена Тогда НовыйАлгоритм() Иначе СтарыйАлгоритм() КонецЕсли
8) Про просмотр временных таблиц. Если вкрячить инструменты разработчика, то так же появится метод от() который передаст в нужную консоль запрос, компоновку или еще чего. Крайне полезно при отладке чего то тяжелого.
9) Чтобы научить программиста дорабатывать конфу так, чтоб легче было обновлять его следует сперва заставить выполнить обновление, чтоб он на все возможные проблемы понатыкался, а уже потом давать правила
7) Обработка инициализации по правильному вроде называется миграцией данных, но это не точно.
8) Про справочник предопределенных значений хорошая идея, утащу к себе. У нас есть похожий механизм под кодовым названием "Экспериментальные функции". Если есть старый алгоритм чего то и мы разработали новый, но не очень в нем уверены, то старый не удаляем, а переключаем с помощью значения в предопределенном элементе в справочнике, типа так Если Справочники.ЭкспФункции.ИспользоватьНовыйАлгоритм.Включена Тогда НовыйАлгоритм() Иначе СтарыйАлгоритм() КонецЕсли
8) Про просмотр временных таблиц. Если вкрячить инструменты разработчика, то так же появится метод от() который передаст в нужную консоль запрос, компоновку или еще чего. Крайне полезно при отладке чего то тяжелого.
9) Чтобы научить программиста дорабатывать конфу так, чтоб легче было обновлять его следует сперва заставить выполнить обновление, чтоб он на все возможные проблемы понатыкался, а уже потом давать правила
(2)
По мне так, авторские комментарии в коде это зло, тем более с датой. Максимум обрамление кода комментариями команды - организации. А там уже и blame в гите глянуть можно.
Просто бывают ситуации, что в авторский код залез другой автор и просто забыл еще обрамить своими комментариями, хотя если, допустим второй автор добавляет просто проверку на условие то получается пишет 2 строчки кода и 4 строчки комментариев к ними. Плюс забывают менять даты изменений, что тоже может запутать других.
Для новых алгоритмов используем функциональные опции. Хотя со справочником тоже интересно, надо попробовать.
Сейчас все пытаюсь 4 базы с разными наработками объединить в одну, для удобства поддержки, Как раз нетиповой функционал каждой базы обрамляется функ.опц, Допустим в 3х базах используется одни и тот же функционал, но в 3й еще есть свои дописки, а функционал 4й базы наверняка в скором времени понадобится и в какой нибудь из этих 3х.
На счет обработки инициализации...хотим у себя как раз подобное попробовать, но рабочее название константы пока "Номер сборки" - номер коммита в мастер хранилищи. Т.е добавили роль, написали что в 100500 номере сборки надо сделать обновление вспомогательных данных.
На счет интерактивных изменений форм делаем так, с начало в ветке фичи все делается прям на форме, для быстроты прототипирования и наглядности. Потом декомпелируем форму, но если не успеваем, вешается тех.долг по переносу интерактивных изменений в код
По мне так, авторские комментарии в коде это зло, тем более с датой. Максимум обрамление кода комментариями команды - организации. А там уже и blame в гите глянуть можно.
Просто бывают ситуации, что в авторский код залез другой автор и просто забыл еще обрамить своими комментариями, хотя если, допустим второй автор добавляет просто проверку на условие то получается пишет 2 строчки кода и 4 строчки комментариев к ними. Плюс забывают менять даты изменений, что тоже может запутать других.
Для новых алгоритмов используем функциональные опции. Хотя со справочником тоже интересно, надо попробовать.
Сейчас все пытаюсь 4 базы с разными наработками объединить в одну, для удобства поддержки, Как раз нетиповой функционал каждой базы обрамляется функ.опц, Допустим в 3х базах используется одни и тот же функционал, но в 3й еще есть свои дописки, а функционал 4й базы наверняка в скором времени понадобится и в какой нибудь из этих 3х.
На счет обработки инициализации...хотим у себя как раз подобное попробовать, но рабочее название константы пока "Номер сборки" - номер коммита в мастер хранилищи. Т.е добавили роль, написали что в 100500 номере сборки надо сделать обновление вспомогательных данных.
На счет интерактивных изменений форм делаем так, с начало в ветке фичи все делается прям на форме, для быстроты прототипирования и наглядности. Потом декомпелируем форму, но если не успеваем, вешается тех.долг по переносу интерактивных изменений в код
Офис 2016, файл не открывается. Что за бред оформлять статьи в виде каких-то документов. А если у меня офис вообще не установлен и нет лицензии на его использование, получается статью мне не прочитать? Оформите пожалуйста статью в соответствии с правилами. А так это не статься а просто бесполезный текст.
Прикрепленные файлы:
(6) никакого отношения к ресурсу (Инфостарт) на котором вы публикуете статью не имеет это первое. Вы нигде в статье не сослались ни на видео которое вы записывали когда готовились к выступлению, ни на ссылки которые указали сейчас в сообщении, документ который вы прикрепили к сожалению тоже не открывается - вывод полезной информации в статье ноль. А еще и имеете неосторожность при этом минусовать вполне адекватные замечания. Тут телепатов нет, все уехали готовиться к INFOSTART EVENT 2017 COMMUNITY. Отрицательно воспринимаете критику? Я понимаю, что возможно там полезной инфы на докторскую диссертацию, но черт возьми, так оформлять статью никуда не годится, зачем вообще добавили ее если нет возможности ее НИКАК прочесть?
(9)
Что вы на меня напали? Критику я воспринимаю адекватно. Я вас не минусовал.
Более того, я вам открою секрет, это даже не я публиковал статью, а модераторы infostart.ru на основании моего выступления.
Все ссылки, кстати, есть в конце статьи. Сожалею, что у вас не получилось открыть документ .docx. Напишите почту в личном сообщении, я вышлю вам PDF версию.
Что вы на меня напали? Критику я воспринимаю адекватно. Я вас не минусовал.
Более того, я вам открою секрет, это даже не я публиковал статью, а модераторы infostart.ru на основании моего выступления.
Все ссылки, кстати, есть в конце статьи. Сожалею, что у вас не получилось открыть документ .docx. Напишите почту в личном сообщении, я вышлю вам PDF версию.
(16)
Даже и не думал. Просто хочется, чтобы другие люди которые захотят изучить материал не столкнулись с этими же проблемами.
(16)
Жаль, что модераторы так бездарно (по другому не могу назвать) оформили такую отличную статью...
(16)
Ничего нет. К счастью информацию умею искать хорошо и к сожалению ничего не удалось найти по ссылкам. Единственная ссылка ведет на страницу с информацией об INFOSTART EVENT, там разумеется ничего о статье. Прикладываю подтверждения
Что вы на меня напали?
Даже и не думал. Просто хочется, чтобы другие люди которые захотят изучить материал не столкнулись с этими же проблемами.
(16)
не я публиковал статью, а модераторы infostart.ru на основании моего выступления.
Жаль, что модераторы так бездарно (по другому не могу назвать) оформили такую отличную статью...
(16)
Все ссылки, кстати, есть в конце статьи.
Ничего нет. К счастью информацию умею искать хорошо и к сожалению ничего не удалось найти по ссылкам. Единственная ссылка ведет на страницу с информацией об INFOSTART EVENT, там разумеется ничего о статье. Прикладываю подтверждения
Прикрепленные файлы:
(6) видос сделан качественно ) "расширения" не используете ? До "расширений" тоже добавляли программно на форму но расширения как-то все упростили да и роли тоже а сейчас и ОМ и др. модули можно править расширениям (правда нативных конф 1с под 8.3.10 нет пока)
(11)
На текущий момент расширения хорошо подходят для доработки форм и объектов интерфейса, добавления и вывода в интерфейс своих обработок, отчётов и т.п. минуя механизмы БСП в типовых конфигурациях без включения возможности изменения конфигурации. Как только типовые будут переведены на БСП 2.4 возможности применения расширений для доработки полностью типовых конфигураций существенно расширятся.
Для типовых конфигураций с изменённым режимом совместимости все возможности расширений можно использовать уже и сейчас.
Основной нюанс, на текущий момент - для расширений нет встроенных в платформу систем версионирования, поэтому при разработке для контроля версий приходится использовать сторонние решения, такие как Mercurial, Git и т.п.
Расширениями не пользуетесь? До сих пор не могу для себя решить если в них польза.
На текущий момент расширения хорошо подходят для доработки форм и объектов интерфейса, добавления и вывода в интерфейс своих обработок, отчётов и т.п. минуя механизмы БСП в типовых конфигурациях без включения возможности изменения конфигурации. Как только типовые будут переведены на БСП 2.4 возможности применения расширений для доработки полностью типовых конфигураций существенно расширятся.
Для типовых конфигураций с изменённым режимом совместимости все возможности расширений можно использовать уже и сейчас.
Основной нюанс, на текущий момент - для расширений нет встроенных в платформу систем версионирования, поэтому при разработке для контроля версий приходится использовать сторонние решения, такие как Mercurial, Git и т.п.
(53)
Если у вас совсем немного разработки, или же всей разработкой занимаются 1-2 человека, то можно поступить и так, как вы написали: рабочую базу подключить к разработочному хранилищу. Такой подход также может быть допустим на начальных этапах проекта.
Но если же в продуктивной базе уже идет работа пользователей и работоспособность информационной базы критична для бизнеса, а на проекте занято достаточное число людей и активно идет разработка, то перенос непротестированной или несогласованной модификации может привести к ошибкам и простою. Кроме того, бывают ситуации, когда в одном объекте могут быть уже выполненные и протестированные задачи, и части кода, которые находятся еще в разработке, соответственно переносить весь объект в рабочую базу нельзя.
Подробнее о схеме разработки, применяемой нами в поддержке и на проектах, я рассказывал, например, в начале вот этого видео:
Если у вас совсем немного разработки, или же всей разработкой занимаются 1-2 человека, то можно поступить и так, как вы написали: рабочую базу подключить к разработочному хранилищу. Такой подход также может быть допустим на начальных этапах проекта.
Но если же в продуктивной базе уже идет работа пользователей и работоспособность информационной базы критична для бизнеса, а на проекте занято достаточное число людей и активно идет разработка, то перенос непротестированной или несогласованной модификации может привести к ошибкам и простою. Кроме того, бывают ситуации, когда в одном объекте могут быть уже выполненные и протестированные задачи, и части кода, которые находятся еще в разработке, соответственно переносить весь объект в рабочую базу нельзя.
Подробнее о схеме разработки, применяемой нами в поддержке и на проектах, я рассказывал, например, в начале вот этого видео:
(14)
Пока в расширениях нет возможности создавать свои объекты и реквизиты объектов, никакого смысла в них не вижу. В 8.3.11 вроде такая возможность будет, но тут же мы натыкаемся на режим совместимости типовых конфигураций. Так что расширения не используем.
Почти всегда обновления готовим через файл cf. Хотя есть также опыт и обновления через поставку на территориально распределенных площадках.
Пока в расширениях нет возможности создавать свои объекты и реквизиты объектов, никакого смысла в них не вижу. В 8.3.11 вроде такая возможность будет, но тут же мы натыкаемся на режим совместимости типовых конфигураций. Так что расширения не используем.
Почти всегда обновления готовим через файл cf. Хотя есть также опыт и обновления через поставку на территориально распределенных площадках.
По большей части согласен. Могу добавить "отсебятины":
1. часто вместо добавления реквизитов или табличных частей справочников и документов выгодным оказывается удобнее добавить регистр сведений, связанный через измерения с основным объектом, а в ресурсах хранящий необходимую информацию.
2. типовые объекты, куда не успели вмешаться, держим "под замком". Это одновременно индикатор и защита от случайных правок из разряда "лишний пробел"
3. В шаблонах кода очень удобно разместить собственный комментарий. Результат - при нажатии Ctrl + пробел в пустом месте в одной из верхних строк прелагается к вставке личная метка с текущей датой.
4. Касательно нетиповых участков - по возможности используем параметризированные запросы вместо склейки из строк. Сохранение возможности открыть запрос конструктором - небольшой бонус, позволяющий быстро отформатировать исправленный руками запрос и заодно проверить синтаксис (как известно, неправильный запрос конструктором не открывается). Комментирование внутри запроса достаточно бесполезно, т.к. исчезает при вызове конструктора, поэтому проще размещать тексты запросов в отдельных функциях, а перед правкой создавать копию всей функции с видоизмененным именем.
5. Громоздкие функции и процедуры удобнее дробить на мелкие, чем читать все это как сплошной текст.
6. Выигрышь в быстродействии на 5-10% за счет запутывания разрастания и усложнения кода пользователи не оценят. Но большинство оценивает разработку/доработки в короткий срок. Если Вы видите, что схожие подзадачи возникают с завидной регулярностью, чаще всего проще потратить полдня на универсальную функцию или механизм, закрывающие их все разом.
Например, однажды написав и вызвая в своих разработках функцию "ПреобразоватьТаблицуВДерево" скорее всего вы сможете выиграть больше времени по сравнению с описанием этого процесса в каждой отдельно взятой задаче.
1. часто вместо добавления реквизитов или табличных частей справочников и документов выгодным оказывается удобнее добавить регистр сведений, связанный через измерения с основным объектом, а в ресурсах хранящий необходимую информацию.
2. типовые объекты, куда не успели вмешаться, держим "под замком". Это одновременно индикатор и защита от случайных правок из разряда "лишний пробел"
3. В шаблонах кода очень удобно разместить собственный комментарий. Результат - при нажатии Ctrl + пробел в пустом месте в одной из верхних строк прелагается к вставке личная метка с текущей датой.
4. Касательно нетиповых участков - по возможности используем параметризированные запросы вместо склейки из строк. Сохранение возможности открыть запрос конструктором - небольшой бонус, позволяющий быстро отформатировать исправленный руками запрос и заодно проверить синтаксис (как известно, неправильный запрос конструктором не открывается). Комментирование внутри запроса достаточно бесполезно, т.к. исчезает при вызове конструктора, поэтому проще размещать тексты запросов в отдельных функциях, а перед правкой создавать копию всей функции с видоизмененным именем.
5. Громоздкие функции и процедуры удобнее дробить на мелкие, чем читать все это как сплошной текст.
6. Выигрышь в быстродействии на 5-10% за счет запутывания разрастания и усложнения кода пользователи не оценят. Но большинство оценивает разработку/доработки в короткий срок. Если Вы видите, что схожие подзадачи возникают с завидной регулярностью, чаще всего проще потратить полдня на универсальную функцию или механизм, закрывающие их все разом.
Например, однажды написав и вызвая в своих разработках функцию "ПреобразоватьТаблицуВДерево" скорее всего вы сможете выиграть больше времени по сравнению с описанием этого процесса в каждой отдельно взятой задаче.
Учитывая зияющие перспективы 1С по расширению данных, означенные извраты должны отойти в прошлое, где им самое место. Ибо всё это - от безысходности, а по-людски оно вообще модульно должно бы делаться) Но за труды респект.
(40)а как сделать "по-людски"?
1с делает свое. Вы - свое. Все независимо, а конечные данные одни и те же.
Расскажите как же помогут расширения, получить стабильно работающий адаптированный функционал?
А то пока занимался такими же "извратами" я сильно устарел.
Пока заказчиков расширения радуют только тем, что их можно выкинуть вместе с разработчиком. Хотя и не понятно, а как далее работать без расширения, если в нем производились какие-то полезные изменения все тех же конечных данных, а потом перестали? Забить?
Не надо только итс с зазеркальем цитировать. По существу есть что сказать?
1с делает свое. Вы - свое. Все независимо, а конечные данные одни и те же.
Расскажите как же помогут расширения, получить стабильно работающий адаптированный функционал?
А то пока занимался такими же "извратами" я сильно устарел.
Пока заказчиков расширения радуют только тем, что их можно выкинуть вместе с разработчиком. Хотя и не понятно, а как далее работать без расширения, если в нем производились какие-то полезные изменения все тех же конечных данных, а потом перестали? Забить?
Не надо только итс с зазеркальем цитировать. По существу есть что сказать?
На мой ИМХО самоя крутая вещь при разработке это расширения, ко всему можно привязаться не редактируя модули и формы.
Еще с начала года как 8.3.9 появилась, снял на свой страх и риск с БП 3.0 совместимость с 8.3.8 и вперед.Единственный минут они нормально работают только начиная с 8.3.9. Если режим совместимости меньше то приходится по старинке...
Еще с начала года как 8.3.9 появилась, снял на свой страх и риск с БП 3.0 совместимость с 8.3.8 и вперед.Единственный минут они нормально работают только начиная с 8.3.9. Если режим совместимости меньше то приходится по старинке...
(43)бп3 часто обновляется. Как часто приходится менять расширение?
Оно ведь слетит при изменении заимствований. Это весьма неприятная тема, так как адаптацию расширения делать придется уже после отказа.
Есть какие-нибудь соображения как с этим быть, кроме отключения автообновления у заказчика и проверки расширения на буферной базе?
Оно ведь слетит при изменении заимствований. Это весьма неприятная тема, так как адаптацию расширения делать придется уже после отказа.
Есть какие-нибудь соображения как с этим быть, кроме отключения автообновления у заказчика и проверки расширения на буферной базе?
Объемная статья с картинками и видео-приложением, отражающая определенный, систематизированный подход к обновлению конфигураций. Автору безусловный плюс. И большое спасибо всем, кто высказал свое мнение в комментариях. Много интересного.
(52) Расширение это альтернативный подход. Пока не заменяет полноценную доработку/ исправление ошибок в конфигурации.
Вон в ERP исправительные релизы выходят чуть ли ни каждую -две недели, релизы с новой версией бсп и полностью измененными общими модулями раз в несколько месяцев. Все равно раширение нужно переделывать, один плюс : конфигурация с поддержки не снимается, но если в ней расширения , то без помощи программиста не обойтись, тогда какой толк в автоматическом обновлении ?
Вон в ERP исправительные релизы выходят чуть ли ни каждую -две недели, релизы с новой версией бсп и полностью измененными общими модулями раз в несколько месяцев. Все равно раширение нужно переделывать, один плюс : конфигурация с поддержки не снимается, но если в ней расширения , то без помощи программиста не обойтись, тогда какой толк в автоматическом обновлении ?
Все так. Единственное для новых объектов или реквизитов делаем не префиксы, а суффиксы. так не надо помнить это наш объект при кодировании или типовой. На Вашем примере "Проекты_ФТО". Попробуйте и Вам захочется переименовать все что вы делали.
Эти правила плюсанул бы лет 5 назад. Сейчас же это уже атавизм.
Как тут уже писали, git blame покажет кто когда и зачем писал каждую строку. Даже у кода поставщика вы увидите какая строка в каком из ваших обновлений обновилась.
Если типовой код нужно поменять на ваш — меняйте, не нужно оставлять старый! Нужно посмотреть что было раньше? Посмотрите историю в git. В 1С — сравните с конфигурацией поставщика. При обновлении 99,9% таких правок модулей пройдёт автоматически при помощи инструмента типа KDiff3. Попроцедурное в 1С вам не поможет в случае изменения названия процедуры, а инструмент справится. То же касается и обработок событий проведения и т. п.
Кстати говоря, в конфигурациях на основе УТ11, ERP там за формирование движений отвечает много вспомогательных процедур в модуле менеджера. В этот механизм лучше и встаиваться — это как с программным изменением форм: сначала сложно, потом станет понятно.
Про префиксы. В именах — на ваше усмотрение, конечно. Мне лично они вообще не нравятся. Типовой это объект или новый видно сразу по пометке справа. В синонимах префиксы — вообще зло. Какая разница пользователям какой разработчик в рамках какого проекта это добавил/изменил? На целостность интерфейса пользователя это не должно влиять. А чтобы найти добавленные/изменённые объекты я добавляю их для себя в соответствующие подсистемы: Доработки/Измененные, Доработки/Новые. К тому же, если вы добавили новый объект/реквизит, а затем в обновлении поставщик добавил такой же, то это тот случай, когда нужно проанализировать этот объект. Возможно, это и должен быть 1 реквизит, уже типовой. Если вы добавили рекв. Основание, затем поставщик добавил рекв. Основание. В результате вам не нужно 2 реквизита Мой_Основание и Основание. Вам нужен именно 1, с объединёнными типами.
Ну и, конечно, большинство изменения типовых объектов нужно добавлять в автотесты. Например, добавили/удалили типы в определяемом типе — добавили в проверку. При обновлении такие объекты можно смело обновлять, а после — прогнать тесты и они покажут всё, что нужно куда добавить/удалить.
После перехода на такие правила обновление сильно доработанной КА2 у меня вместо нескольких дней стало занимать полдня.
Как тут уже писали, git blame покажет кто когда и зачем писал каждую строку. Даже у кода поставщика вы увидите какая строка в каком из ваших обновлений обновилась.
Если типовой код нужно поменять на ваш — меняйте, не нужно оставлять старый! Нужно посмотреть что было раньше? Посмотрите историю в git. В 1С — сравните с конфигурацией поставщика. При обновлении 99,9% таких правок модулей пройдёт автоматически при помощи инструмента типа KDiff3. Попроцедурное в 1С вам не поможет в случае изменения названия процедуры, а инструмент справится. То же касается и обработок событий проведения и т. п.
Кстати говоря, в конфигурациях на основе УТ11, ERP там за формирование движений отвечает много вспомогательных процедур в модуле менеджера. В этот механизм лучше и встаиваться — это как с программным изменением форм: сначала сложно, потом станет понятно.
Про префиксы. В именах — на ваше усмотрение, конечно. Мне лично они вообще не нравятся. Типовой это объект или новый видно сразу по пометке справа. В синонимах префиксы — вообще зло. Какая разница пользователям какой разработчик в рамках какого проекта это добавил/изменил? На целостность интерфейса пользователя это не должно влиять. А чтобы найти добавленные/изменённые объекты я добавляю их для себя в соответствующие подсистемы: Доработки/Измененные, Доработки/Новые. К тому же, если вы добавили новый объект/реквизит, а затем в обновлении поставщик добавил такой же, то это тот случай, когда нужно проанализировать этот объект. Возможно, это и должен быть 1 реквизит, уже типовой. Если вы добавили рекв. Основание, затем поставщик добавил рекв. Основание. В результате вам не нужно 2 реквизита Мой_Основание и Основание. Вам нужен именно 1, с объединёнными типами.
Ну и, конечно, большинство изменения типовых объектов нужно добавлять в автотесты. Например, добавили/удалили типы в определяемом типе — добавили в проверку. При обновлении такие объекты можно смело обновлять, а после — прогнать тесты и они покажут всё, что нужно куда добавить/удалить.
После перехода на такие правила обновление сильно доработанной КА2 у меня вместо нескольких дней стало занимать полдня.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|