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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Оverengineering - это проявление болезни программизма у 90%. Я очень сомневаюсь в том что в других условиях эти же программисты не будут страдать этой заразой. Поднявшись по служебной лестнице им и в голову не придет что перенос на .NET и переход на VS - это Оverengineering.
Если бы этой деформации реальности в мозгах технических специалистов не было - то и не случалось бы постановки таких задач и создания таких условий. Психическая Болезнь.

И не думаю что надо понимать и оправдывать ".NET программистов" к которым это попало в руки. Это не в один день случилось и начали это не "чужие", а "свои". Системные программисты АХ. Страдающие программизмом.

Цитата:

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

мысль понятна.
но чтобы получить ответ стоит сформулировать полностью: будет хуже кому? в чем выражается хужесть?

Хуже всем. Клиенту, партнеру, вендору.
Выражается в удовлетворении (куда входит и цена-качество) и в удобстве. Для всех участников.
То есть при отсутствии ненужных изменений в технической стороне как проявления Оverengineering в сознании специалистов всех уровней
нахождение на технической платформе 3.0 (к примеру) было бы лучше для всех участников эко-системы.
Все изменения абсолютно иррациональны и ни что иное как деформация сознания на всех уровнях и отсутствия чувства оverengineering. Даже в бизнесе это понимание простоты логики критически необходимо для успеха.

[egorych]

Цитата:

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

нахождение на технической платформе 3.0 (к примеру) было бы лучше для всех участников эко-системы.

Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.

[Ace of Database]

Цитата:

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

Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.

Когда МСу надоест заниматься ERP, с его стороны было бы очень красивым жестом отпустить Аксапту в свободное плавание в Open Source в том виде, в котором она была в AX2009.Да пусть даже и в том виде, как она была в AX3. Все-таки DirParty сильно напрягают, и еще самому себе делать assert в коде тоже напрягает. В АХ 3 было классно без assert'ов. Но в AX2009 пакетники лучше работают, чем в AX3.

[ax_mct]

Цитата:

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

Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.

Платформа "устарела", "современные технологии" - это оно самое. Болезнь
"устарела" если нельзя полноценно CLR Interop
"современные технологии" - AIF, Sharepoint...

3.0 я привожу для чистоты примера. Да 2009 - лучше, но велика ли разница?
То что OCC, RecId, RPC и подобное это действительно kernel необходимое, и никак не часть "2009".
Но добавление что-то типа использования .NET service proxy, WCF - чистый воды програмизм.
AIF - чистый пример оverengineering.
Переход на Sharepoint EP - оverengineering.

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

Качество партнеров, рынок, проекты

Цитата:

Сообщение от George Nordic

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

Вот все что прямо не направлено на закрытие потребностей клиентов, мешает удобно и шустро работать, усложняет изменение кода - и есть оverengineering как проявление дурной болезни.

[egorych]

Цитата:

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

Платформа "устарела", "современные технологии" - это оно самое. Болезнь
"устарела" если нельзя полноценно CLR Interop
"современные технологии" - AIF, Sharepoint...

3.0 я привожу для чистоты примера. Да 2009 - лучше, но велика ли разница?

По-моему очень велика! Хотя-бы при работе с памятью - АОС 3,0 при "наборе" 1,5Г памяти просто вешается. AIF и т.п. - это просто надстройки, а вот создать просто Web-сервис в 3.0 и 2009 - это 3 большие разницы.

[ax_mct]

Цитата:

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

По-моему очень велика! Хотя-бы при работе с памятью - АОС 3,0 при "наборе" 1,5Г памяти просто вешается. AIF и т.п. - это просто надстройки, а вот создать просто Web-сервис в 3.0 и 2009 - это 3 большие разницы.

При стандартной поддержке существующего эти kernel проблемы были бы решены в рабочем порядке.

А разница создания Web-сервис в 3.0 и 2009 - это программизм. Это вопрос новых классов/библиотек на уровне языка. Генерировать код можно на чем угодно.

[belugin]

Цитата:

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

придет что перенос на .NET и переход на VS - это Оverengineering.

Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?

Вон ABAP вполне себе на Eclipse живет (поправьте, если я что-то не так понимаю)

[ax_mct]

Цитата:

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

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

От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.
Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.

Цитата:

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

Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?

Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Медленность нативного X++ это миф, бедность IDE - миф.
Скорость это железо, база данных и кэширование, бедность IDE - это плагины.

[mazzy]

Цитата:

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

Медленность нативного X++ это миф, бедность IDE - миф.

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

и дело даже не в портировании на .net/vs.
каждый помнит тормоза при первом обращении к AOT, при создании программисткого проекта. для глобальной компиляции аж специальную утилиту сделали.

про бедность - стоит вспомнить, что X++ основан на java-виртуальной машине первого поколения. когда никакого JIT, никаких оптимизаторов, тривиальный сборщик мусора, убогая модель объектов в памяти, чудовищно неэффективные exception и кривая релиазция tread, никаких функций высшего порядка. (тривиальный-убогий-неэффективный конечно по нынешним временам и по современным меркам).

сейчас актуальной является java 8 поколения. ближайшим будущим является java 9.

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

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

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

==========================
не, morphX - отличная вещь для своего времени, хорошо продуманная и крепко сделанная.
но рано или поздно все-таки надо двигаться дальше.
и хорошо, что двигаются.

[ax_mct]

Цитата:

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

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

Спасибо за по существу. Но можно слушать пользователей, то есть не страдать аутизмом, но при этом продолжать болеть программизмом и в упор не видеть оverengineering.

Тормозов стало меньше? Что-то стало быстрее? Да на текущем железе оно летало бы.
Программировать стало легче?

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

оverengineering это когда нет чувства достаточности. Тот медленный и бедный нативный X++ был достаточен. Это как лопату усовершенствовать.

[belugin]

Цитата:

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

Что-то стало быстрее?

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

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

[Logger]

Цитата:

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

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора

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

1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?

2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.

3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему Помогите найти: Сравнение производительности различных операндов при конкатенации строк
операция += в CIL ведет себя по-тормозному по сравнению с p-code. И никуда тут не денешься. только если переписывать код через StringBuilder или TextBuffer что сильно ухудшает читаемость.

пп. 1-2 зануляют все плюсы CIL
Рука тянется за револьвером

[ax_mct]

Цитата:

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

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

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

Моя категоричность она для чистоты лечения

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое решение.

Но нам же неинтересен плоский T-SQL так как 3D OOП, не так ли? Вот оно и есть - программизм.

[belugin]

Цитата:

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

От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.

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

Цитата:

Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.

Только вчера ревьюил фикс баги, которая бы не возникла если бы код не продублировали.

Цитата:

Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Докажите.

Цитата:

бедность IDE - это плагины.

Вы непонятно выражаетесь. "Граальность" VS в том, что плагинов там большая куча

[Ace of Database]

Цитата:

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

Только вчера ревьюил фикс баги, которая бы не возникла если бы код не продублировали.

Похоже, чтобы решить задачку из соседней ветки, придется продублировать целую форму. А в старых Аксаптах все решилось бы маленькой модификацией
добавить readonly датасорс на форму, для фильтрования
Так какой подход плодит больше багов: старый или новый?

[belugin]

Цитата:

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

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

Если бы там был метод в 2000 строк - было бы легче?

[Ace of Database]

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