Миф о модифицируемости Аксапта, или техническая эстетика.

[StoneRoller]

Цитата:

Изначально опубликовано Тимур


Ну это неправда.

Правда. Вся работа разработчиков строится на формах, отчетах и событиях. В противном случае техсаппорт теряется. Я всех деталей не знаю - но отступлений от такой практики практически не бывает.

[Тимур]

Цитата:

Изначально опубликовано mazzy

"Чтобы рассуждать" достаточно любого опыта.
Тимур, ты неправ.

ок. Тогда я буду рассуждать как правильно программировать.

[Тимур]

Цитата:

Изначально опубликовано Alks


Хорошо, согласен с тем что у меня нет опыта в SAP или чём то еще подобном кроме Axapta и 1С, поэтому на данном этапе сузим мой пост только до рамок Аксапты. Перечитайте его еще раз и ответьте с этих позиций.
Далее более - если там есть что то верное для Аксапты и неверное для SAP/R3, то может хотя бы потрудитесь в общих чертах пояснить почему? Неужели в SAP предусмотрены все виды экспорта/импорта во внешние системы которые клиенту будет разумно сопрячь с ними и не надо программировать?

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

Только не надо утрировать. Одно дело сопряжение с другими системами, а другое - пример, который Вы привели в начале. Пример касается слабости функционала.
Есть четыре важных аспекта, которые многие путают ввиду разности реализации в той или иной системе:
1) инструменты экспорта-импорта и интеграция с другими системами; да, они настраиваются или разрабатываются, а интеграция настраивается или программируется;
2) дизайн экранных форм и отчетов; да, система обязана давать возможности его изменить;
3) стандартные функциональные возможности системы - нет; та система, которая позволяет это сделать настройками дает на выходе меньше багов;
4) новый функционал - нет. Это дело производителя системы, а клиент должен подбирать себе подходящую систему(ы).
По поводу пункта (4). Прошу не путать внесение дополнительных справочных полей и прочего с разработкой новых модулей системы.

[Тимур]

Цитата:

Изначально опубликовано Андре


Можешь прокомментировать ? Мое утверждение основано на общении с программистами несколько лет работающими с OEBS.
А ваше ? Какие еще средства разработки предоставляются разработчику внедряющему OEBS ?

Вопрос был не в средствах разработки, а в том, чего можно достичь имеющимеся.

[Тимур]

Цитата:

Изначально опубликовано StoneRoller

Правда. Вся работа разработчиков строится на формах, отчетах и событиях. В противном случае техсаппорт теряется. Я всех деталей не знаю - но отступлений от такой практики практически не бывает.

Именно так. Саппорт разработок партнеров осуществляют сами партнеры.

[Alks]

Короче говоря почитав и поразмыслив я вижу только одно серьезное (действительно значимое, в отличие от остальных недопониманий и несогласованностей в терминах) разногласние - в пункте 4:

Цитата:

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

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

[Тимур]

Цитата:

Изначально опубликовано Alks

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

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

[Alks]

Цитата:

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

Так я то же самое и говорю. Пытаться переработать стандартный функционал - себе дороже, но статическая закрытая система - тоже зло, потому что не оставляет потребителю пространства для очень нужных иногда манёвров - таких как "ф-я внесения данных" (весь спектр которых разработчик по понятным причинах охватить не может) и (я всё таки настаиваю) многих других, потому что тут опять же надо выяснять что значит является ли гипотетическая доработка "модулем тесно сплетенным с другими", или просто "внесением данных". Например к чему надо относить тот же тестовый проект "Модуль управления ремонтами", делающий проводки по главной книге?

[Тимур]

Да не вопрос. Тот же SAP имеет открытую среду разработки и Oracle.
Хочет кто-то модифицировать - берет на себя все риски и затраты.

Я ж говорю, как избежать рисков и получить приемлемый результат при выборе и внедрении ERP-системы.

[Андре]

Цитата:

Тот же SAP имеет открытую среду разработки и Oracle.

Тимур, не надо перевирать.

В отличие от Oracle и SAP, разработка в Аксапта построена так, что все разработчики имет в своем распоряжении один и тот же код (если куплены лицензии).

[Тимур]

Цитата:

Изначально опубликовано Андре


Тимур, не надо перевирать.

В отличие от Oracle и SAP, разработка в Аксапта построена так, что все разработчики имет в своем распоряжении один и тот же код (если куплены лицензии).

Да. Вначале у них конечно один исходный код.

Проясни свою мысль. В чем я переврал.

[Андре]

Цитата:

Проясни свою мысль. В чем я переврал.

Ок.

Аксапта - Damgaard/Navision/MS - пишет ядро. Вся логика основывается на этом ядре и пишется на X++. Ключевая фраза - вся логика пишется на X++. Это значит, что у разработчика в американском mbs, российском mbs и у простого разработчика из села Новые Васюки один и тот же исходный код - который они могут править.

В Oracle же часть функционала(логики) поставляется в уже откомпилированном виде и для модификации не доступна (например, все EJB). То есть, рядовому разработчика из СИ доступна для модификации уже не вся логика, а довольно малая ее часть.

