Есть ли рекомендации у 1С к доработке типовой конфигурации?

Тогда про какие договора идет речь?

Про любые: устные, письменные, .... любые, по которым происходит доработка базы. Хотелось бы, чтобы Тот, кто изменяет конфигурацию, придерживался некоторой методики, рекомендаций. Удобнее их не самому писать (это раз), получить их из авторитетного источника (это два) и обговорить с исполнителем одной фразой "разработка идет согласно методике 1С".

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

Я уже приводил выше примеры. См. предыдущие посты.<br>Я хочу видеть официальный документ от 1С по этому вопросу. Документов по этому вопросу в инете много, но все они от франчайзи, посетителей форумов, групп разработчиков и т.д.

хотите видеть официальный документ - делайте запрос в 1С

Уже сделано. Думал, может здесь у кого такая ссылка есть .

> и обговорить с исполнителем одной фразой "разработка идет согласно методике 1С".<br> <br>На ИТС есть раздел "Система стандартов и методик разработки", но там далеко не все моменты учтены. Практически всегда конечная ответственность сводится к "предпочтениям" архитектора системы. Даже типовые конфигурации самой 1С (не говорю уже даже про крупных партнеров типа Рарус или Акселот) бывает сильно разнятся по "стилю" написания кода. Какая-то систематизация задумана посредством перевода разработок на использование БСП, но и тут еще нет 100%-й ясности, т.к. версии БСП так же периодически обновляются. Если Вы конкретно хотите как-то оградить свою программу от всяких "чудиков", которые вносят изменения и после этого конфигурация становится неработоспособной, то тут никакие стандарты не помогут. Единственный выход это только каждый раз самому перепроверять выполненные работы. Если перепроверять работы не представляется возможным, то наверное только рекомендации помогут довериться стороннему разработчику. Наличие сертификата у программиста по платформе (желательно "посвежее", а не 5-ти летней давности) и по прикладному решению, так же могут дать какую-то гарантию, что хотя бы грубых ошибок разработчик не натворит.

Полностью согласен. Но в указанном разделе ни слова про доработку типовых . Что касается "каждый раз проверять самому", это естественно. Считается нормальным принимать и проверять любой товар по количеству и качеству. Есть даже инструкция. ПО почему-то долгое время стояло особняком от этой процедуры.

А чем "типовые" от любых других отличаются? Вопрос же качества кода и выбора архитектуры решения несколько творческое занятие, поэтому и нет точных инструкций. Я имел как-то дело с одним программистом, который все переменные обозначал одной буквой ("А", "Б", "В"...) и так всю жизнь работал. Глядя на этот код его хотелось убить, но ему было так удобно писать программы и в принципе механизмы работоспособные получались. Чистый субъективизм...

Можно я не буду отвечать на эти вопросы ))))))))))).<br> <br>Прим. От 1С ответ такой: прямых рекомендаций нет. Максимум,что может быть на эту тему - рассуждения авторитетных людей в книгах, изданных с участием 1С.