Оver-engineering - "зачем так сложно?"

[ax_mct]

Цитата:

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

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

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

Общего - до фига. А дублировать код - не по жабьи.

[mazzy]

Мдя... это уже перебор.

[ax_mct]

Цитата:

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

Мдя... это уже перебор.

Ну а как иначе сказать? Это не ругательство а наглядный пример так как с телом человека все знакомы. Рот - получаем еду, "зеркальный рот" - выводим. То же что и с Accounts "In" и "Out".
Масса общего если задуматься.

Ну и от лица той инопланетной жабы могу сказать что обьединение не с потолка взято, а из природы.
Вторичноротые.
https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%83%D1%81
У кишечнополостных и у плоских червей анальное отверстие отсутствует, у вторичноротых животных анальное отверстие развивается на месте первичного зародышевого рта.

По моему прекрасный пример абсурда моделирования когда мы не хотим дублировать код. Функция "Сжать" должна быть членом класса Отверстие. И так далее.

[mazzy]

Цитата:

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

По моему прекрасный пример

нет. как раз наоборот.
поинтересуйтесь, поизучайте.

например, https://www.youtube.com/watch?v=X6-DKuwHyjY
а также Висцеральная теория сна https://www.youtube.com/watch?v=2c7G_ml791w
и другие примеры оверинжиниринга в эволюции

только, пожалуйста, общие обсуждение оверинжиниринга - в специальную ветку
Оver-engineering - "зачем так сложно?" - Мортира Карл

ax_mct, давайте я сделаю предупреждение еще раз.
будете гадить в этой ветке, буду банить.

здесь тема про Аксапту
Оver-engineering - "зачем так сложно?"

[ta_and]

Цитата:

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

в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.

Я очень долго думал о причине разделения таблиц CustTable и VendTable.
Никак не мог для себя понять. ЗАЧЕМ было разделять таблицу контрагентов на две независимые таблицы.
Единственное, что меня успокоило и более или менее оправдало это решение - это разграничение прав доступа.
Ведь в Ах ранних версий настроить права доступа по записям было на два порядка сложнее, чем разграничить права доступа к разным таблицам.
Видимо только поэтому родились Cust и Vend вместо Contragent.
Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)

[Raven Melancholic]

Клиенты-поставщики всего лишь небольшая часть проблемы классификации, выделения общих и различающихся признаков и совсем не являются уникальной проблемой не только Аксапты, но даже и не связанной вообще с ERP. Большинство знает афоризм про определение того, к какой науке относится явление (если зеленое, то.., если пахнет, то…).
Почему их разделили в разные справочники, а потом нарисовали код, который их обрабатывает как что-то похожее? Ну принято было такое решение, ему и следуют и нам тоже приходится следовать. Другие варианты были? Конечно были, многие в других системах видели реализацию других вариантов. Лучше другие варианты или хуже? В одних ситуациях лучше, в других хуже.
Достаточно давно встречал описание того, как определить является ли архитектор приложения профессионалом. Если на вопрос «как правильно реализовать вот эту штуку?» начинаются ответы, что «вот только так..», то это новичок, профессионал начнет свой ответ «это смотря с какой стороны посмотреть…».
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.
Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым. Если делаем сопоставление, что почему для клиентов/поставщиков механизм один, а для подотчетников другой? Можно сказать, что для последних есть отличия, но так они и для клиентов/поставщиков есть – почему тогда не разделили сопоставление для клиентов/потавщиков?

[ax_mct]

Цитата:

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

...Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)

Одна шляпа - это программизм. Если бы и таблицы и код были отдельны и независимы всем было бы лучше. Кроме программистов которым больно смотреть на дублирование кода и данных.

Цитата:

Сообщение от Raven Melancholic

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

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

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

ООП должно быть подчинено процессу и обслуживать процесс.
Не контрагент.Действие(), а действие(Контрагент).
Никому не нужна общность отверстий кроме программистского мозга.
"Принимать пищу", "Усвоить пищу", "Выводить усвоенное" - реализация этих функций нужна, а не реализация "рот беззубый зеркальный". И сколько бы не было мнимого дублирования - если это повышает независимость и надёжность, то и замечательно.

[Pustik]

Цитата:

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

Я очень долго думал о причине разделения таблиц CustTable и VendTable.

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

[Raven Melancholic]

Цитата:

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

Программистский подход - искать общее, объединять.

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

Ответил в Курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл

Именно что программистский учет не должен отражать то чего нет в реальности. Дублирование кода - наименьшее зло.

Цитата:

так как вендор и кастер (ну предположим Вася Пупкин) совершенно разные единицы в управленческом и бухгалтерском учете.

[Raven Melancholic]

Цитата:

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

Несомненно свысока своего опыта мы понимаем, что было бы лучше, что хуже.

Не только мы. Ну не любят некоторые участники форума правил, наработанного опыта и т.п., но еще в 50-60 годах 20 века обсуждалось "правило жирафа".
"Спросите у специалистов, почему у жирафа такая длинная шея и получите много абсолютно правильных и обоснованных ответов, почему так получилось. А теперь спросите, раз это все так важно, то почему у жирафа шея длинная, а у зебры нет?" это должно быть помечено (С), но я не знаю чьим.

[macklakov]

Цитата:

Сообщение от Raven Melancholic

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

Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса.
А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно. К примеру, если это компания-партнер, которая покупает товары, оказывает вам услуги, берет у вас в долг и держит на руках ваши акции. А еще они одалживают оборудование и дают свой товар на ответственное хранение. И вот мы должны посмотреть, кто чего и кому должен... И вот здесь все становится очень сложно. Без хитрых фреймворков такой функционал станет совершенно несопровождаемым.
Но причина-то ведь не в ООП! Причина в ошибках дизайна БД! Именно из-за того что структура таблиц неадекватно отражает бизнс-сущности, и возникает необходимость применять высший архитектурный пилотаж. Ярчайший пример, новая ГК, не к ночи будет помянута. Ради нее одной огромное количество новшеств в программную среду внесено. ГК это ведь такая простая вещь, по своей сути. В каждой второй смописке есть и почти никогда это не является bottleneck. Но у нас это чудовищный монстр, забивающий базу с экспоненциальной скростью, из-за чего система начинает тормозить уже на среднем объеме проводок.

[macklakov]

Цитата:

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

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

Доступ на уровне записей и сейчас лучше не использовать. Быстродействие убивает. Дело в другом. Дело именно в увлеченностью ООП.
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно.
Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

[Raven Melancholic]

Цитата:

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

Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться.

Точно, что для ERP главное это база данных? Разве не предметная область?
Когда я должен дать ответ по данным кассового чека, сколько покупатель может получить бонусов за эту покупку в зависимости от текущих акций, то какая разница получил ли я данные чека из базы, в которую он уже сохранен, получил ли этот чек прямым запросом из кассовой системы через Connector или получил его запросом через WEB сервис от консультанта торгового зала с планшета?

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

...

Ответил в курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл

[macklakov]

Цитата:

Сообщение от Raven Melancholic

Точно, что для ERP главное это база данных? Разве не предметная область?

Предметная область в разы лучше реализуется всякими специализированными решениями. ERP обычно внедряют для того, чтобы повысить управляемость конторы в целом, а не для повышения эффективности операционистов (которого обычно не происходит). ERP это, своего рода, лекарство от болезней роста. Управляемость же достигается за счет консолидации информации, позволяющей строить разноплановую отчетность в реальном времени. Именно поэтому в маркетинге Dynamics такое значительное место занимает BI. Менеджмент хочет видеть что у них в конторе творится.
Т.е. если у на то пошло, то пляска идет даже не от базы, а от построителей отчетности. И я не знаю хороших построителей отчености по объектным базам данных, к примеру. А вот SAP, решили что им даже обычная RDB недостаточно, хороша, и потому запустили HANA.

[gl00mie]

Цитата:

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

ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно. Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.

Что-то тема наследования таблиц никак не отпустит - давайте на минуту отвлечемся от нее. А как же журналы, которые есть в Аксапте с давних времен, когда и нормального ООП хотя бы с модификаторами доступа для методов в ней не было? Там тоже ООП не к месту? Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?
А как же проводки в Управлении запасами, которые жили, не тужили в одном InventTrans'е, "обсчитываясь" двумя ортогональными иерархиями классов, реализующими всевозможные комбинации правил обновления статусов запасов с источниками этих обновлений? Там сколько разных таблиц надо было сделать, может, по одной на каждый источник (покупка, продажа, перенос, инвентаризация, списание в производство и т.п.)? А как надо было бы отвечать на вопрос, сколько товара на складе или откуда списать в резерв?..

Цитата:

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

Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно. Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

А для чего именно SAP замутил свою HANA, неужели для упрощения кода системы, а не для повышения производительности и масштабируемости? Разве не работал он десятилетиями на РБД сторонних производителей и разве не на этих РБД он завоевал свою долю рынка? Или, может, он свою долю рынка завоевал не благодаря РБД, а вопреки?..

Цитата:

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

Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса. А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно.

Есть такое понятие - называется party, и справочник отдельный для всех-всех контрагентов есть. Если нормально связывать сущности из разных модулей (клиентов, поставщиков, сотрудников, etc) через party и строить отчеты вокруг нее, то всё получится. Только мне бизнес-пользователи почему-то рассказывали, что им и их контрагентам не интересен баланс "вообще", им интересен баланс в разрезе договоров и проч. И сопоставлять проводки "вообще" контрагенты не позволяют: платит, допустим, клиент за отгрузки и явным образом уточняет, что это вот за те две недельной давности, а не за три другие месячной давности. Удивительные люди...

Цитата:

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

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

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

Цитата:

Сообщение от Raven Melancholic

Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.?

Проклятое наследие прошлого Для модулей РСК и РСП были отгрузки и оплаты, было сопоставление проводок - вот кому-то и показалось, что можно выделить общую логику. Для модуля управления персоналом такого сопоставления не требовалось - вот и не выделили. А расчетов с акционерами, инвесторами и заемщиками исторически вроде и вовсе не было.

Цитата:

Сообщение от Raven Melancholic

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

Пока что общий подход выливается во что-нить вроде Source Document Framework

[gl00mie]

Мне кажется, в Аксапте изначально всё довольно логично было спроектировано: вот есть отдельный модуль, у него есть свои основные сущности, есть движения по этим сущностям, есть журналы, которыми пользователям удобнее вводить информацию об этих движениях, есть запросы и отчеты, ну и еще настройки модуля. Далее, по ходу реализации выяснялось, что у модулей РСК и РСП много общего, а у других модулей - не так вроде много, поэтому ленивые программисты стали пытаться избавляться от копипаста и выносить общую бизнес-логику. Справочники так и не объединили, потому что по изначальной задумке они в каждом модуле - свои. Но общие вещи в итоге-таки вынесли в тот же ГАК.
Объективно ERP автоматизирует достаточно сложные сущности и процессы окружающего мира, и это определяет некий минимальный порог сложности самой системы. А разработка ПО крутится, с одной стороны, вокруг борьбы со сложностью, а с другой, - вокруг повторного использования кода. Две эти задачи неплохо решаются с помощью ООП, поэтому логично, что в Аксапте как сложной системе ООП используется достаточно широко и для борьбы со сложностью, и для повторного использования кода. Конечно, есть "перекосы на местах", конечно, кое-где выделение общей логики для повторного использования подчас сделано топорно и приносит больше проблем, чем пользы, особенно когда имеешь дело с методами в сотни строк кода. Но не стоит, по-моему, с водой выплескивать и ребенка, заявляя, что все проблемы Аксапты - от ООП.

[ax_mct]

Цитата:

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

Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?

А почему нет? Если "нет" только потому что это не соответствует ООП и нежеланию копипастить, то да, лучше нашлепать и тупо копипастить общую логику.

Цитата:

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

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

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

Мысль macklakov мне кажется очень интересной.

Цитата:

Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

[Logger]

Да не в SQL все дело.
А в оторванности от практики людей, создающих прикладной код аксапты.

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