"Собственные модули" в Axapta

[RVS]

Который раз уж вижу и слышу - "написание СОБСТВЕННОГО модуля в Ax - это мегакруто". К примеру - здесь: Москва - Сильный программист Axapta

Кто бы пояснил - оно действительно так? И чем собственный модуль так уж сильно круче ветки в меню того (существующего) модуля Ax, к которому он, собственный, наиболее тяготеет?

КМК, все эти "собственные" модули (на клиенте, тем более) - скорее зло, чем добро, и идет скорее от непонимания того, что система уже может и того, что надо довернуть, чтобы она еще и местные хотелки перекрыла.

Вооот...

[George Nordic]

Есть плюсы, есть минусы. Конечно, самый класс, это настолько хорошо разбираться в системе, чтобы по-максимуму использовать стандартную функциональность. При этом понимать архитектуру и оценивать влияние доработок на систему вцелом. Но! При этом гораздо усложняется процесс перехода на новые версии системы. Отдельно стоящий блок легче переносить. К тому же, это тянет на "вертикальное решение", которое легче пиарить. Лучше сказать "Мы написали супер-пупер ***", чем сказать "Мы разобрались в стандарном ****, настроили его и заставили работать, а также сделали ряд доработок для повышения удобства использования".

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

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

Типичный взгляд типичного партнера и типичного локализатора. С горизонтом планирования в год-два.

Все что угодно, кроме "как этим люди будут пользоваться". С горизонтом планирования в пять-десять лет.

[Zodiak]

Цитата:

Сообщение от George Nordic

Но! При этом гораздо усложняется процесс перехода на новые версии системы.

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

[mazzy]

Цитата:

Сообщение от Zodiak

которые делают "внутренний API" модулей.

М-м-м... (аж зубы заныли)

Пока ситуация сильно ухудшилась. Прежде всего с переходом на Reporting Service, который диктует прямое обращение к данным и не может нормально обращаться к методам самой Аксапты...

Раньше API были просто недокументированы, а действия в обход API совершались прежде всего в угоду производительности...
Теперь API будут тотально игнорироваться создателями отчетов...

Впрочем, это совершенно отдельная тема.
Извините.

[mazzy]

Цитата:

Сообщение от RVS

"написание СОБСТВЕННОГО модуля в Ax - это мегакруто"

Кто бы пояснил - оно действительно так?

Тут дьявол в деталях.

Согласен: "написание СОБСТВЕННОГО модуля в Ax при условии полной и бесшовной интеграции с существующим функционалом - это мегакруто"

Не согласен: "написание СОБСТВЕННОГО отдельно стоящего модуля в Ax - это мегакруто"

Отдельно стоящий модуль в AX написать легко и беззаботно (даже легче, чем создать конфигурацию с нуля в 1С). Правда пользователи такого модуля не смогут использовать остальной функционал Аксапты. Со всеми вытекающими (как и в 1С). В результате отдельно стоящий модуль в AX превращается в аналог 1С, только существенно дороже.

[RVS]

Цитата:

Сообщение от mazzy

Тут дьявол в деталях.

Точно Поэтому сужу тему:

- речь не о партнере, а о клиенте. Однозначно - о клиенте.
- речь о том, что в определенных кругах, похоже, слова "собственный модуль" - это... ПЯТЬ
- речь о том, что я не понял, чем, собственно, "собственный модуль" так сильно круче, чем просто ветка меню, и просил гуру разъяснить по возможности.

Насколько я понимаю, в лицензию его запихать все равно не получится. А коли так - в чем, собственно, разница?

[ice]

Цитата:

Сообщение от RVS

Точно Поэтому сужу тему:

- речь не о партнере, а о клиенте. Однозначно - о клиенте.
- речь о том, что в определенных кругах, похоже, слова "собственный модуль" - это... ПЯТЬ
- речь о том, что я не понял, чем, собственно, "собственный модуль" так сильно круче, чем просто ветка меню, и просил гуру разъяснить по возможности.

Насколько я понимаю, в лицензию его запихать все равно не получится. А коли так - в чем, собственно, разница?

ИМХО "собственный модуль" для некоторых руководителей является показателем профессионализма и умения работать с нестандартным кодом

[RVS]

Цитата:

Сообщение от ice

ИМХО "собственный модуль" для некоторых руководителей является показателем профессионализма и умения работать с нестандартным годом

Именно... Выше автор поста, на который я ссылался, пояснил, что "собственный модуль", в его понимании - это

Цитата:

Сообщение от Stepa

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

Вот такая вот терминология

Stepa,

Будучи программистом, на вопрос про "собственный модуль" - честно отвечу "нет"; на вопрос про "большой объем... по ТЗ" - "да".

Почувствуйте разницу

