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

[ax_mct]

Цитата:

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

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

Именно что инструментарий.

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

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

То ООП которое есть оно делает систему монолитной и запутанной. По большей части именно потому что за дублирование кода сжигают на костре. А паттерны там где они абсолютно бесполезны - приветствуют.

[ax_mct]

Цитата:

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

но что заставляет людей экспериментировать и кардинально переделывать шестую-седьмую версию успешно работающей системы?
причем это касается, и аксапты, и навижина, и, насколько я понимаю, MS CRM.

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

подключение нового инструментария? пусть так.
но почему этот инструментарий не распространяется на всю экосистему?

=================
и еще. пусть эксперименты.
а каков механизм избавления от этих экспериментов?

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

в программировании это рефакторинг legacy-систем. есть много холиваров на эту тему.
но МС код вообще не рефакторит.
...
какие еще примеры экспериментов и Оver-engineering в программных продуктах можно привести?
есть ли примеры успешного преодоления последствий?
какие еще механизмы есть в программировании для борьбы со сложностью и устаревшим кодом? есть ли примеры-аналоги?

Как Groupon мигрировал от монолитного Rails приложения к новой Node.js инфраструктуре
https://habrahabr.ru/post/200906/

Цитата:

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

[macklakov]

Цитата:

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

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

Это уже экстремизм! Сфинктер это отличный инжинерный паттерн. Не надо путать ора-анус со сфинктером.

[ax_mct]

Цитата:

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

Это уже экстремизм! Сфинктер это отличный инжинерный паттерн. Не надо путать ора-анус со сфинктером.

Мысль о том что прослойка между GUI и DB слишком много о себе вообразила - крайне интересна.
Это стоит подумать.

Цитата:

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

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

[ax_mct]

Цитата:

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

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

Хороший пойнт. Разные источники данных.
Можно и сказать что и GUI - главное. Но если смотреть в корень технической реализации то скорее таки база данных. Все остальное оболочка ввода и вывода.
Востребованная функциональность - это да. Но не важно как она реализована через простое ООП, сложное ООП или без ООП.

По хорошему создание X++ для обеспечения этой прослойки - было overengineering. Просто кто-то хотел был творцом. Возможно разумнее было использовать Java.
P.S. Но возможно это было обусловлено как эволюция XAL чтобы использовать уже существующий код - здесь я про overengineering только предполагаю.

[belugin]

> Никому не нужна общность отверстий кроме программистского мозга.

Я знаю одно выражение, использующее общность отверстий. Там прямо квантор всеобщности и просторечное выражение обозначающее отверстия (но по контексту ясно что не имеются ввиду прорехи в одежды).

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

Я бы стал извлекать сведения из доменного специалиста или книжки, но мне влом.

В википедии:

"The anus (from Latin anus meaning "ring", "circle") is an opening at the opposite end of an animal's digestive tract from the mouth."

"In biological anatomy, commonly referred to as the mouth, under formal names such as the oral cavity, buccal cavity, or in Latin cavum oris,[1] is the opening through which many animals take in food and issue vocal sounds."

"Some animal phyla, including vertebrates, have a complete digestive system, with a mouth at one end and an anus at the other. Which end forms first in ontogeny is a criterion used to classify animals into protostome and deuterostome."

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

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

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

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

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

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

[ax_mct]

Цитата:

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

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

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

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

[macklakov]

Цитата:

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

Соответственно пример со ртом и анусом мне непонятен и почему вендор - взят из реальности, а контрагент - нет тоже

В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто. И в это понятие совершенно естественным образом попадают и сотрудники и арендаторы и даже банки.
Есди продолжать проводить аналогии с биологической классификацией, то oris и anus объединили по каким-то общим признакам, а вот нос, желудок, верхние и средние разделы кишечника, протоки желез в эту классификацию почему-то не попали. При этом физиологически они сделаны разными, а вот перифирийная нервная система из одного узла активируется.

[belugin]

Цитата:

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

В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто.

Цитата:

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

Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию.

Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?