[Тимур]

Цитата:

Изначально опубликовано Андре


Ок.

Аксапта - Damgaard/Navision/MS - пишет ядро. Вся логика основывается на этом ядре и пишется на X++. Ключевая фраза - вся логика пишется на X++. Это значит, что у разработчика в американском mbs, российском mbs и у простого разработчика из села Новые Васюки один и тот же исходный код - который они могут править.

В Oracle же часть функционала(логики) поставляется в уже откомпилированном виде и для модификации не доступна (например, все EJB). То есть, рядовому разработчика из СИ доступна для модификации уже не вся логика, а довольно малая ее часть.

Ага. Все правильно. Именно так и должно быть. Потому что напортачит этот простой разработчик, смоется с предприятия, а потом клиент будет обвинять разработчика в том, что это его продукт не работает! Как счас и происходит с Axapta и Navision.
Ребята, я понимаю, хочется могучих возможностей вплоть до того, что снести все и написать с нуля. Но поймите, это корпоративное ПО, а не средство разработки. Были уникумы в свое время, которые писали с++ на с++ - ради прикола.

Тех инструментов, которые предоставляются разработчиком Оracle и SAP вполне хватит, чтобы напортачить. Поэтому я бы вообще запретил модификации. Разрабатывать - это все равно, что ящик Пандорры открывать.
Разработчики должны работать у вендора. И должны разрабатывать многофункциональные системы, а не давать средства разработки, на которых клиент будет лабать себе систему.
Это принцип разделения труда. Каждый занимается тем, что ему приносит добавленную стоимость. Вендор делает систему, а не средства разработки, и продает ее. Партнеры - внедряют. Клиенты - используют.

[Андре]

Цитата:

Ага. Все правильно. Именно так и должно быть.

А я и не говрил, что это не правильно. Я пояснял, где ты переврал.

[Alks]

У меня есть одна любимая книжка по C++ которая наз-ся "веревка достаточно длинная, чтобы выстрелить себе в голову".
Подразумевалось то, что язык C++ настолько многогранен, универсален и гибок, что очень легко совершить какую нибудь "трагическую" ошибку бездумно программируя на нём.

Так вот - согласен с тем что открытые системы автоматизации "более чем длинная веревка, чтобы выстрелить себе в голову".

[Тимур]

Цитата:

Изначально опубликовано Андре


А я и не говрил, что это не правильно. Я пояснял, где ты переврал.

Я не переврал. А не уточнил нюанс.

[Тимур]

Так вот для России открытый код в корпоративном ПО - это беда, ввиду:
1) нежелания программистов документировать изменения и разработки;
2) неумения многих клиентов (особенно на среднем рынке) оценивать риски и ТСО;
3) горластости сейлз-менеджеров, которые расхваливают и "идут на встречу пожеланиям" клиентов.

[ppson]

Цитата:

Изначально опубликовано Тимур
Так вот для России открытый код в корпоративном ПО - это беда, ввиду:
1) нежелания программистов документировать изменения и разработки;
2) неумения многих клиентов (особенно на среднем рынке) оценивать риски и ТСО;
3) горластости сейлз-менеджеров, которые расхваливают и "идут на встречу пожеланиям" клиентов.

Я тебя умоляю, Тимур , перестань!
Прямо там у них все документируется (у Аксапты все классы обдокументированы :-)))), многие клиенты оценивают риски (все проекты успешные???), а продавцы говорят всегдя правда и ничего кроме правды .

[Тимур]

Цитата:

Изначально опубликовано ppson

Я тебя умоляю, Тимур , перестань!
Прямо там у них все документируется (у Аксапты все классы обдокументированы :-)))), многие клиенты оценивают риски (все проекты успешные???), а продавцы говорят всегдя правда и ничего кроме правды .

Олег.
1) творчество датских программистов - это не пример, а скорее исключение. Но если даже их труды сравнить с трудами наших умельцев - у них, потомков викингов, лучше поставлен процесс. Тут захаживают на форум бывшие "наши" из Дании, можно у них спросить.
2) на счет оценки рисков. Звучит как в анекдоте:
- Вы бы хоть лобовое стекло протерли;
- А зачем? Я все равно очки дома оставил.
Я не говорил, что оценка рисков - достаточное условие успешности проекта, но оно, безусловно необходимое.
Еще часто бывают, что многие думают, что если сделают одну необходимую вещь, то будет все ок. Это от лени. Перечень мероприятий известен. Варьируются лишь в зависимости от сложности и масштабности проекта.

3) У нас пока слабо работают статьи Административного кодекса в части наказания за недобросовестную рекламу и введение покупателя в заблуждение. Зарубежом очень часто применялись подобные статьи в 60-70хх. После этого количество "вешать лапшу на уши" сильно сократилось. Теперь у них там обратная ситуация - покупатели пытаются надуть продавцов.

[Alks]

Тогда вопрос: а как вы считаете, зачем тогда существуют открытые системы?
Чтобы вводить покупателя в заблуждение с целью извлечения прибыли?