Z
Ну какая разница кто и когда решал задачу. Ты лучше опиши что за задача решалась и зачем.
Size: a a a
2021 May 16
Z
если нужно что и когда - есть хранилище
A
Так я и пишу)) я сейчас про вопрос зачем вообще менять типовые)
Z
менять надо! типовой код менять не надо.
надо встраиваться через события, переопределяемый интерфейс или точечные замены в расширениях, в некоторых случаях копирование модулей с подменой типовых, обычно это модули обмена с другими системами.
надо встраиваться через события, переопределяемый интерфейс или точечные замены в расширениях, в некоторых случаях копирование модулей с подменой типовых, обычно это модули обмена с другими системами.
A
ERP. Подбор серий в документы (обработка) вызывается из многих документов и ее копирование бессмыслено. Необходимо реализовать собственный алгоритм подбора в документы продаж с учётом собственных реквизитов серии. Обработка не вызывает ни одного модуля локализации. Сделана "в лоб" под текущие потребности типовой. Что делать?
JD
Лучше быть богатым и здоровым, чем бедным и больным (с)
NM
Вот после таких историй обновление системы и превращается в лёгкий адок..
HN
Если поведение меняется незначительно, можно б и позаимствовать в расширение форму обработки.. или вопрос с подвохом?
A
Не, никакого подвоха. Просто первое что в голову пришло. Дело было когда расширения только появлялись и тогда уж точно доверия не было
HN
В ут10 перепахивали формы подбора только в путь, по 3 штуки попадались с разными суффиксами, а в типовой при открытии добавлялся вызов нужной не типовой, чтоб сильно не вандалить
HN
По замыслу обновлять все 3 в случае значительных обновлений, зато типовая рядом, чтоб сравнить и вычленить правки
A
Так если правки откоментированны то вот они, рядом. Даже при двустороннем обмене
E
При работе на заказчика комментарии обязательны, ну по крайней мере считаю это хорошим тоном, как и мой работодатель.
В комментарии - номер задачи, фамилия исполнителя, дата и "скобки" начало-конец. Особенно полезно, когда над проектом работает несколько программистов, понятно, кто что делал и чей фрагмент кода затрагивается (типовой или другого программиста).
В комментарии - номер задачи, фамилия исполнителя, дата и "скобки" начало-конец. Особенно полезно, когда над проектом работает несколько программистов, понятно, кто что делал и чей фрагмент кода затрагивается (типовой или другого программиста).
PM
Шаблоны от Чистова.
g
https://t.me/ssl1c/84129
не всегда согласен с революционными методами Никиты, но тут явно вы застряли в прошлом. Жиру и гит сервер сейчас очень легко подружить. Всегда можно понять кто и что и по какой задаче внёс, причём без комментария, даже без конфигуратора
не всегда согласен с революционными методами Никиты, но тут явно вы застряли в прошлом. Жиру и гит сервер сейчас очень легко подружить. Всегда можно понять кто и что и по какой задаче внёс, причём без комментария, даже без конфигуратора
PZ
Тут дело все в заказчике.
Фиг вам оскрип, жира и гит.
Вполне рядовое развитие событий
Фиг вам оскрип, жира и гит.
Вполне рядовое развитие событий
g
Да не, дело в том что вы не можете это продать заказчику) у бита же удаётся и у вас получится
PZ
О да конечно
Z
не, ну можно и в ворде беклог держать
Z
если команда не хочет учиться пользоваться гитблеймом, то ей нужны комментарии.