roman72

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

И как быть с уже имеющимся в наличии инструментом "Автоматизированная проверка конфигураций", который эту задачу решит гораздо лучше?
Тем более, часть стандартов 1С в них уже зашита.
И технология, которая в АПК заложена пригодна для нового и уже написанного кода.
В АПК фактически аналог шаблона - это пакет проверок.
Каждое утверждение стандарта может быть записано в виде атомарного элемента АПК.
Элементы собираются в пакеты.
Пакеты запускаются для проверки текста кода.
Пакетов много, элементы в пакеты могут собираться в любой комбинации = множество разных проверок.

(6) Знаете, резкость и грубость вашего комментария вас выдаёт.

А что мешает сделать такой вариант - размещать эти гигантские количества строк таблиц в отдельном регистре/хранилище,
а документ связывать с блоком записей через индекс/ключ/имя/ссылку документа?
При открытии документа по ссылке, эти выборки будут вызываться в таблицу /закладку документа (по вызову пользователя) и то лучше по нажатию кнопки пользователем - не при каждом открытии это ему нужно.
Если документ или дальше по бизнес-процессу другой объект 1С обрабатывает эту таблицу, то проводиться может результирующий запрос или множество таких запросов (то есть по сути ОЛАП_кубы).

Приятно читать статьи об организации и наведении порядка

Сослался на вашу статью в нашем чате Телеграм по СППР
https://t.me/SPPR1c/222

Будем признательны, если поделитесь информацией о работе с СППР в контексте вашей статьи и входе обсуждения в чате.

Общий посыл участников чата СППР - инструмент есть, методологии работы с ним нет.
В СППР 1С забыла прикрутить методологию корпоративных внедрений типа «1С:Технологии корпоративного внедрения 2.0» (1С:ТКВ).

А тут вы со статьей и методологией! )

(27) Спасибо

(8) С таблицами непонятно.
Вы список таблиц передаёте в чатЖПТ?
Или в ответ полученный от чатЖПТ вставляете таблицы из вашего списка перед передачей пользователю?

(6) А насчёт кода 1С, который не является запросом? С ним не работаете?


"перевожу его на 1С так, чтобы он стал выполнимым" - вручную? алгоритм какой-то?


И как таблицы 1С (имена) передаёте в чатЖПТ?

Правильно я понимаю, что в вашем тесте вы вопрос на русском языке
- переводите на английский
- передаёте его в чатЖПТ
- получаете конструкцию запроса на английском языке
- переводите эту конструкцию на русский 1сный
- выдаёте в ответ пользователю
-- при этом вы каким-то образом передаёте чатЖПТ списки таблиц регистров 1С (как, если так?)

Насколько я знаю, чатЖПТ обучен в основном на кодах гитхаба и похожих ресурсах, где кода на языке 1С считай нет.
Но там полно кода на SQL.
Поэтому вам, для 1С, чатЖПТ строит ответы на языке SQL вполне приемлемо.
Но что вы собираетесь делать для получения ответов от чатЖПТ по коду 1С, который не является кодом запроса?

Техническое задание - это конечный результат этапа "Техническое проектирование", а не отдельный этап.

Разработка - этап зависящий от качества исполнения этапа "проектирование".
При качественном проектировании разработка и проектирование должны стремится к соотношению 20/80.
20% длины этапа - разработка, а 80% проектирование - такое соотношение признак качества, его уже достаточно.
Если разработка ещё менее 20%, то это ещё более лучший показатель качества.
Чем качественнее проектирование, тем выше скорость работы разработчика. И качество его работы.

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

Все конструкции проектного договора "по ходу дела поймём, выявим, внесём изменения и втиснем в проект" - от лукавого.
Любое отклонение от собранного списка Требований должно иметь следствием изменение срока и/или цены проекта (договора).
Иначе доходность исполнителя от проекта уменьшается. Ожидаемая прибыль не зарабатывается.

Другое дело, что клиент хочет знать цену/срок проекта ещё ранее этапа "Обследование", включая сроки/стоимость самого этапа "Обследование", т.е. уже на этапе пресейла или первого звонка в офис исполнителя.
Здесь могут помочь только методы типа COCOMO, типа как здесь
https://infostart.ru/1c/articles/1176530/