[belugin]

Цитата:

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

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

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

Цитата:

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

Что такое ООП-общность и чем она отличается от других видов общности?
Что такое "Кросс-модульная организация кода"?

[macklakov]

Цитата:

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

Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?

Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger.
И вот в системе у нас ГК, которая делает CustTrans, VendTrans ненужными. Но и CustVendTrans тоже никуда не неделись. При этом TaxTrans почему-то в эту чудесную иерархию не попадают. И payroll тоже. И даже для банков у нас какой-то причудливый reconciliation, который, по сути дела, тот же settlement, только чудовищно кривой.
Т.е. как раз дублирования в коде и функционале выше крыши. И чтобы это дублирование поддерживать, приходится писать всякие феерические reconciliation reports. Количество дублирования только нарастает. Но при этом произвольные куски вдруг покрыты иерархиями. В то время как другие вполне себе отдельно живут.

[Vadik]

Цитата:

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

Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger

Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же, в ГК ? А что, мне нравится. А то понапридумывают фреймворков-шмеймфорков непонятных

[macklakov]

Цитата:

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

Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же

Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR. Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?
И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?

[Vadik]

Цитата:

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

Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR

Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)

Цитата:

И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?

Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?

Цитата:

Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?

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

[Pavel]

Цитата:

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

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

Поддерживаю. Надо было апдейтить ядро, совершенствуя технологии и оставить в покое бизнес-логику и БД, написанную на 4GL.

[Pavel]

Цитата:

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

По хорошему создание X++ для обеспечения этой прослойки - было overengineering. Просто кто-то хотел был творцом. Возможно разумнее было использовать Java.
P.S. Но возможно это было обусловлено как эволюция XAL чтобы использовать уже существующий код - здесь я про overengineering только предполагаю.

Хмм... содержательная у вас тут дискуссия.)
Иногда заглядываю, что обсуждают кодеры в первых топиках и прихожу в ужас. Такая 'эволюция', просто как с навигатором по GPS в сортир дома ходить... а когда пропадает сигнал, 'забыв обо всем', решать вопросы со спутниками и коммуникациями.

Если отвлечься от 'бытовухи' и чисто ради 'академического интереса' задаться вопросом: насколько ООП сочетается/противоречит технологии слоев (своего рода полиморфизм) или системным номерам таблиц и полей (выделение диапазонов для ядра и доработки)? - то становится интересно мнение творцов этого синтеза.)

ООП это все не нужно, как самодостоточной технологии.

[mazzy]

Computer, open pen
https://www.youtube.com/watch?v=nY7i7kj2jO4

[macklakov]

Цитата:

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

Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)

скидки по оплате и aging? можешь описать как и зачем?

Цитата:

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

Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?

Зачем такие аналитики нужны? Я вот видел системы где счета через черточку и AR это буквальным образом счет accounts receivable в ГК и один из сегментов это именно клиент. Очень сильно напоминает эти самые entity backed. И еще очень характерная технология это journal transfer. Т.е. проводки пишутся журналами и лишь потом, отдельной операцией, переносятся в ГК. Ничего не напоминает?
Т.к. мы заменяли эту замечательную систему на AX, нам даже требование впендюрили, наладить периодический перенос журналов. Что было с легкостью реализованно ибо у нас теперь есть синхронная, асинхронная и batch разноска. Вы все еще думаете это великий замысел, с целью разгрузить сервера? Такой великий замысел что пришлось покрыть каждый модуль reconciliation reports, чтобы проводки между модулями и ГК не слишком сильно расходились.

Цитата:

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

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

Это правда, мой опыт в последние годы ограничен диковатой колонией и несколькими варварскими странами.

[macklakov]

Мне вся эта ситуация с новой ГК видится вот как. Купил мужик на ebay 2 велика:


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

[EVGL]

Цитата:

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

скидки по оплате и aging? можешь описать как и зачем?

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

Aging в AP - экзотика, но в балансе разделяют кратковременную и долговременную (дольше года) задолженность. Для этой реклассификации можно в теории использовать отчет.