[konopello]

Цитата:

При этом гораздо усложняется процесс перехода на новые версии системы. Отдельно стоящий блок легче переносить. К тому же, это тянет на "вертикальное решение", которое легче пиарить. Лучше сказать "Мы написали супер-пупер ***", чем сказать "Мы разобрались в стандарном ****, настроили его и заставили работать, а также сделали ряд доработок для повышения удобства использования".

Да это круто если Вы написали именно свой модуль, качественно написать свой модуль, не под цели одного заказчика это действительно довольно сложно..... у нас же происходит все как обычно пишим под конкретные цели одного заказчика а потом продоем это как подойдет всем. А еще круче когда Ваш модуль полностью базируется на стандарте и ни как его не ломает : )

[ice]

еще смотря что считать за собственный модуль, например, в книжке по Ax описывается пример создания модуля управления гостиницей, и те кто его сделал, могут говорить, что они создали собственный модуль

пс и там полная бесшовная интеграция есть

[Stepa]

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

[mazzy]

Цитата:

Сообщение от ice

ИМХО "собственный модуль" для некоторых руководителей является показателем профессионализма и умения работать с нестандартным кодом

"нестандартный код" - это код не из стандартных модулей?
в любом случае, какая разница в коде то?

Цитата:

Сообщение от Stepa

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

Во-первых, спасибо.
Во-вторых, ... вот пройдет пара лет, сменится команда спецов (может быть, неоднократно), на ходу поменяются требования (может быть, неоднократно) и "собственный модуль" превратится в такую же мешанину исторических напластований... что и стандартный код.

Поэтому очень скпетически отношусь к результату попыток "написать с нуля". И наличие бесчисленных поделок в 1С только подтерждает мою личную убежденность.

Единственное чем отличается (на самом деле) собственный код от стандартного - собственный код можно самостоятельно рефакторить. А для стандартного надо писать врапперы... Но это такое технически рутинное отличие...

В общем, попробуйте. Вы не первые. Но вдруг у вас что-нибудь получится.

[ice]

Цитата:

Сообщение от mazzy

"нестандартный код" - это код не из стандартных модулей?
в любом случае, какая разница в коде то?

честно говоря, трудно дать определение этому выражению, но с таким кодом постоянно приходится иметь дело

[Lemming]

Неоднократно участвовал в подобной затее. Ничего крутого в этом нету. Всякий раз когда казалось бы - сейчас мы "сделаем конфетку", все эти затеи спотыкались о реальную действительность, которая видна не на стадии проектирования или тестирования, а когда её начинают юзать конечные пользователи. ИМХО, самая большая сложность в этом деле это именно на стадии проектирования учесть все то, чего мы еще даже не предполагаем Как пишет Эльдар Мусаев, получается не "экономика знаний", а "экономика открытий". В общем, раз уж вопрос стоит "круто это" или "не круто". Ответ, не круто. Реально круто, уметь адаптировать стандартный функционал так, что если вдруг твою модификацию отключают, то система работает стандартным образом, без оговорок, вроде: "из-за этой вот модификации, стандартом мы уже не сможем пользоваться".

[Vals]

Сколько я таких решений видел, везде есть разной степени тяжести недочёты, которые не позволяют назвать решение красивым.

Хочу посоветовать командам разработчиков показывать ТЗ экспертам на предмет проверки "чё мы такого упустили".

[ice]

Цитата:

Сообщение от Vals

Сколько я таких решений видел, везде есть разной степени тяжести недочёты, которые не позволяют назвать решение красивым.

Хочу посоветовать командам разработчиков показывать ТЗ экспертам на предмет проверки "чё мы такого упустили".

"а судьи кто?"

[Vals]

Цитата:

Сообщение от ice

"а судьи кто?"

1. Те, кому вы доверяете.
2. Не судить, а подсказать альтернативы, пути решения, возможности и т.д.

[Zabr]

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

• Сложность серьезных модификаций на основе существующих модулей - в доскональном знании их архитектуры, в знании стандартного (а значит - чужого) кода и способов его правильного использования (что для чужого кода всегда сложно, особенно в условиях тотального отсутствия документации от разработчиков и архитекторов системы).
• Сложность написания собственных модулей, не базирующихся на стандартном функционале - в доскональном и полном понимании бизнес-процессов, для которых разрабатывается этот функционал, и как этот функционал нужно правильно связать со стандартным (если это нужно, а бывает что и не нужно вообще).

[EVGL]

У меня вот другие несколько проблемы. Интеграция с системой - лучше некуда, зато часто не хватает времени или духа довести собственные идеи до логического конца. Пример: сделали печать ярлыков из журнала ГП в производстве, но не сделали аналогичной печати ярлыков для приемки сырья. Сидим, дописываем.