Здравствуйте. Делаю тестовое. Дали демо-базу, которая стоит на поддержке.
Чтобы выполнить задание, нужно доработать логику — есть два пути:
- cнять конфигурацию с поддержки.
- cделать через расширение.

Как считаете, какой вариант лучше выбрать для тестового?

(0) а как ты считаешь?

(1) знал бы, не спрашивал

снять с поддержки

(0) расширение 100%

(2) лучше спросить у ясеня (ну или у того, кто это задание выдал).

(0) Не "снять с поддержки" а "включить возможность изменений".

(6) а потом снять с поддержки

(7) И еще расширение

(8) да, потом можно ещё и расширение. :)

(0) Зависит от принимающего. Я бы за снятие с поддержки, когда есть возможность сделать расширение, выдал бы пня) Но есть и другое мнение)

Радуют меня одноклеточные, которым вообще насрать на то, что за задание, у них вот независимо ни от чего, расширение — это либо хорошо либо плохо
И плевать, что все зависит от кучи вещей

Всем спасибо за ответы.
(11) зависит от каких вещей?

(12) Если надо добавить новые реквизиты - то лучше снять с поддержки.Если изменить логику решения - то лучше использовать расширение.

(12) От многих

Можно ли и нужно ли делать в расширении документ, если требуется полностью интегрировать его во все штатные мульки?
Ну типа там отчет о движениях, структура подчиненности, участие в разных определяемых типах, печатные формы и пр.

Можно ли и нужно ли делать в расширении план видов характеристик?
Пусть у объекта пяток реквизитов примитивного типа

Можно ли и нужно ли делать в расширении регистр сведений, у которого тип одного из измерений "Любая ссылка"?
А если не любая ссылка, а просто сотня объектов ссылочного типа?

Можно ли и нужно ли делать в расширении регистр бухгалтерии?
Предположим, у него все примерно так, как у "Хозрасчетный", то есть несколько субконто, свой план счетов

Можно ли и нужно ли делать в расширении изменении пары строк в процедуре общего модуля на тысячу строк?

Можно ли и нужно ли делать в расширении свою роль, примерно по объему похожую на "Полные права"?

Можно ли и нужно ли делать в расширении документ "Наш новый документ, по важности и используемости примерно как поступление товаров и услуг, реализация товаров и услуг, поступление на расчетный счет или списание с расчетного счета"

Продолжать?

+(14) Как только кто-нибудь потными ладошками настучит яростный ответ "На все вопросы ответ НЕТ, не нужно делать все это в расширении", пусть сразу же ответит на пару следующих вопросов:
— А если у заказчика используется гит для ведения списка доработок?
— А если у клиента уже широко используется практика использования расширений и чье-то безапелляционное НЕТ не воспринимается в качестве бесспорного аргумента для срочного перевода всех доработок с расширений в конфигурацию?

(13) Щас модно и реквизиты в расширения создавать, и даже целые регистры.

(14) Можно ли и нужно ли делать в расширении документ, если требуется полностью интегрировать его во все штатные мульки?

Можно. Я раз делал, но больше как-то не хочу.

(17) Серьезно?
И прям везде все получилось, нигде не обломался в процессе?
Структура подчиненности там, приложенные файлы, история изменений, планы обмена и пр.
Или ты так, сделал у документа кнопочку движений и печатную форму прикрутил и умаялся?

А вариант сделать свою демобазу с нуля не рассматривался?

(19) Дерзко. Нагло. Открыто. Они этого не ждут, поэтому дело выгорит.

(15) Ром, ты перебираешь. Это всего лишь тестовое задание. Полагаю на джуна/мидла. И правильно было бы, как выше заметил Fragster, спросить у "ясеня"

(21)+ и получить от него мой вопрос из (1)

(18) Ага. Почти все прикрутил, кроме история изменений и плана обмена. И все это чисто кодом. Но больше фиг я таким гемором заниматься буду.

(21) Если джун, то согласен, что от него ждать, тут интереснее наблюдать за его рассуждениями
Если мидл, то не согласен, тут человек уже все-таки должен шурупить, хотя бы немного, что такое хорошо, а что такое плохо
А вообще, спросить у "ясеня" это конечно прикольно, но вообще ничего не заменит самостоятельного ковыряния в конфигураторе, тут и в голове заодно откладываются веселые вещи, ну типа, что можно добавить ПВХ, но нельзя добавлять реквизиты, например

(22) А вот тут ты, конечно, обломал чувака
Ему задали такой вопрос, он пришел на форум, а ты ему такой же вопрос задаешь :))

(23) Там точно были засады
Я могу ошибаться, но, вроде тип у ПВХ ты так не изменишь в расширении, чтобы добавить туда свой документ
С определяемыми типами значений вроде так не прокатит, типа Объекты приложенных файлов
С критериями отбора вроде засада была
И тут вообще речь не про код, если что
И таких засад в расширениях вагон, так что нужно смотреть в оба и все проверять, причем проверять на будущее, исходя из планов, а не только на сейчас

