И пятый пункт: при возможности делаем это в расширении ;)

@yellow_club

2 жыл бұрын

Артем против расширений)

@Taktic1C

2 жыл бұрын

@@yellow_club Что-то религиозное или есть разумное оправдание отказа от расширений? У нас такое правило - новые реквизиты в основной конфигурации, все что не касается хранения данных выполняется при помощи расширения.

@yellow_club

2 жыл бұрын

Тут лучше у Артема спросить) может прочитает это обсуждение

@user-jy8ux2ml2x

2 жыл бұрын

@@Taktic1C это более правильный подход исходя из опыта. Недавно из-за расширения (были добавлены реквизиты в документ) потеряли данные расширений и самих документ. Ошибка SDBL в один прекрасный момент.

@EvilBloodEye

2 жыл бұрын

@@Taktic1C расширения усложняют процедуру обновления. Вместо того, чтобы проконтролировать корректность основной конфгируации, протестировать ее и как есть залить на прод приходится при обновлении редактировать 2 сущности, при тестировании и обновлении контролировать корректность версий. При этом полностью изолировать друг от друга их практически нельзя. Безусловно есть задачи, где расширения хорошо себя показывают. Как минимум это единственная возможность дорабатывать приложения, работающие в модели сервиса или универсальные тиражируемые решения для установки поверх клиентами, без снятия с поддержки. Но при прочих равных для конкретного клиента на мой взгляд безопаснее пилить конфигурацию, нежели делать поверх расширение.

Я это уже писал под полным роликом, напишу еще раз. Копировать дубли объектов поставщика, это что такое, это что за совет такой?? Я один раз видел умельца, который бспшный модуль общего назначения вот так скопировал себе «рядом» и стал его вызывать везде в своих доработках, а потом спустя пару лет ВНЕЗАПНО половина вызываемого программного интерфейса развалилась из-за кривых вызовов типовых модулей из этой не обновляемой годами копии. Это вы вот так советуете дорабатывать? Дорабатывать типовое нужно всегда, если вам нужно изменить типовой функционал. Что здесь может быть не очевидно, не пойму. Можно создать рядом с типовым макетом mxl свой макет, но не чтобы вызывать его вместо целиком, а с какой то небольшой вставляемой областью на пример.

@Taktic1C

2 жыл бұрын

Плюсую! Совет делать дубли объектов крайне сомнителен.

@dmitrysim5920

2 жыл бұрын

У каждого подхода есть как свои плюсы, так и минусы, нет идеальных решений, каждый вырабатывает для себя подходы для достижения необходимого баланса. Не ищите золотой таблетки, ее нет.

@LosashExote

2 жыл бұрын

@@dmitrysim5920 "золотой таблетки" нет, а единственно правильные решения в специфических ситуациях - есть. Создание дублей типовых объектов и использование их "вместо" рано или поздно угробит кодовую базу, база потеряет возможность корректно обновиться.

@dmitrysim5920

2 жыл бұрын

@@LosashExote и согласен и нет. Согласен что в каждом случае есть свой правильный вариант, не согласен что дублирование в принципе нужно исключать и что это зло. Злом станет когда будете переходить на кардинально другой релиз, например, с 2.5.6 на 2.5.7, или с 2.4 на 2.5. Но там при использовании любого подхода нужно перепроектировать часть решений, нельзя доработать так (при любом подходе), чтобы система выдержала любое обновление.

@dmitrysim5920

2 жыл бұрын

@@LosashExote и копирование общего модуля, кажется что это просто апогей подобного случая, думаю автор имел в виду копировать документы, при необходимости кастомизации.

Интересный кейс: случилось как то добавить реквизит в ТЧ "данныеОВремени" табеля (ЗУП, erp, и тд), программно его на форму не добавить, ибо у самой ТЧ снято в типовой "использовать всегда", любимый вендор распотранил это свойство на чилдренят, вне зависимости от того что у них у самих указано, может есть какие соображения?

А почему сюда или в описание не положили ссылку на github из видео ?

Не согласен, с четвертым пунктом, я даже свой код комментирую, так как я ума неприложу для чего и кому это было год назад нужно, потом выйдет Петя из отпуска и скажет, кто отменил мою доработку и почему, поднимать историю инцидентов, читать архив почты, нах... А так всё в коде видно и понятно, что Миша попросил отменить её пару недель назад и почему, комментируем функционал Миши, разкомментируем функционал Пети 😅 профит

Видимо Вася, который дорабатывает за Ваней, настолько в себе уверен, что в случае проблем с его доработкой через пару недель точно вспомнит, что же он там делал и где всё это искать.

@LosashExote

2 жыл бұрын

Не совсем понятно, что вы пытаетесь сказать. Нормальные разработчики дорабатывают всегда по одному и тому же принципу, и вкупе с умением пользоваться отладкой легко находят/вспоминают где и что было сделано. Беда бывает только если на компании у разных программистов разный подход к доработке и разные стандарты в голове. Мы это лично присекли давно. Все должны работать единообразно.

@Anton-ni8un

2 жыл бұрын

@@LosashExote, вместо того, чтобы найти нужные участки кода по комментарию, в котором указан номер задачи, мы будем искать с использованием отладки. Пусть программист бесплатно поработает еще за те же деньги, или заказчик пусть это ещё раз оплатит. Только потому, что кому-то взбрело в голову запретить комментировать...

@Taktic1C

2 жыл бұрын

@@LosashExote Полагаю что это к тому, что любое изменение кода должно комментироваться, даже если это доработка уже ранее доработанного кода.

@LosashExote

2 жыл бұрын

@@Taktic1C а, понял. Это докладчик из видео говорил, не комментировать, да, я тоже не согласен с этим подходом. Стандартизированный комментарий считаю что необходимо оставлять даже в нетиповом коде другого разработчика.

@EvilBloodEye

2 жыл бұрын

@@LosashExote если вы работаете с гитом, то за несколько секунд сможете посмотреть историю жизни со всеми комментариями к коммитам любой строчки. С такой возможностью лишние комментарии в коде только визуальный мусор создают.