Краткое руководство по внесению изменений в конфигурацию
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Ничего не понял, но очень интересно.
Лайк, первый буду
может молодешь так будет писать, я как то по старике. Написал дату автор и досвидос, все кто не умеет писать код идите учитесь
Лайк, первый буду
// + [Компания], [Программист] [Дата изменений]
// Задача: [Номер тех.задания или заявки], [Краткое описание изменений]
// Было:
// [закомментированный старый код]
// Стало:
[новый код]
// - [Компания], [Программист] [Дата изменений]
Например:
// + 1С, Иванов И.И. 07.01.2020
// Задача: Ф-037, Заполнение реквизитов формы по новому алгоритму
// Было:
// ПриЧтенииСозданииНаСервере();
// Стало:
ВАШПРЕФИКС_ПриЧтенииСозданииНаСервере();
// - 1С, Иванов И.И. 07.01.2020
Показать// Задача: [Номер тех.задания или заявки], [Краткое описание изменений]
// Было:
// [закомментированный старый код]
// Стало:
[новый код]
// - [Компания], [Программист] [Дата изменений]
Например:
// + 1С, Иванов И.И. 07.01.2020
// Задача: Ф-037, Заполнение реквизитов формы по новому алгоритму
// Было:
// ПриЧтенииСозданииНаСервере();
// Стало:
ВАШПРЕФИКС_ПриЧтенииСозданииНаСервере();
// - 1С, Иванов И.И. 07.01.2020
может молодешь так будет писать, я как то по старике. Написал дату автор и досвидос, все кто не умеет писать код идите учитесь
(30) Да и Окружающая Среда постоянно меняется. Вот Зиму долго ждали... Снег выпал в Новогодние праздники и растаял...
А если серьёзнее, то конфигурацию могут править множество доработчиков (некоторые уволились уже, и не расспросишь). Если не ведется журнал доработок с фиксацией ТЗ, то единственным местом смысла доработки будет комментарий. Поэтому лучше писать смысл исправления кода.
А если серьёзнее, то конфигурацию могут править множество доработчиков (некоторые уволились уже, и не расспросишь). Если не ведется журнал доработок с фиксацией ТЗ, то единственным местом смысла доработки будет комментарий. Поэтому лучше писать смысл исправления кода.
Прочитал, плюсанул. Ну и критика:
Общие требования к написанию кода:
1,2 - Невыполнимо на более-менее нетривиальной задаче
5 - На каком железе и объеме данных? Как это спрогнозировать на этапе разработки?
6 - Это не всегда верно, бизнес-задачи бывают разные.
8 - А если я пишу с нуля?
Работа с хранилищем конфигурации
По моему надо переписать:
Разработка ведется с использованием СКВ, таких как хранилище 1С, git, svn и т.д.
(Ну а дальше подпунктом)
Работа с хранилищем 1С.
Показать1,2 - Невыполнимо на более-менее нетривиальной задаче
5 - На каком железе и объеме данных? Как это спрогнозировать на этапе разработки?
6 - Это не всегда верно, бизнес-задачи бывают разные.
8 - А если я пишу с нуля?
Работа с хранилищем конфигурации
По моему надо переписать:
Разработка ведется с использованием СКВ, таких как хранилище 1С, git, svn и т.д.
(Ну а дальше подпунктом)
Работа с хранилищем 1С.
(9) Можно еще писать всякие приколы:
1. Парнь - если ты нашел до - этой строки - я знал что задача ипически сложная и каюсь, что писал каумнокод.
2. Если ты набрел на эту срочку и нашел тут ошибку.. то ты убер крут. Исправь баги и ты выйдешь на новый уровень матрицы.
3. Или так - медленно работает перепиши - все через запросы!
4. Или так - не нравится мой код - иди в баню!
5. Парень тебе обещали 300 тысяч за этот проект - имей в виду до тебя тут 10 прогеров кинули.
1. Парнь - если ты нашел до - этой строки - я знал что задача ипически сложная и каюсь, что писал каумнокод.
2. Если ты набрел на эту срочку и нашел тут ошибку.. то ты убер крут. Исправь баги и ты выйдешь на новый уровень матрицы.
3. Или так - медленно работает перепиши - все через запросы!
4. Или так - не нравится мой код - иди в баню!
5. Парень тебе обещали 300 тысяч за этот проект - имей в виду до тебя тут 10 прогеров кинули.
Вспоминается...
Самый бесполезный лайфхак - ставить крестик на руке, чтобы не забыть! БЛИН!!! НЕ ЗАБЫТЬ ЧТО?!
Я бы еще добавил пункт - периодическая ревизия доработок.
И внесение в комментарий поля - это новый функционал или исправление ошибок
Если часто меняются главбухи - то через пол-года можно смело все зачищать и если никто не вспомнит - так и оставить
Самый бесполезный лайфхак - ставить крестик на руке, чтобы не забыть! БЛИН!!! НЕ ЗАБЫТЬ ЧТО?!
Я бы еще добавил пункт - периодическая ревизия доработок.
И внесение в комментарий поля - это новый функционал или исправление ошибок
Если часто меняются главбухи - то через пол-года можно смело все зачищать и если никто не вспомнит - так и оставить
Комментарии старого когда это зло, Если конфигурация разрабатывается с нуля то репозиторий Вам в помощь для того, чтобы понять кто что изменил/добавил. Программный код должен быть самодокументированным. Комментириев вообще должно быть минимум, и главное они должны быть только в самых не очевидных местах. Представьте что Вы раскомментируете программный код по прошествии например года, а некоторых объектов то уже и нет в конфигурации.
Не нужно комментировать изменение, если код не типовой. Комментарий должны быть только для изменений относительно типового кода. При изменении ранее измененного куска кода необходимо изменить только дату изменения в комментарии - разделяю (любое изменение кода обязательно должно быть прокомментировано), предлагаю аргументировать Вашу позицию
Любые изменения конфигурации должны быть максимально реализованы с помощью Расширений конфигураций
Как много возникает различных расширений в рамках одного проекта?
Какими правилами руководствуетесь при принятии решения о доработке существующего расширения или создании нового? Легко искать доработки, если расширений много?
(20) (направление я уловил) Я не против и просто конфигурацию менять, там можно тоже всё аккуратненько делать, сохраняя обновляемость. Можно и так и ч/з расширения. Например, в ЕРП пока нельзя делать регистры накопления в расширении и с некоторыми типами объектов, есть проблемы доработки в связи с не включенной пока совместимость с 8.3.13. Её вроде в ЕРП хотят в 2020 году в ЕРП включить. Поэтому расширения в ЕРП ещё не совсем взлетают.
(21) у меня кстати были проблемы с реквизитами в расширении. Была такая проблема с журналом банковские выписки в бухглтерии и с поступлением безналичных денежных средств. Реквизиты сначала были в расширении, но потом для исправления нужно было ТИИ делать при отключенном расширении, в результате пришлось дублировать реквизит в конфигурацию, делать обработку по переносу данных. Понял что в расширении я пока только визуально-интерфейсную часть оставлю и не более.
(22)
именно поэтому не используем их, так как на этапе обновления не известно сломаются ли расширения или нет.
танцию, но при обновлении конфигурации есть очень удобный механизм тройного сравнения, чего нет при реализации доработок с помощью расширений.
именно поэтому не используем их, так как на этапе обновления не известно сломаются ли расширения или нет.
Мне кстати понравилось использовать не префикс, а постфикс, на крайняк начинать название с подчеркивания. Тогда с сортировкой попроще. С постфиксом делали в Почте России на проекте.
(32) Переопределяете в ПриСозданииНаСервере() текст запроса динамического списка Список.ТекстЗапроса = "...новый ваш текст запроса..." или если нужно изменить кусочек запроса Список.ТекстЗапроса = СтрЗаменить(Список.ТекстЗапроса, "ИскомыйТекст", "НовыйТекст").
по поводу изменения ролей в целом согласен, но есть одно НО. Стоит упомянуть, что нужно взвесить изменять типовую роль или создавать новую. Сделайте поиск по конфигурации по ключевому слову РольДоступна(" в ERP и удивитесь, что создав новую роль копирование вам придётся изменять типовую конфигурацию. Самый яркий пример с ролью ЗачетОплаты
п.8 имеет исключение. Если объект не типовой, а добавленный в процессе разработки, то вынесение его изменений в расширения добавит сумятицы. Это итак наш документ, пусть он будет "цельный", описанный одной сущностью.
"Не нужно комментировать изменение, если код не типовой. Комментарий должны быть только для изменений относительно типового кода. При изменении ранее измененного куска кода необходимо изменить только дату изменения в комментарии."
При "изменении ранее измененного" НА СРЕДНЮЮ ПЕРСПЕКТИВУ в комментариях всегда оставляю даты прошлых изменений. Иначе возможна ситуация когда приходят через полгода-год и говорят - вот два года назад так работало, а сейчас совсем не правильно (например документ который с каким-то видом операции проводится раз в два-три года). Если не помнить об предыдущих изменениях либо изменения делались совсем другим человеком, то найти ошибку будет очень трудно - нет информации что два года назад код был иным. Конечно если покопать, то все можно найти, но время и лишние усилия потеряны. У вас есть лишнее время - замечательно. если его нет - все совсем не замечательно.
Следующее замечание относится к ситуациям если изменения не делаются "по серьезному", то есть без "[Номер тех.задания или заявки]". Бывали случаи когда изменения продавливаются вопреки аргументам программиста (вроде мы тебя выслушали, но сделай как мы сказали). Можно потратить массу времени на уговоры и аргументацию, а можно в комментарии написать - указание главбуха Петровой. И случись что - всегда можете сказать "а я предупреждал". Но, хотелось бы предупредить, что такое работает только в более-менее адекватных организациях. В ином случае (юные падованы 1с) пишите служебную записку с своими предупреждениями и аргументами и фиксируйте их в документообороте (это банальное прикрытие своей задницы официальной бумажкой).