(26) Да, засад было много. Я где-то месяц убил, периодическими набегами. Но мне было тупо интересно осилю или нет. Но реально оно нафиг такое не надо. Не окупится.

Вообще, если честно, не понимаю, когда человеку дали задание, он не знает, как его решать, но пытается объегорить проверяющего
Тут можно либо сразу сказать, что не знаешь, но сейчас чуть погуглишь, поковыряешься в конфигураторе, выберешь вариант и попробуешь аргументированно защитить свое решение
Либо просто быстро погуглить, что такое расширение и когда его стоит применять, а когда нет, а дальше доказывать свою точку зрения
А задавать такой вопрос коллективному разуму, чтобы за тебя выдали экспертное мнение — это вот вообще непонятно, зачем?
Тебе же все-равно пару вопросов зададут и ты посыпешься, как листва осенью
Только будет видно, что ты пытался изобразить из себя что-то, чем ты вообще даже рядом не являешься

Помню, ко мне как-то пришел вместе с другом чувак устраиваться на 90 тысяч (это была в то время нихреновая такая сумма)
Вилка у меня была 70 — 90
Я его спросил, на сколько он рассчитывает, он с какой-то странной такой уверенной ухмылкой сказал, что вот у меня 90 написано, его в принципе устраивает
Я его прособеседовал и сказал, что он не подходит
И тут у человека началась суровая реальность
Сначала он спросил, что может не 90, а 80
Я сказал, что нет и не 80
Может 70, говорит
Я говорю, нет, и не 70 и не 60 и даже бесплатно нет, потому что уровень вообще никакой, а учить его у меня желания нет
Ухмылка куда-то пропала, он как-то аж прям осунулся и пошел с другом своим
Это к тому, что не надо пытаться на дурку наебать работодателя
Пытаться устроиться, ничего не зная, говоря, что ты все знаешь, скорее всего ничем хорошим не закончится
Можно чуть приукрасить свои знания
Можно где-то чуть слукавить или умолчать
Но не нужно рассказывать, что ты даже не синьор, а уже гуру, если ты в конфигураторе всего месяц

(27) В том-то и дело, что ряд вещей не решается даже сегодня в принципе
Мы в свое время сделали такой вариант на проекте
Включаем возможность изменения, мизерная доработка типовой, просто вот тупо добавляем документ, по минимуму всякие изменения галочек, которые нельзя вынести в расширение, все остальное с этим документом в расширении, включая реквизиты

https://infostart.ru/1c/articles/2269280/

(0) так сделай два варианта...мол могу и так, и так))

ИИ используй для решения своей задачи. В отличии от мисты даст вменяемый ответ и не будет ругать.

Тот кто будет проверять он смотреть не будет как ты сделал через расширение или в основной конфигурации.

(26) с версии 8.3.20 можно расширять определяемые типы и тип пвх

(32) му-ха-ха!

(34) Ну вот попробуйте добавить реквизит в "Статьи расходов" в ERP, не получится.

(36) * через расширение.

Расширение хорошо, когда там можно решить вопрос чисто кодом. Когда начинается, затаскивание и правка форм, создание метаданных, то начинается треш и угар. Плюс рандомные непредсказуемые глюки.

(28) Уверен, что чувак быстро нашел данную зп у работодателя не мозгоклюя)

(39) Ой, даже не сомневаюсь
Я когда со штатными сотрудниками клиентов общаюсь, там порой такие нули попадаются, что этот-то уж точно нашел
Пяток контор обошел, кто-нибудь на 60 взял, извинялся еще небось, что так мало, а тот рожу кривил, что так и быть, просто вы уж сильно мне понравились, снизойду до вас

Если кто-то не умеет готовить расширения, разве это проблемы технологии расширений?

(41) Вы так говорите, как будто у технологии расширений совсем нет проблем...

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

Странный спор

Если задача тестовая - ответ в (5)
Если есть ТА - аналогично
Если ты сам по сути ТА - вероятно у тебя уже есть знания как правильно лучше делать в конкретном случае

Иногда лучше не использовать расширения
Например если легаси и не будет типовых обновлений

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

Иногда приходится использовать сочетание снятия с замка (новые реквизиты и новые метаданные) + расширения (код, программное изменение типовых форм)

(0) За снятие с поддержки во франчах всегда били по рукам. Максимум, что разрешено делать, — это включать возможность изменения.

(45) У него ж не типовая

(46) >> У него ж не типовая

Типовая, нетиповая... В (0) сказано "которая стоит на поддержке".

(45) Да понятно, что под снятием с поддержки в 99% случаев понимают именно только включение возможности изменения, без снятия с поддержки.

