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

[ax_mct]

Цитата:

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

Некоторые места в коде overengineered настолько, что смысл происходящего начинает ускользать. И наименования объектов лишь добавляют мистики.

Цитата:

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

зубная боль...
зачем?..............

Цитата:

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

Паттерны из GoF и подобная литература решает конкретную задачу в программировании и очень жалко что по историческим причинам в АХ попадают люди предпочитающие методы по 2000 строк потому что "все в 1 месте, так удобней" и отрицающие все что "не как в 4ке".

Тема очевидна и болезненна. Началась в частности с темы AX2012. Цель атрибутов в расширении наследования классов
но прорывается то там здесь криками душами и раздражением которые наверное можно коротко как "зачем?" "зачем так сложно?".

При этом очевидно что здесь мы делимся как минимум на два лагеря.

[mazzy]

не, не делимся на два.
или распределяемся по спектру, согласно критериям лучшести )))

Цитата:

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

На самом деле все проще.
Как и остальные люди, специалисты в МС хотят сделать лучше, проще, быстрее. Просто "критерии лучшести" в МС сильно отличаются от остальных людей.

Можно много говорить на тему "почему отличаются". Это отдельная тема.

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

[ax_mct]

Цитата:

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

не, не делимся на два.
или распределяемся по спектру, согласно критериям лучшести )))

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

Обозначим две стороны.
Старые пердуны которые не понимают зачем в Аксапте нужно общепринятое искусство программирования и другие, те кто прочитал "Искусcтво программирования Кнута" до конца.

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

Спектр спектром, но есть четкий водораздел - отношение к тому что есть оver-engineering кода в AX.
Для меня это любой код который я не понимаю в течение трех секунд и любой дизайн который мне интуитивно непонятен как программисту Аксапты. "Зубная боль... Зачем" (с)

Более того если увижу 2000 строк в одном месте - ругаться не буду. Да, это under-engineering но на практике это может быть и дешевле чем оver-engineering когда этот код разбит на пол-сотни классов обслуживающих не бизнес-логику, а междусобойчик паттернов кодирования.

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

Цитата:

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

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

[mazzy]

Цитата:

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

отношение к тому что есть оver-engineering кода в AX

нет, конечно. какие нафиг "отношения"?
разницу вносят очень технические и прагматичные моменты.

1.
прежде всего, кто должен реализовывать "защиту от дурака"?

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

если МС делает продукт для разработчиков партнеров/заказчиков,
то защиту от дурака должны делать эти разработчики партнеров/заказчиков.
следовательно код МС может содержать только happy path.
но стоимость внедрения и поддержки растет многократно.

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

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

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

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

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

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

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

• код - в котором задаются параметры расчета
• группа1 - которая содержит коды
• группа2 - которая также содержит коды

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

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

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

====================
4.
групповая разработка и мс-подход с Code owning, которого нет ни у заказчиков, ни у партнеров.
именно про Code owning писал Столлман в своем труде "Собор и Базар".
Code Owning очень сильно влияет на все, что разрабатывается внутри МС. прежде всего как системообразующий фактор, критерие-задающий фактор.

сообщество программистов вне МС пошло несколько другим путем - "форки можно и нужно создавать. форки создавать легко, не бойтесь создавать форки".
в сообществе программистов Code owner не может повлиять на форки административными методами. А при Сode owning - может.
Естественно, что самое легкое для owner'а - запретить трогать мой код. Поэтому при Code owning нужно затратить усилия, чтобы убедить owner'а.

Это не хорошо и не плохо. Это просто абсолютно другой подход.
С одной стороны, Code owning цементирует продукт.
С другой стороны, модули-дубли типа Основных средств, Расчет ЗП, Retail, WMS/WHS и прочий дубль-функционал появился именно как своеобразный форк в ответ на Code owning.

====================
и так далее.
каждый такой выбор в итоге дает спектр.

