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

[belugin]

Цитата:

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

SysOperation(где та-же видимость и метки задаются атрибутами) такая "простая" с виду модификация потребует кучу усилий

Не могли бы вы рассказать, что вы пытались можифицировать и какую именно кучу усилий это потребовало?

[trud]

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

[belugin]

Цитата:

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

ну вот допустим есть у вас Tutorial_RunbaseBatch

Хорошо, какие же именно усилия требуются для того. чтобы сделать то же самое для SysOperation?

[Ace of Database]

Цитата:

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

Все конечно довольны, но радость недолго длится. Некоторые ошибки вылезают только лет через 5-7.

Люди радовались целых 5-7 лет

[Ace of Database]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

[trud]

Цитата:

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

Хорошо, какие же именно усилия требуются для того. чтобы сделать то же самое для SysOperation?

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

[belugin]

Цитата:

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

Из моего скромного опыта, ответ зависит от того, как пойдут требования для изменений.

Я совершенно согласен с этим, есть еще факторы.

Цитата:

Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные".

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

Мне кажется тут первый список понятнее - ясно кто подчиняется общему умолчанию а кто нет.

У этих животных хвосты длинные:
- Лиса
- Бобер
- Кенгуру (кроме австралийских короткохвостых)
- Собака

- У лисы длинный хвост.
- У бобра недлинный хвост.
- Кенгуру имеет длинный хвост (кроме австралийских короткохвостых).
- Такой же хвост и у собаки.

Цитата:

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

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

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

Цитата:

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

Есть coupling и cohesion - если изменения надо как правило делать в двух местах сразу, иначе это будет ошибкой, то это не повышает надежности.

Я не против дублирования в принципе, просто оно должно быть обосновано.

[ax_mct]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

CustVend иерархия это хороший пример теория vs практика.
Обоюдоострый топор - прекрасная идея, но нам им лес валить.

Действительно если бы вместо settleNow() было два метода было бы легче.
И то что было бы повторение кода в этих двух методах - и слава яйцам в разных корзинах.

А главное мое "салон vs двигатель" слишком лиричное, а твое Это учетная система, она должна отражать реальность - понятнее.

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

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

[macklakov]

Цитата:

Сообщение от Ace of Database

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

Самому не стыдно? Твой код приходится менять. Почему сразу не продумал все варианты? Ведь у тебя же есть иерархия. Мог бы объявить объект класса-родителя, инициировать конкретного наследника через factory, исходя из параметров. Ну и потом почему поленился, нормально, через SysOperation, делать? Ведь это гораздо более универсальный механизм чем jobs.

Цитата:

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

Я не против дублирования в принципе, просто оно должно быть обосновано.

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

[belugin]

Цитата:

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

Почему сразу не продумал все варианты?

Тут другое интересно, почему вообще возникла задача сделать одно и то же в двух модулях, между которыми нет НИЧЕГО общего. То есть у кастомера и вендора общего не больше чем у кастомера и пирожка с капустой

[macklakov]

Цитата:

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

Тут другое интересно, почему вообще возникла задача сделать одно и то же в двух модулях, между которыми нет НИЧЕГО общего. То есть у кастомера и вендора общего не больше чем у кастомера и пирожка с капустой

Это в жизни у них общего мало. А в системе очень даже много. Ведь с точки зрения системы это лишь отражения счетов в ГК. А у всех счетов ГК много общего друг с другом. У них есть дебет, кредит и балланс.
Девочки операционистки зачастую слишком необразованны чтобы оценить величие и изящество замысла. Когда им звонит клиент, он ожидают видеть баланс клиента, а не баланс на счету AR. И поэтому им каждый раз приходится долго втолковывать что инвойс делает счет клиента положительным, а платеж делает этот счет отрицательным. И все равно путаются какое-то время.
Да что говорить. Процесс закупки настолько отличается от клиентского возврата, что целый модуль procurement and sourcing наваяли. И одобрения платежей. На закупках часто бывает 3-х уровневое одобрение, а возврат клиенту делается на месте. Но при возврате важен исходный платеж. А в оплате покупки такого платежа не было вовсе.
Зато мы не какие-то там быдлокодеры, которые под клиента подстраиваются. У нас наследование и фреймворки. Все как у взрослых

[belugin]

Цитата:

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

Ведь с точки зрения системы это лишь отражения счетов в ГК. А у всех счетов ГК много общего друг с другом.

То есть есть что-то общее и есть кокретное подразделение, которому нужно это общее, правильно?

Цитата:

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

То что есть различия, тоже понятно

Так вы на вопрос не ответили, как возникла вообще потребность сделать одно и то же для двух вещей, между которыми НИЧЕГО общего.

[macklakov]

Цитата:

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

Так вы на вопрос не ответили, как возникла вообще потребность сделать одно и то же для двух вещей, между которыми НИЧЕГО общего.

А откуда этот вопрос проистекает? Где сказано что в бизнесе между этими процессами много общего? Ace of Database говорит что у него джобы зеркально выглядят. Но они зеркально выглядят потому, что в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие. То что можно отзеркалить, вообще не должно в этих таблицах находиться. Справочник адресов и справочник юр. лиц отдельные сделать и все. Никакой иерархии наследования. Никакого зеркалирования. Юр. лицо, это юр. лицо, независимо от того, поставщик это, клиент, сотрудник на контакте, субподрядчик по проекту или еще кто. Проводки и по поставщикам и по клиентам должны отражаться в ГК. Это общее. Но они совершенно по разному отражаются. Разная детализация, разный смысл. Платежи, как уже упоминал, совершенно по разному обрабатываются. Процесс разный, зачастую сопровождается разными документами. И поэтому вся эта иерархия CustVendOutPaym только под ногами путается.

[dech]

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

[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 - "зачем так сложно?"

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

[macklakov]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

Элегантное, спору нет. Правда как не настраивай потом долго пользователей дрессироваться приходится что:"вот здесь пока прижимаешь, там тянешь, а вот ты в это время смотри чтобы оттуда не лезло". Но инженерно красиво. Гордость за систему. У других пара функций и все. А у нас наследование!

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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