Демо-база которая стоит на поддержке в 99% случаев типовая. Я очень редко видел нетиповые на поддержке.

(0) Задание тестовое. Ваше решение снять с поддержки, выполнить в расширении. Будет тоже оценено, если конечно оценщик оценивает методы решений, а не только сам код...

Тут не угадать... :)
Каждый такой момент у тебя будет содержать дольку удачи.
- Удача, у проверяющего не болит голова.
- Удача, у проверяющего не пришлось выслушивать от руководства, как он плох во всём...

(49) Я могу создать конфу с нуля и сделать файл поставки, которую загрузить в демо-базу. Она окажется на поддержке.

А так то (44) прав. Странный спор.
Дилемма ложная.
К тому же у любого выбора всегда есть свои плюсы и минусы. И даже не как преимущества и недостатки, а как особенности и ограничения.

Вон в (30) ссылка на неплохую статью о примере практического применения расширений. Хотя (на мой вкус) и очень неполная и содержащая множество спорных и/или неоднозначных утверждений. Но ценна она именно практическим опытом в весьма специфических условиях - а конкретно неадекватный заёб заскок в голове заказчика. А надо понимать, что специфика бывает в числе прочего и неадекватной.

Задача исполнителя в любом случае состоит в том, чтобы сделать выбор, осознавая все его последствия, и обосновать заказчику. Вот в статье из (30) обосновать заказчику не сумели.

Задание в студию (0)

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

(54) А в чём разница между тестовой задачей и реальной?...

Предположим ситуацию.
Мы хотим протестировать знания кандидата.
У нас вероятно есть определенные требования к набору и уровню этих знаний - чем конкретно и насколько глубоко должен владеть кандидат.
Если я хочу проверить умеет ли кандидат дорабатывать конфигурации с использованием расширений, то я в задании прямо укажу - что следует выполнять задание только в расширении.
Возможность выбора в задании имеет смысл предоставлять только в двух случаях: либо нам всё равно (мы в таких задачах прямо писали что-то типа "отчёт/обработку можно сделать как внешними, так и в расширении (на выбор)"), либо мы хотим оценить умение кандидата сделать правильный выбор. В последнем случае мы в задаче так и пишем - "выберите способ решения - в конфигурации или в расширении, и обоснуйте его."

Иными словами - спрашивать надо прямо именно о том о чём хотим узнать. А вот нахрена усложнять нелепыми загадками на ровном месте? Чтобы что?... Задачка с подвохом?... А зачем? ... Чтобы кандидат в стрессовой ситуации налепил кучу ошибок, которые он в обычной рабочей обстановке никогда бы не сделал?

>> в 2025 году приоритетно через расширения делать пока это возможно

ИМХО, это вообще бред.
Расширения имеют весьма ограниченную область применения.
Пытаться ими решать все задачи - тупиковый путь. Для конфигураций с более или менее значительным количеством доработок спустя некоторое время это приводит к серьёзным проблемам и ошибкам.

PS: "Дьявол кроется в деталях"(с)

(55) отличие простое - ограниченные сроки и отсутствие жизненного цикла.
Те вещи которыми вы тут в требе упарываетесь в рамках тестового задания значения не имеют.
Задача тестового показать способности.
Если ты часовую условно задачу со всеми раздумиями будешь делать неделю то пролет.

(57) А ты че, постановщик? Может ему месяц дали?

Давайте не гадать за бота. Вот вы станете ботом и вам какую-то хуйню загадают. Что вы будете делать?

(57) >> Если ты часовую задачу будешь делать неделю то пролет.

И при чём тут расширения?...

>> Задача тестового показать способности.

ВООООТ ИМЕННО!!!

И если мне надо знать способность кандидата уметь выбирать между расширением и доработкой внутри самой конфы, то я так и спрошу его об этом. И буду наблюдать за его рассуждениями, обоснованиями своего выбора.
Если меня эта способность не интересует, а важно, например, насколько хорошо он умеет делать доработки через расширения, то я напрямую укажу - делай в расширении.

>> отличие простое - ограниченные сроки и отсутствие жизненного цикла.

Ограниченные сроки есть всегда.
Вряд ли у Вас заказчик, направляя ТЗ, сообщает, что готов подождать вечность. И сами Вы вряд ли станете делать месяц доработку, которую в норме можно сделать за пару дней.
Что касается жизненного цикла, то продуктивных разработок с нулевым или минимальным жизненным циклом огромное количество. Классический пример - разного рода одноразовые обработки загрузок-выгрузок данных в проектах по переходу с одной конфигурации (программы) на другую. Сделали, протестировали, один раз запустили в проде, забыли и выкинули.

(36)(37) я писал про расширение Типа пвх. а для статьи расходов в ерп есть доп реквизиты.