так уж получается, что сейчас "критерии лучшести" у разработчиков внутри МС сильно отличаются от "критериев лучшести", которые приняты у разработчиков партнеров и заказчиков.

возможно, различие - это побочный результат digital transformation.
хочется верить, что это различие проявилось в результате управляемого процесса.

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

[mazzy]

Вопрос: "зачем так сложно?"
Ответ: "Возможно, сложность - это естественная стадия развития энтропии."
Время и энтропия. Серия #3: Откуда берётся сложность?

[ax_mct]

Цитата:

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

нет, конечно. какие нафиг "отношения"?

разницу вносят очень технические моменты.

mazzy, спасибо за обстоятельный ответ. Особенно четко про Сode owning, форки и цементирование.

Все же думаю что есть пропасть между разными программистами Аксапты по отношению к оver-engineering вообще и в частности.

Одни приветствуют некий прогресс системы, а другие наоборот уверены что все эти технические изменения вредны. Лично я думаю что все эти "технические моменты" Microsoft сами по себе оver-engineering для того достаточно законченного продукта какой была Аксапта. На уровне самого наличия таких задач по изменению технической платформы до внесения чужеродного стиля и кода в X++.

Если сейчас брать не AX2012 (AX7 это слишком очевидный оverengineering),
а Аксапту 3.0 для внедрений как техническую платформу,
при условии того что в этой Axapta 3.0 тот же функционал как и в AX2012,
но при этом усилия были (пере)направлены на качество этого кода в рамках Axapta Best Practices
и продуманность функционала. Понятно что при этом какие binary фиксы но по сути на той технологической платформе.
То я совсем не уверен что будет хуже.

Любая привнесенная сложность которая не упрощает - оverengineering.
Что на уровне задач, что на уровне кода.

Более того ересь скажу. Атрибуты, делегаты, наследование интерфейсов и прочее подобное - суть есть оverengineering. Часто XML формат - оverengineering. Помогли? Облегчили что-то? Упростили? Сделали надежней или эффективней? Быстрее?

И я уверен что это таки мое отношение к оverengineering чувство и понимание которого у других явно другое. Понимание того что важно, а что нет.

Цитата:

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

.
...
Чем же занимается MBS последние лет 10? Чем угодно, но не введением модульности в продукт. Эпический перенос на .net, неистовый рефакторинг базы данных, революционными нововведениями x++. И при этом чем дальше тем сильнее приложение сплавляется в неразделимый клубок.
...

[macklakov]

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

Цитата:

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

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

Вот здесь программизм во всей красе расцветает. И в этом состоит "убийство AX". Вся идеология MorphX была в том, чтобы сделать предельно простой механизм для быстрого "допиливания" системы под нужды конкретной бизнес-практики. Ибо мир большой, везде разное законодательство, везде разные обычаи и они быстро меняются. Все предусмотреть невозможно. Более того, бизнес это война. Каждая компания пытается придумать инновацию, т.е. уникальный прием, который позволит обскакать конкурентов. Именно за это AX ценилась. Она позволяла довольно быстро и сравнительно дешево "допилить" бизнес-логику под конкретный бизнес. Да, механника была далека от идеала и создавала кучу технологических сложностей. И не так просто и легко было кастомизировать. Все равно были постоянные жалобы на недостаточную гибкость ситемы, которые пытались отмести лозунгом:"нельзя автоматизировать хаос" Но гораздо легче чем конкурентных продуктах.
И вот этого козыря AX уже почти лишили.
Эти постоянные попытки систематизировать бизнес-процессы, выстроить их в логические иерархии наследования. Сделать универсальный механизм, покрывающий все возможные бизнсе-сценарии. Это все симптомы аутизма. Иррациональное желание все систематизировать и разложить по полочкам, выстроить в единую логическую систему. Но этой единой логики нет! Есть огромное разнообразие законодательств, отраслевых договоренностей, сложившихся практик, видов контрактов. Если все свалить в одну кучу, то получается хаотическое нагромождение. Получается нечитаемая база данных. Получается нечитаемый код. Получается приложение, которое не подходит никому и при этом не дающее подстроться.
Эдакие универсальные кирзачи среднестатистического размера. Они всем или слишком большие или слишком маленькие, или слишком узкие или слишком широкие.

