Как стать автором
Обновить

Комментарии 6

Интересно, автор когда-нибудь работал с настоящим архитектором 1С?

На всех языках разработки все стремятся обобщать код, делать абстракции, убирать "копи-пасту" как источник ошибок. Вы же предлагаете все делать наоборот.

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

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

Очень часто «дороботчику» об этом забыват сказать. И он («дороботчик») достает молоток и воздь сотку, вбивая его прям по живому!

Сам страдает! Но не видит другого, потому что он кто?! Правильно разработчик ставший «дороботчиком» и он не видит все это красоты. Ему гвозь забить и бежать дальше.

Есть конечно уперты, что докопаются и увидят всю красоту архитектурного решения!

К чему это я?! Да к тому что архитектуру нужно документировать и нести в массы. С примерами кода, самогоном и куртизанками!

P.S. ИМХО

Полностью согласен с тем, что хочется иметь документацию к тому как же оно работает и как лучше встраивать свои доработки.

И хотелось бы, чтобы при разработке типовых учитывалась легкость доработки расширениями. Иногда приходится забирать в расширение большую функцию, чтобы поменять одно условие

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

А если мне нужно поправить какое-то движение во всех документах сразу, то могу в общем модуле проведения это исправить.

Вообще способ проведения через механизмы довольно замороченный для понимания, но позволяет некоторые доработки сделать проще. Можно добавить вызов своей функции, а уже в ней прописать какую-то доп.обработку таблиц перед записью не влезая в остальной типовой функционал. И упрощая себе последующее обновление.

При этом вообще к типовым конфигурациям 1с много претензий. Переименовывание функций, общих модулей. Постоянное изменение логики работы с остатками в пути. Удаление регистров и добавление новых. Но вот механизм проведения реально понравился в 11.5

И часто доработку делают в виде расширения. А потом вжик - и при обновлении поменяли имена/сигнатуры методов

Зарегистрируйтесь на Хабре, чтобы оставить комментарий