Не могу найти никаких статей по поводу. Хотелось бы почитать как дописывать типовую конфигурацию, чтоб потом не было проблем с обновлениями.

Расширения

https://wonderland.v8.1c.ru/search/index.php?tags=расширения

(1) (2) Спасибо, почитаю.

обработки

(0) для начала понять -- нужна дописка или нет
частенько дописывают то, что уже есть в типовых решениях => занимаются ненужной работой

(0) по возможности использовать модули с суффиксом Переопределяемый

обработки, подписки, расширения, свои отдельные объекты метаданных

(8) что насчет ролей и форм порекомендуете?

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

(10) формы - больная места. Однозначного решения тут не посоветуешь, кроме - пока есть хоть какая-то возможность, код и элементы управления типовой формы менять нельзя. А вот, когда возможности исчерпаны, тогда - либо править типовое, либо копипасте и свое. Тут - только по месту решать.

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

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

если нужны новые реквизиты в типовых объектах, в первую очередь стоит обдумать вариант использования общих реквизитов и регистров сведений. Для редактирования в этом случае можно добавить общую команду с параметром, каковая команда будет открывать форму редактирования этих своих реквизитов. Немного громоздко, но зато экологично.

(10) http://catalog.mista.ru/public/236363/

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

Попробую сформулировать по памяти основные моменты:
1. Основные положения
    1.1 Если это можно сделать подпиской, расширением, обработкой заполнения, общей командой, то это должно быть так сделано.
    1.2 Если нельзя 1.1, то любые изменения типовых метаданных в обязательном порядке должны быть полностью и строго задокументированы в принятой в компании форме (если формы нет, ее надо принять). Комментарии в коде - хорошо, но это не все.
2. Метаданные
    2.1 Новые объекты метаданных создавать можно. Нужен префикс или нет - вопрос котрытый, но считаю, что префиксы - это очень плохо, т.к. они усирают читабельность просто в хлам. Разумно свои объекты совать в какую-то свою же служебную подсистему, чтобы потом можно было их легко отобрать.
    2.2 Типовые атрибуты (измерения,реквизиты и т.д. в том числе имена объектов метаданных) изменять запрещено. Насовсем. Вообще.
    2.3 Роли. Типовые менять запрещено.
        2.3.1 Если надо дополнить типовую роль - создавай свою с именем "<ТиповоеИмя><Суффикс>", где суффикс - это слово или два, однозначно идентифицирующие характер дополнения. Соответственно, при начале работы системы проверяешь всех пользователей, у которых есть типовая роль, на предмет наличия еще и твоей. Нет твоей - отказ=истина, профиль настроен не корректно.
        2.3.2 Если надо сузить разрешения - просто создаешь свою роль с правильными разрешениями. При начале работы системы проверяешь, что у пользователя НЕТ типовой роли, права которой ты сузил.
3. Код
    3.1 Если надо изменить поведение типового метода (процедуры или функции), то механика такая:
        3.1.1 Создаем общий модуль "БЛАБЛАБЛАПереопределяемый" с идентичным набором галок, если его еще нет
        3.1.2 В самой первой строке типового метода втыкаем вызов БЛАБЛАБЛАПереопределяемый.ИмяТиповогоМетода(все параметры типового метода без исключения)
            3.1.2.1 Если это функция, то Возврат БЛАБЛАБЛАПереопределяемый.ИмяТиповогоМетода()
            3.1.2.2 Если это процедура, то БЛАБЛАБЛАПереопределяемый.ИмяТиповогоМетода(); Возврат;
            Чтобы типовой код не выполнялся ни когда.
        3.1.3 Код БЛАБЛАБЛАПереопределяемый.ИмяТиповогоМетода() копипастим из типового и меняем, как хотим
    3.2 Изменения в не общих модулях - по той же схеме со следующей оговоркой
    3.3 Если нецелесообразно городить общий модуль, то можно свой метод сложить прямо в редактируемые типовой, но строго в конец модуля. Можно даже объединить всой код в #Секцию, но это не обязательно. Однако следует помнить, что складывать свой код в типовые модули - это плохая затея почи всегда.

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

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

(16) мне любопытно, будет ли в свете https://wonderland.v8.1c.ru/blog/rasshirenie-moduley пересмотрен запрет на изменение конфигурации в вашей организации?

(19) я больше не работаю там. Может и будет.

(20) а про изменение типов реквизитов ничего нет(

(21) Типовые. Реквизиты. Не. Меняются. Вообще.
Кроме случаев, когда без этого ни как. Про случаи написал отдельно.