[trud]

Че-то мне кажется все гораздо проще - т.е. в разработку продукта приходят люди которые хотят показаться нужными и придумывают как-бы все переделать чтобы оказаться нужными
- АХ3.0 - карточка сотрудника - все поля(имя, телефон) в карточке (EmplTable), все круто, работают все фильтры, поиски, система насколько крута и удобна что продается Microsoft
- В АХ2012 - все говорят что это плохо, тормозит, много полей, вообще так никто базы не проектирует и все нафиг денормализуют(попутно удаляют и EmplTable, херя все возможности фильтрации и прочее)
- AX7 ранняя команда - понимают что с новой схемой никто работать не может, данные не загрузить, делают DataEntity где поля в одной строке
- D365 более поздняя команда - убеждают что текущий подход это полная ерунда, в дата енти куча ограничений и вообще дигитал трансформашн и делают новую базу
CDM, где все поля тупо в карточке сотрудника
-Попутно я так понял идут разговоры что вообще эта АХ очень сложна, язык какой-то странный, все тормозит, данные в интерфейсе разбросаны по разным формам, пользователи недовольны, поэтому начинается переписывание части функций на С# используя базу CDM. (это можно кстати уже посмотреть в работе подписавшись Dynamics 365 for Talent technical preview - пока напоминает больше студенческую лабу, но уже продают вовсю)

[Pustik]

Цитата:

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

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

Цитата:

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

Инженер-разработчик Dynamics Ax / Software Engineer, Dynamics Ax

Наши масштабы и задачи:
В связи с расширением московского R&D центра, отвечающего за Dynamics AX (Axapta) в Европе и России, а также открытием новых проектов по разработке и локализации вертикальных решений компания Microsoft набирает инженеров-разработчиков для участия в выпусках одной из крупнейших мировых ERP систем.
Наши требования к соискателям:
Из обязательного:
• Высшее техническое образование
• Знания методологий структурного и объектно-ориентированного программирования, умение их использовать на практике
• Знание основ реляционных БД
• Знание одного из высокоуровневых языков программирования (C#, Си, Паскаль, Java)
• Технический английский (хороший письменный, приемлемый устный)
Из желательного:
• Все то же самое, но на очень хорошем уровне
• Опыт работы с Dynamics AX; знание языка X++ и среды разработки MorphX
• Опыт работы c ERP, бухгалтерскими, финансовыми и торговыми системами
• Знание бухгалтерского, управленческого учета, логистики
• Опыт тестирования ПО
• Опыт работы с Visual Studio .Net & C#
В настоящий момент открыто несколько вакансий по данному направлению. Мы рассматриваем как начинающих разработчиков, так и сильных кандидатов со значительным опытом работы

Более подробно описано здесь:
https://careers.microsoft.com/jobdet...jlang=en&pp=ss
Регистрируйтесь через сайт (предпочтительная опция)
либо посылайте свое резюме на e-mail filatovm@microsoft.com

Да, мне тоже так кажется. Набрали людей (сишарпистов,джавистов), которые просто не имели опыта разработки в AX или еще хуже вообще не имели представления что такое Axapta до прихода на новую работу. Зато, наверное, имели диплом с отличием и ,может быть, опыт "высокоуровнего программирования" на разных языках типа C++, C#, Java, обратите внимание Паскаль .

Инженер-разработчик Dynamics AX в Microsoft R&D Center в Москве

[mazzy]

Цитата:

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

Все же думаю что есть пропасть между разными программистами Аксапты по отношению к оver-engineering вообще и в частности.

это те же самые программисты.
просто поставлены в другие условия. поэтому и критерии лучшести у них другие.

Цитата:

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

То я совсем не уверен что будет хуже.

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

Цитата:

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

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

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

Цитата:

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

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

да. это была эпоха, когда Стив Балмер прыгал по сцене и кричал: Developers! Developers! Developers!

Сейчас продукты предназначены не для разработчиков.
И это не только аксапта.
И это не только МС.
Это общий тренд.

Цитата:

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

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

Не, не, не, не!
Если бы попытки систематизировать бизнес-процессы... Это ж знать заказчика надо... Это ж надо концентрироваться на определенном сегменте. В то время, как планы продаж растут...

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

Цитата:

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

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

Ну, не.
Нет такого. И не было раньше. И даже при Дамгаарде такого не было.

Цитата:

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

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

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

Да, валить все в одну кучу не надо.
Но и делать отдельные реализации, отличающиеся с точностью до названия, тоже фигово.

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

Оказывается, это паттерн:
1. на основании исходных проводок собрать данные в отдельную таблицу
2. дать возможность пользователю внести ручные правки в эту таблицу (да, включая вставку новых записей и включая удаление)
3. дать возможность пользователю утвердить
4. дать возможность напечатать/отослать утвержденное пользователем
5. дать возможность вносить коррекции/доп.листы в утвержденное

прежде всего, такой паттерн для withholding tax. и многих других данных в гос.органы.
реализации внутри аксапты отличаются только названиями (например, withholding tax или форма 1080), реализации отличаются валютами и курсовыми, некоторые реализации запрещают изменение исходных данных после утверждения, некоторые реализации пытаются интеллектуально построить корректировочную отчетность.

Цитата:

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

Эдакие универсальные кирзачи среднестатистического размера. Они всем или слишком большие или слишком маленькие, или слишком узкие или слишком широкие.

и портянки!

Цитата:

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

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

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

Просто в условиях Code Owning транзакционные издержки проще снизить, тупо выделив себе отдельную область. Тогда можно не заниматься "непродуктивными" переговорами с Owner'ом, а просто сделать "как правильно". При этом, как Owner в этой области, ты можешь без объяснения причин просто послать каких-то странных людей, которые просят от тебя что-то незапланированного.

Простой критерий: снижение издержек и повышение продуктивности разработчика внутри данной команды. )
Остальное не учитывается.

Цитата:

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

- АХ3.0 - карточка сотрудника - все поля(имя, телефон) в карточке (EmplTable), все круто, работают все фильтры, поиски, система насколько крута и удобна что продается Microsoft
- В АХ2012 - все говорят что это плохо, тормозит, много полей, вообще так никто базы не проектирует и все нафиг денормализуют(попутно удаляют и EmplTable, херя все возможности фильтрации и прочее)
- AX7 ранняя команда - понимают что с новой схемой никто работать не может, данные не загрузить, делают DataEntity где поля в одной строке
- D365 более поздняя команда - убеждают что текущий подход это полная ерунда, в дата енти куча ограничений и вообще дигитал трансформашн и делают новую базу
CDM, где все поля тупо в карточке сотрудника
-Попутно я так понял идут разговоры что вообще эта АХ очень сложна, язык какой-то странный, все тормозит, данные в интерфейсе разбросаны по разным формам, пользователи недовольны

Кстати, хороший пример.
карточка сотрудника - считали что универсальные контакты (DirParty) позволит легче создавать разные продукты, которые совместно используют контакную информацию. Это было до того, как осознали проблему утечки персональной информации. Потребности пользователей вообще в расчет не принимались - ну, сделаем же необходимые инструменты.
DataEntity - позволит легче создавать разные продукты, которые совместно используют общую информацию. Потребности пользователей в расчет не принимались - ну, сделаем же необходимые инструменты для пользователей.
CDM - позволит легче создавать разные продукты, которые совместно используют общую информацию. Но механизмы чуток другие... Потребности пользователей?... Кто здесь?!!

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

Цитата:

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

поэтому начинается переписывание части функций на С# используя базу CDM. (это можно кстати уже посмотреть в работе подписавшись Dynamics 365 for Talent technical preview - пока напоминает больше студенческую лабу, но уже продают вовсю)

да, начинается переписывание на C#
да, студенческую лабу
да, уже продают.

но не потому что аксапта такая.
это общая попытка перейти от монолита к микросервисам. и не только в Аксапте. и не только в МС.

такой переход выполнялся многими. Тема перехода от монолита к микросервисам отрефлексирована и отхоливарена программистским сообществом по самое небалуйся.

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

[fed]

Цитата:

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

но не потому что аксапта такая.
это общая попытка перейти от монолита к микросервисам. и не только в Аксапте. и не только в МС.

такой переход выполнялся многими. Тема перехода от монолита к микросервисам отрефлексирована и отхоливарена программистским сообществом по самое небалуйся.

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

Есть такая классическая притча про стратегию, нежно любимая всеми кто проработал в Микрософте 10+ лет (Я так долго в MS не работал, конечно, мне ее в фейсбучную ленту занесло лайками старших товарищей):
"Один из лучших стрелков из лука в Японии однажды проходил, через одну деревню. И увидел, что кто-то стрелял из лука в мишень, и все стрелы попадали точно в цель. Рассматривая результаты стрельбы неизвестного стрелка, лучший мастер понял, что он не лучший. Достав меч для харакири, он хотел покончить с собой. Но местные жители, сказали, что это стрелял местный дурачок. Он сначала стреляет, а потом вокруг стрел рисует цель".

[trud]

Все же для меня загадка, чем вообще можно руководствоваться, чтобы имея такие системы(в плане скорости разработки) как AX и CRM начать разрабатывать новый app для найма с чистого листа на C# и React.
ну т.е. и AX и CRM поддерживают модули, почему бы это не сделать одним из них. кстати сделал простое сравнение формы параметров в текущей версии Talent(параметр всего 1 и тот пока не работает) и первой ссылки из гугла Hiring online app.
Очень много работы

[ALES]

Генералы боятся "упустить модный тренд" и осваивают бюджет
Бойцы амбициозны, разбираются в технологиях и ничего "на собственной шкуре" не знают о "реалиях" использования системы (или слишком хорошо о них знают )
Сложность повышает бюджеты и генерит "движуху" для всех звеньев "пищевой цепочки" внедрений но нельзя бесконечно издеваться над "заказчиком" и рано или поздно "рычаг лицензий" не удержит от альтернативных путей

[ax_mct]

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[ax_mct]

Цитата:

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

Все же для меня загадка, чем вообще можно руководствоваться, чтобы имея такие системы(в плане скорости разработки) как AX и CRM начать разрабатывать новый app для найма с чистого листа на C# и React.
ну т.е. и AX и CRM поддерживают модули, почему бы это не сделать одним из них. кстати сделал простое сравнение формы параметров в текущей версии Talent(параметр всего 1 и тот пока не работает) и первой ссылки из гугла Hiring online app.
Очень много работы

Если это про Microsoft Dynamics 365 for Talent
https://www.microsoft.com/en-us/dynamics365/talent
то это большой вопрос что есть
Оver-engineering - "зачем так сложно?"
если делать это как модуль AX или CRM.

Для меня стремление сделать это таким "модулем" и есть проявление overengineering и программизма. С чистого листа это тоже явный программизм но таки меньший.С учетом того что имеем - разумное решение. Меньшее зло.

[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 как проявление дурной болезни.

[belugin]

Цитата:

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

Более того если увижу 2000 строк в одном месте - ругаться не буду. Да, это under-engineering но на практике это может быть и дешевле чем оver-engineering когда этот код разбит на пол-сотни классов обслуживающих не бизнес-логику, а междусобойчик паттернов кодирования.

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

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

[belugin]

Цитата:

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

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

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

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

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