Ситуация - разработчик внедряет 1с Консолидацию, соответственно меняет типовою конфу у баз 1с-Бухгалтерий.
В будущем поддерживать систему будет штатный 1с.
Есть какие-либо best practices для документирования изменений, внесенных в типовую конфу Бухгалтерии, чтобы проще было, допустим, обновлять.
Думал просить разработчика запонять некую "карту изменений", в которую он бы вносил пометки о допилках типовой конфы, главным образом переписки "родных" модулей.
Может быть, я велосипед изобретаю, а у уважаемых программеров такая формочка уже есть?
Если нет, подскажите, какие поля в такой табличке должны быть, допустим
Объект Изменено Добавлено Пояснение(какую функцию выполняет) Код(нужен ли?)
Что посоветуете? И не подскажите, как надо при хорошем стиле программирования в 1с комментить изменения?
В будущем поддерживать систему будет штатный 1с.
Есть какие-либо best practices для документирования изменений, внесенных в типовую конфу Бухгалтерии, чтобы проще было, допустим, обновлять.
Думал просить разработчика запонять некую "карту изменений", в которую он бы вносил пометки о допилках типовой конфы, главным образом переписки "родных" модулей.
Может быть, я велосипед изобретаю, а у уважаемых программеров такая формочка уже есть?
Если нет, подскажите, какие поля в такой табличке должны быть, допустим
Объект Изменено Добавлено Пояснение(какую функцию выполняет) Код(нужен ли?)
Что посоветуете? И не подскажите, как надо при хорошем стиле программирования в 1с комментить изменения?
По теме из базы знаний
- [ED2] Обмен УПП 1.3, КА 1.1, УТ 10.3 с EnterpriseData (универсальный формат обмена), обработка
- Создание и групповая обработка информационных карт. Розница 2.2
- Платформа интеграции 1С с чат-ботами (Telegram, Viber, WhatsApp, Instagram, Skype, ICQ, Facebook, ВКонтакте, Одноклассники, Яндекс.Алиса, Verbox, Jivochat, Avito)
- Групповое изменение формата картинок с PNG на JPG
- Прокачай список. Как добавить дополнительную информацию в динамический список с помощью расширения!
Найденные решения
Могу сказать из своего опыта: Записывать изменения в отдельный файл нет смысла, т.к. все изменения в конфигурации можно отследить, сравнив основную конфигурацию и конфигурацию поставщика, да и постоянно отслеживать изменеия в файле и конфигурации просто не удобно.
Достаточно в коде все изменения выделять комментариями типа "Доработано начало-----------" и "Доработано конец-----------", можно указывать ФИО программиста, дату изменения и краткое описание функционала, но не обязательно. Таким образом будет проще отслеживать изменения при обновлении и ошибки в измененном коде.
Если были внесены изменения на форме, то в модуле формы в самом начале в комментариях описывать какие элементы были добавлены, удалены или изменены.
В отдельном файле можно описать доработанный функционал в обобщенном виде, например: В документе поступление товаров и услуг добавлена возможность загружать данные в табличную часть из Excel или изменен алгоритм зачета авансов и краткое описание алгоритма.
Так же будет уместно записать в файл изменения в плане счетов, например: Добавлен счет такой-то, служит для учета того-то в таких-то документах.
Для файла c описанием функционала, можно определить следующие поля:
- Функционал: измененные или доработанные алгоритмы в обобщенном виде,
- Объекты: Список объектов, в которых внесены изменения по данному функционалу(необязательно, т.к. грамотный программист и так поймет какие объекты могли быть изменены исходя из функционала + в коде будет все выделенно комментариями),
- Пояснения: подробное описание функционала(при необходимости) или какие-либо вжные замечания.
Отдельно вынести изменения в плане счетов:
- Счет
- Добавлен/Изменен
- Описание счета: субконто, реквизиты, признаки учета и т.п.
- Объекты: список объектов, в которых используется счет(только для добавленных)
Код выносить в файл ненужно, т.к. его можно посмотреть в конфигурации.
Достаточно в коде все изменения выделять комментариями типа "Доработано начало-----------" и "Доработано конец-----------", можно указывать ФИО программиста, дату изменения и краткое описание функционала, но не обязательно. Таким образом будет проще отслеживать изменения при обновлении и ошибки в измененном коде.
Если были внесены изменения на форме, то в модуле формы в самом начале в комментариях описывать какие элементы были добавлены, удалены или изменены.
В отдельном файле можно описать доработанный функционал в обобщенном виде, например: В документе поступление товаров и услуг добавлена возможность загружать данные в табличную часть из Excel или изменен алгоритм зачета авансов и краткое описание алгоритма.
Так же будет уместно записать в файл изменения в плане счетов, например: Добавлен счет такой-то, служит для учета того-то в таких-то документах.
Для файла c описанием функционала, можно определить следующие поля:
- Функционал: измененные или доработанные алгоритмы в обобщенном виде,
- Объекты: Список объектов, в которых внесены изменения по данному функционалу(необязательно, т.к. грамотный программист и так поймет какие объекты могли быть изменены исходя из функционала + в коде будет все выделенно комментариями),
- Пояснения: подробное описание функционала(при необходимости) или какие-либо вжные замечания.
Отдельно вынести изменения в плане счетов:
- Счет
- Добавлен/Изменен
- Описание счета: субконто, реквизиты, признаки учета и т.п.
- Объекты: список объектов, в которых используется счет(только для добавленных)
Код выносить в файл ненужно, т.к. его можно посмотреть в конфигурации.
Этого вполне хватит.
А поповоду обновления: был у меня период, когда приходилось обновлять много доработанных баз, и все доработки были вынесены в файл. Я лично запарился постоянно переключаться с файла на конфигурацию, чтобы отследить доработанный код, в итоге от файла просто отказался и все занес в конфигурацию в ввиде комментариев. Но тут дело лично каждого - кому как...
Опять же тут нужно учитывать, что у вас всегда под рукой измененная конфигурация(основная) и конфигурация поставщика(в первоначальном виде). В любой момент их сравнив, будет видно что и где доработано. Проблема только с формами, при сравнении сложно понять, что изменено, поэтому я и предлагаю изменения формы выносить в тело модуля в комметариях - тогда все будет прозрачно и понятно.
При обновлении, чтобы отследить изменения, не используя файл достаточно в фильтре установить "Показывать дважды измененные объекты". Данная возможность вообще сводит на нет пользу выноса изменений в файл.
В файле достаточно хранить описание функционала, чтобы понимать для чего он нужен и как работат, в случае если придется что-то менять, например при том же обновлении могут поменяться типовые алгоритмы, которые используются в доработках. Тогда придется внести изменения и в сами доработки, чтобы все работало так как должно, а для этого неплохо было бы знать как оно вообще изначально задумывалось...
А поповоду обновления: был у меня период, когда приходилось обновлять много доработанных баз, и все доработки были вынесены в файл. Я лично запарился постоянно переключаться с файла на конфигурацию, чтобы отследить доработанный код, в итоге от файла просто отказался и все занес в конфигурацию в ввиде комментариев. Но тут дело лично каждого - кому как...
Опять же тут нужно учитывать, что у вас всегда под рукой измененная конфигурация(основная) и конфигурация поставщика(в первоначальном виде). В любой момент их сравнив, будет видно что и где доработано. Проблема только с формами, при сравнении сложно понять, что изменено, поэтому я и предлагаю изменения формы выносить в тело модуля в комметариях - тогда все будет прозрачно и понятно.
При обновлении, чтобы отследить изменения, не используя файл достаточно в фильтре установить "Показывать дважды измененные объекты". Данная возможность вообще сводит на нет пользу выноса изменений в файл.
В файле достаточно хранить описание функционала, чтобы понимать для чего он нужен и как работат, в случае если придется что-то менять, например при том же обновлении могут поменяться типовые алгоритмы, которые используются в доработках. Тогда придется внести изменения и в сами доработки, чтобы все работало так как должно, а для этого неплохо было бы знать как оно вообще изначально задумывалось...
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) bogena, не надо никаких файлов. Во-первых, замучаетесь сравнивать изменения в файле и в конфе. Во-вторых, не дай бог разработчик забудет что-то записать в файл?
Самый лучший вариант - дать разработчику почитать статью Сам держу на поддержке несколько конфигураций БП 2.0 и ЗУП (некоторые конфигурации оооочень сильно изменены - 4-е субконто, исправлены формы многих документов, добавлены свои регистры и т.д.). Но я уже несколько лет следую правилам, подобных тем, что описаны в статье. В результате, очень редко, когда обновление даже самой переписанной конфигурации отнимает у меня больше полутора-двух часов ...
Самый лучший вариант - дать разработчику почитать статью Сам держу на поддержке несколько конфигураций БП 2.0 и ЗУП (некоторые конфигурации оооочень сильно изменены - 4-е субконто, исправлены формы многих документов, добавлены свои регистры и т.д.). Но я уже несколько лет следую правилам, подобных тем, что описаны в статье. В результате, очень редко, когда обновление даже самой переписанной конфигурации отнимает у меня больше полутора-двух часов ...
На основной работе в коде, где делаются изменения, пишем назначение, фамилию и дату. Когда накатываешь обновление видно что обновляешь.
Измененные формы пишем в табличку xls. В общем, всё очень примитивно и мне не нравится.
Ну еще помогает то, что еженедельно рассылается описание изменений конфигурации для пользователей. По ним если что тоже можно будет понять, что менялось.
Когда работаю как фрилансер, постоянно натыкаюсь на полное отсуствие документирования изменений. Соответсвенно и сам не документирую. Порочный круг.
Измененные формы пишем в табличку xls. В общем, всё очень примитивно и мне не нравится.
Ну еще помогает то, что еженедельно рассылается описание изменений конфигурации для пользователей. По ним если что тоже можно будет понять, что менялось.
Когда работаю как фрилансер, постоянно натыкаюсь на полное отсуствие документирования изменений. Соответсвенно и сам не документирую. Порочный круг.
Могу сказать из своего опыта: Записывать изменения в отдельный файл нет смысла, т.к. все изменения в конфигурации можно отследить, сравнив основную конфигурацию и конфигурацию поставщика, да и постоянно отслеживать изменеия в файле и конфигурации просто не удобно.
Достаточно в коде все изменения выделять комментариями типа "Доработано начало-----------" и "Доработано конец-----------", можно указывать ФИО программиста, дату изменения и краткое описание функционала, но не обязательно. Таким образом будет проще отслеживать изменения при обновлении и ошибки в измененном коде.
Если были внесены изменения на форме, то в модуле формы в самом начале в комментариях описывать какие элементы были добавлены, удалены или изменены.
В отдельном файле можно описать доработанный функционал в обобщенном виде, например: В документе поступление товаров и услуг добавлена возможность загружать данные в табличную часть из Excel или изменен алгоритм зачета авансов и краткое описание алгоритма.
Так же будет уместно записать в файл изменения в плане счетов, например: Добавлен счет такой-то, служит для учета того-то в таких-то документах.
Для файла c описанием функционала, можно определить следующие поля:
- Функционал: измененные или доработанные алгоритмы в обобщенном виде,
- Объекты: Список объектов, в которых внесены изменения по данному функционалу(необязательно, т.к. грамотный программист и так поймет какие объекты могли быть изменены исходя из функционала + в коде будет все выделенно комментариями),
- Пояснения: подробное описание функционала(при необходимости) или какие-либо вжные замечания.
Отдельно вынести изменения в плане счетов:
- Счет
- Добавлен/Изменен
- Описание счета: субконто, реквизиты, признаки учета и т.п.
- Объекты: список объектов, в которых используется счет(только для добавленных)
Код выносить в файл ненужно, т.к. его можно посмотреть в конфигурации.
Достаточно в коде все изменения выделять комментариями типа "Доработано начало-----------" и "Доработано конец-----------", можно указывать ФИО программиста, дату изменения и краткое описание функционала, но не обязательно. Таким образом будет проще отслеживать изменения при обновлении и ошибки в измененном коде.
Если были внесены изменения на форме, то в модуле формы в самом начале в комментариях описывать какие элементы были добавлены, удалены или изменены.
В отдельном файле можно описать доработанный функционал в обобщенном виде, например: В документе поступление товаров и услуг добавлена возможность загружать данные в табличную часть из Excel или изменен алгоритм зачета авансов и краткое описание алгоритма.
Так же будет уместно записать в файл изменения в плане счетов, например: Добавлен счет такой-то, служит для учета того-то в таких-то документах.
Для файла c описанием функционала, можно определить следующие поля:
- Функционал: измененные или доработанные алгоритмы в обобщенном виде,
- Объекты: Список объектов, в которых внесены изменения по данному функционалу(необязательно, т.к. грамотный программист и так поймет какие объекты могли быть изменены исходя из функционала + в коде будет все выделенно комментариями),
- Пояснения: подробное описание функционала(при необходимости) или какие-либо вжные замечания.
Отдельно вынести изменения в плане счетов:
- Счет
- Добавлен/Изменен
- Описание счета: субконто, реквизиты, признаки учета и т.п.
- Объекты: список объектов, в которых используется счет(только для добавленных)
Код выносить в файл ненужно, т.к. его можно посмотреть в конфигурации.
(5) m02, Может "постоянно отслеживать изменеия в файле и конфигурации просто не удобно" программеру, который делает проект, а вот человеку, который будет постоянно обновлять, очень даже удобно, ИМХО. Один хрен после первого же обновления он себе список изменений и составит, чтобы каждый раз не анализировать одно и то же.
Ситуация такая - разработчик делает свое дело, а дальше уже просто обновление релизов по мере выхода.
Про вынос кода в табличку с изменениями ясно, я так и предполагал в принципе, тем более разраб. и сейчас в коде делает коммент с датой добавления.
Вы предлагаете сделать следующие поля:
Объект;
пояснение;
функционал;
список связанных объектов?
Этого хватит?
У разработчика много кода, меня волнует только описание того, что "затронуло" "стандартные"типовые объекты типовой конфигурации
Ситуация такая - разработчик делает свое дело, а дальше уже просто обновление релизов по мере выхода.
Про вынос кода в табличку с изменениями ясно, я так и предполагал в принципе, тем более разраб. и сейчас в коде делает коммент с датой добавления.
Вы предлагаете сделать следующие поля:
Объект;
пояснение;
функционал;
список связанных объектов?
Этого хватит?
У разработчика много кода, меня волнует только описание того, что "затронуло" "стандартные"типовые объекты типовой конфигурации
Этого вполне хватит.
А поповоду обновления: был у меня период, когда приходилось обновлять много доработанных баз, и все доработки были вынесены в файл. Я лично запарился постоянно переключаться с файла на конфигурацию, чтобы отследить доработанный код, в итоге от файла просто отказался и все занес в конфигурацию в ввиде комментариев. Но тут дело лично каждого - кому как...
Опять же тут нужно учитывать, что у вас всегда под рукой измененная конфигурация(основная) и конфигурация поставщика(в первоначальном виде). В любой момент их сравнив, будет видно что и где доработано. Проблема только с формами, при сравнении сложно понять, что изменено, поэтому я и предлагаю изменения формы выносить в тело модуля в комметариях - тогда все будет прозрачно и понятно.
При обновлении, чтобы отследить изменения, не используя файл достаточно в фильтре установить "Показывать дважды измененные объекты". Данная возможность вообще сводит на нет пользу выноса изменений в файл.
В файле достаточно хранить описание функционала, чтобы понимать для чего он нужен и как работат, в случае если придется что-то менять, например при том же обновлении могут поменяться типовые алгоритмы, которые используются в доработках. Тогда придется внести изменения и в сами доработки, чтобы все работало так как должно, а для этого неплохо было бы знать как оно вообще изначально задумывалось...
А поповоду обновления: был у меня период, когда приходилось обновлять много доработанных баз, и все доработки были вынесены в файл. Я лично запарился постоянно переключаться с файла на конфигурацию, чтобы отследить доработанный код, в итоге от файла просто отказался и все занес в конфигурацию в ввиде комментариев. Но тут дело лично каждого - кому как...
Опять же тут нужно учитывать, что у вас всегда под рукой измененная конфигурация(основная) и конфигурация поставщика(в первоначальном виде). В любой момент их сравнив, будет видно что и где доработано. Проблема только с формами, при сравнении сложно понять, что изменено, поэтому я и предлагаю изменения формы выносить в тело модуля в комметариях - тогда все будет прозрачно и понятно.
При обновлении, чтобы отследить изменения, не используя файл достаточно в фильтре установить "Показывать дважды измененные объекты". Данная возможность вообще сводит на нет пользу выноса изменений в файл.
В файле достаточно хранить описание функционала, чтобы понимать для чего он нужен и как работат, в случае если придется что-то менять, например при том же обновлении могут поменяться типовые алгоритмы, которые используются в доработках. Тогда придется внести изменения и в сами доработки, чтобы все работало так как должно, а для этого неплохо было бы знать как оно вообще изначально задумывалось...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот