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

[belugin]

Цитата:

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

А откуда этот вопрос проистекает? Где сказано что в бизнесе между этими процессами много общего? Ace of Database говорит что у него джобы зеркально выглядят. Но они зеркально выглядят потому, что в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего? Например, ко мне не может подойти начальник и сказать "испеки мне скорость и булочки с изюмом" просто потому, что для этих двуз понятий нет никакого общего смысла что-то делать. А вот для AR и AP возникла. Как так получается?

Цитата:

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

С совершенно разной структурой или они должны отличаться только данными?

То есть в одном справочнике есть юридический адрес, а в другом на этом месте табуретка?

[mazzy]

Цитата:

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

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

На самом деле не очень. А то реально общее - не полностью реализовано.
поставщики и клиенты - это контрагнеты.

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

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

контрагентов пытались получить на DirParty.
со всей вытекающей сложностью.

Цитата:

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

Чтобы избежать дублирования, изобрели Maps. Всю общую логику переместили в CustVend*. Очень элегантное решение, кстати.

будем справедливы:
1. maps изобрели не чтобы избежать, а чтобы хоть как то работать с дублированием.
2. не всю )
3. не очень элегантное. в стандартном функционале постоянно приходится писать if/switch... методы map имеют чудовищный синтаксис и очень плохо используются.

люди на проектах часто делают врапперы типа такого
https://github.com/mazzy-ax/SysCustVend

Цитата:

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

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

но это действительно разные процессы.

Цитата:

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего?

а нет такой потребности.
это просто техническое решение - сделать их похожими.

Цитата:

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

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

Чё это?
Зря ты принижаешь возможности начальника. ))))
Может конечно подойти и может сказать. Это твоя проблема как разработчика объяснить почему ты не будешь делать как начальник сказал ))))

Цитата:

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

То есть в одном справочнике есть юридический адрес, а в другом на этом месте табуретка?

да. у физика нет юридического адреса.

Цитата:

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

А вот для AR и AP возникла. Как так получается?
С совершенно разной структурой или они должны отличаться только данными?

Собственно это и есть тема этой ветки:
Оver-engineering - "зачем так сложно?"

[belugin]

Цитата:

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

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

а также сугубо технические операции типа сопоставления дебет-операций с кредит-операциями.

То есть структура сущностей имеет что-то общее, операции существенно разные так?

В каком смысле сопоставление "техническая" операция?

Цитата:

будем справедливы:
1. maps изобрели не чтобы избежать, а чтобы хоть как то работать с дублированием.

"Как-то работать" это и есть в каком-то смысле избежать. Например избежать дублирование кода который как-то работает.

Цитата:

3. не очень элегантное. в стандартном функционале постоянно приходится писать if/switch... методы map имеют чудовищный синтаксис и очень плохо используются.

Почему вообще возникает потребность делать общий код, если общего мало? Почему просто не продублировать?

Цитата:

люди на проектах часто делают врапперы типа такого
https://github.com/mazzy-ax/SysCustVend

Они все оверэнжиниры?

Цитата:

а нет такой потребности.
это просто техническое решение - сделать их похожими.

Только что выше ты сказал, что потребность есть. Все мепы и классы и прочее.

Цитата:

да. у физика нет юридического адреса.

Мы говорим о разнице между AR и AP а не физиками и лириками. В АR у юрика есть юр адрес, а в AP нет?

Цитата:

Собственно это и есть тема этой ветки:
Оver-engineering - "зачем так сложно?"

Так я хотел, просто понять точку зрения как бы сделали если бы эти справочники были независимы.

[mazzy]

Цитата:

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

То есть структура сущностей имеет что-то общее, операции существенно разные так?

перечитал выше. я вроде не употреблял слово "все" и его отрицание "ничего" )
что-то общее имеет. имеет и что-то различное.

Цитата:

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

В каком смысле сопоставление "техническая" операция?

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

Цитата:

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

"Как-то работать" это и есть в каком-то смысле избежать. Например избежать дублирование кода который как-то работает.

Макс, высказывание полностью на твоей совести.
Как скажешь.

Цитата:

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

Почему вообще возникает потребность делать общий код, если общего мало? Почему просто не продублировать?

Они все оверэнжиниры?

Как только возникает слово "ВСЕ" - жди логической ошибки.
Да, некоторые считают, что некоторые они - оверэнжиниры.

Цитата:

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

Только что выше ты сказал, что потребность есть. Все мепы и классы и прочее.

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

разница как между классом-потомками и интерфейсом-реализациями.

Цитата:

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

Мы говорим о разнице между AR и AP а не физиками и лириками. В АR у юрика есть юр адрес, а в AP нет?

я так и сказал - "не полностью реализовано".

Цитата:

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

Так я хотел, просто понять точку зрения как бы сделали если бы эти справочники были независимы.

Некоторые системы, например 1С, вводят понятие "контрагент"
а специфику сделки выносят в договор (там есть свои тараканы и есть свои минусы)

некоторые системы, например банковские, оперируют понятиями поставщик, а вместо клиентов могут быть разные типы аккаунтов - накопительные/текущие/карточные/валютные (там есть свои тараканы и есть свои минусы)

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

Просто ДВА модуля/справочника с одинаковыми полями - это не единственное решение. Справочников/модулей может быть и больше, и меньше.

[macklakov]

Цитата:

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

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

Не, ну в принципе да, процесс один. Только есть один маленький нюанс

Цитата:

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего?

Очень хороший вопрос. Ведь эти модули естественным образом расползаются, один в Procurement and Sourcing, а другой в Sales and Marketing. В чем тогда сермяжная правда двуединства Accounts Receivable и Accounts Payable? Может в слове Accounts?

Цитата:

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

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

Ну иерархию в DirParty сделали ведь. Значит и скорость испечь сможете. Технически вы отборные специалисты, лучшие на рынке. Значит справитесь.

[ax_mct]

Цитата:

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

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

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

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