AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.06.2017, 15:07   #1  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,739 / 571 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Оver-engineering - "зачем так сложно?"
Цитата:
Сообщение от macklakov Посмотреть сообщение
Некоторые места в коде overengineered настолько, что смысл происходящего начинает ускользать. И наименования объектов лишь добавляют мистики.
Цитата:
Сообщение от ta_and Посмотреть сообщение
зубная боль...
зачем?..............
Цитата:
Сообщение от skuull Посмотреть сообщение
Паттерны из GoF и подобная литература решает конкретную задачу в программировании и очень жалко что по историческим причинам в АХ попадают люди предпочитающие методы по 2000 строк потому что "все в 1 месте, так удобней" и отрицающие все что "не как в 4ке".
Тема очевидна и болезненна. Началась в частности с темы AX2012. Цель атрибутов в расширении наследования классов
но прорывается то там здесь криками душами и раздражением которые наверное можно коротко как "зачем?" "зачем так сложно?".

При этом очевидно что здесь мы делимся как минимум на два лагеря.
Старый 14.06.2017, 15:16   #2  
online
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,778 / 3649 (179) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
не, не делимся на два.
или распределяемся по спектру, согласно критериям лучшести )))

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

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

Но как бы то ни было, получаются решения типа советских панельных домов.
Которые получались неудобными для жилья, очень затратными в части отопления, дорогими в части перевозки (панелевоз всегда ездил порожняком со стройки в сторону панельного завода). Но зато сроки строительства минимальны и стоимость производства панелей минимальна за счет массового производства, а удобство-отопление-перевозки не включались расчет при оптимизации.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 14.06.2017, 23:03   #3  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,739 / 571 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от mazzy Посмотреть сообщение
не, не делимся на два.
или распределяемся по спектру, согласно критериям лучшести )))
В принципе данная тема пересекается с темой ну или вот еще пример "правильной" архитектуры. т.е. сейчас чтобы создать диалог с кнопкой выбрать файл надо написать 60 строк кода. И здесь и там по сути о подходе к программированию. Но если там заговорить о "критериях лучшести" то mazzy уверен скажет что "философия" - это оффтоп.

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

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

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

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

При этом конечно могут быть и ситуации когда overengineering в коде возникает не при обслуживании маньячества самого программиста, а при реализации overengineered бизнес-логики. Когда постановщик задачи - тоже матмех закончил
Цитата:
Сообщение от fed Посмотреть сообщение
Мы занимаемся автоматизацией бизнес процессов. Заметная часть участников этих самых бизнес процессов - люди весьма среднего образования и интеллекта. Поэтому все слишком сложно спроектированные бизнес-процессы, с течением времени либо упрощаются либо умирают.
Поэтому для меня использование в X++ коде слишком большого числа паттернов говорит о том что бизнес-проблема изначально неправильно сформулирована.
Старый 15.06.2017, 00:21   #4  
online
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,778 / 3649 (179) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от 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.
посмотрим.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.

Последний раз редактировалось mazzy; 15.06.2017 в 01:11.
За это сообщение автора поблагодарили: Ace of Database (5), S.Kuskov (5).
Старый 15.06.2017, 01:39   #5  
online
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,778 / 3649 (179) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Вопрос: "зачем так сложно?"
Ответ: "Возможно, сложность - это естественная стадия развития энтропии."
Время и энтропия. Серия #3: Откуда берётся сложность?

__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.

Последний раз редактировалось mazzy; 15.06.2017 в 01:41.
Старый 15.06.2017, 02:16   #6  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,739 / 571 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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++. И при этом чем дальше тем сильнее приложение сплавляется в неразделимый клубок.
...
Старый 15.06.2017, 04:37   #7  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 876 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
По мне, проблема в том, что навороченные паттерны применяются к бизнес-логике, которая, как уже говорилось, не может быть сложной. Она может быть очень разнообразной, но не сложной. В это же время, ядро, где дизайнерски и архитектурные патерны более чем применимы, все еще страдает наследием 90-х.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Зачастую можно сделать более общую реализацию, которая не только покрывает все придуманные пользовательские сценарии, но и открывает массу новых возможностей по использованию.
Но эти открытые возможности надо описывать, надо покрывать тестами и заниматься прочим геморроем. Поэтому самой простой для разработчиков МС выход - не расширять пользовательские сценарии.
Вот здесь программизм во всей красе расцветает. И в этом состоит "убийство AX". Вся идеология MorphX была в том, чтобы сделать предельно простой механизм для быстрого "допиливания" системы под нужды конкретной бизнес-практики. Ибо мир большой, везде разное законодательство, везде разные обычаи и они быстро меняются. Все предусмотреть невозможно. Более того, бизнес это война. Каждая компания пытается придумать инновацию, т.е. уникальный прием, который позволит обскакать конкурентов. Именно за это AX ценилась. Она позволяла довольно быстро и сравнительно дешево "допилить" бизнес-логику под конкретный бизнес. Да, механника была далека от идеала и создавала кучу технологических сложностей. И не так просто и легко было кастомизировать. Все равно были постоянные жалобы на недостаточную гибкость ситемы, которые пытались отмести лозунгом:"нельзя автоматизировать хаос" Но гораздо легче чем конкурентных продуктах.
И вот этого козыря AX уже почти лишили.
Эти постоянные попытки систематизировать бизнес-процессы, выстроить их в логические иерархии наследования. Сделать универсальный механизм, покрывающий все возможные бизнсе-сценарии. Это все симптомы аутизма. Иррациональное желание все систематизировать и разложить по полочкам, выстроить в единую логическую систему. Но этой единой логики нет! Есть огромное разнообразие законодательств, отраслевых договоренностей, сложившихся практик, видов контрактов. Если все свалить в одну кучу, то получается хаотическое нагромождение. Получается нечитаемая база данных. Получается нечитаемый код. Получается приложение, которое не подходит никому и при этом не дающее подстроться.
Эдакие универсальные кирзачи среднестатистического размера. Они всем или слишком большие или слишком маленькие, или слишком узкие или слишком широкие.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: olesh (1), Pustik (2), Logger (1), Stitch_MS (3), S.Kuskov (5).
Старый 15.06.2017, 04:40   #8  
trud is offline
trud
Участник
Лучший по профессии 2017
 
486 / 362 (13) ++++++
Регистрация: 07.06.2003
Че-то мне кажется все гораздо проще - т.е. в разработку продукта приходят люди которые хотят показаться нужными и придумывают как-бы все переделать чтобы оказаться нужными
- АХ3.0 - карточка сотрудника - все поля(имя, телефон) в карточке (EmplTable), все круто, работают все фильтры, поиски, система насколько крута и удобна что продается Microsoft
- В АХ2012 - все говорят что это плохо, тормозит, много полей, вообще так никто базы не проектирует и все нафиг денормализуют(попутно удаляют и EmplTable, херя все возможности фильтрации и прочее)
- AX7 ранняя команда - понимают что с новой схемой никто работать не может, данные не загрузить, делают DataEntity где поля в одной строке
- D365 более поздняя команда - убеждают что текущий подход это полная ерунда, в дата енти куча ограничений и вообще дигитал трансформашн и делают новую базу
CDM, где все поля тупо в карточке сотрудника
-Попутно я так понял идут разговоры что вообще эта АХ очень сложна, язык какой-то странный, все тормозит, данные в интерфейсе разбросаны по разным формам, пользователи недовольны, поэтому начинается переписывание части функций на С# используя базу CDM. (это можно кстати уже посмотреть в работе подписавшись Dynamics 365 for Talent technical preview - пока напоминает больше студенческую лабу, но уже продают вовсю)
Миниатюры
Нажмите на изображение для увеличения
Название: CDS.jpg
Просмотров: 48
Размер:	63.8 Кб
ID:	11502  

Последний раз редактировалось trud; 15.06.2017 в 06:11.
За это сообщение автора поблагодарили: Pustik (2), Ace of Database (5).
Старый 15.06.2017, 09:24   #9  
Pustik is offline
Pustik
Участник
 
772 / 334 (13) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от 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 в Москве
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.

Последний раз редактировалось Pustik; 15.06.2017 в 09:45.
Старый 15.06.2017, 09:26   #10  
online
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,778 / 3649 (179) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от 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#
да, студенческую лабу
да, уже продают.

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

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

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

Последний раз редактировалось mazzy; 15.06.2017 в 09:46.
За это сообщение автора поблагодарили: Pustik (2).
Старый 15.06.2017, 10:07   #11  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,181 / 4007 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mazzy Посмотреть сообщение
но не потому что аксапта такая.
это общая попытка перейти от монолита к микросервисам. и не только в Аксапте. и не только в МС.

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

Для меня все еще загадка - почему МС почти во всех вопросах считает себя первопроходцем и почему при вопросе "как сделать" не выполняется первое действие "посмотреть как сделали другие". Причем это касается и кода в Аксапте, и стратегии, и политики продаж. Либо я чего-то не понимаю.
Есть такая классическая притча про стратегию, нежно любимая всеми кто проработал в Микрософте 10+ лет (Я так долго в MS не работал, конечно, мне ее в фейсбучную ленту занесло лайками старших товарищей):
"Один из лучших стрелков из лука в Японии однажды проходил, через одну деревню. И увидел, что кто-то стрелял из лука в мишень, и все стрелы попадали точно в цель. Рассматривая результаты стрельбы неизвестного стрелка, лучший мастер понял, что он не лучший. Достав меч для харакири, он хотел покончить с собой. Но местные жители, сказали, что это стрелял местный дурачок. Он сначала стреляет, а потом вокруг стрел рисует цель".
За это сообщение автора поблагодарили: AlGol (2), AlexSD (3).
Старый 15.06.2017, 10:25   #12  
trud is offline
trud
Участник
Лучший по профессии 2017
 
486 / 362 (13) ++++++
Регистрация: 07.06.2003
Все же для меня загадка, чем вообще можно руководствоваться, чтобы имея такие системы(в плане скорости разработки) как AX и CRM начать разрабатывать новый app для найма с чистого листа на C# и React.
ну т.е. и AX и CRM поддерживают модули, почему бы это не сделать одним из них. кстати сделал простое сравнение формы параметров в текущей версии Talent(параметр всего 1 и тот пока не работает) и первой ссылки из гугла Hiring online app.
Очень много работы
Миниатюры
Нажмите на изображение для увеличения
Название: recruiterbox.jpg
Просмотров: 73
Размер:	87.4 Кб
ID:	11503  
Старый 15.06.2017, 11:37   #13  
ALES is offline
ALES
Участник
Злыдни
 
216 / 44 (2) +++
Регистрация: 11.08.2004
Генералы боятся "упустить модный тренд" и осваивают бюджет
Бойцы амбициозны, разбираются в технологиях и ничего "на собственной шкуре" не знают о "реалиях" использования системы (или слишком хорошо о них знают )
Сложность повышает бюджеты и генерит "движуху" для всех звеньев "пищевой цепочки" внедрений но нельзя бесконечно издеваться над "заказчиком" и рано или поздно "рычаг лицензий" не удержит от альтернативных путей
Старый 15.06.2017, 15:59   #14  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,739 / 571 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от macklakov Посмотреть сообщение
...программизм во всей красе расцветает. И в этом состоит "убийство AX". Вся идеология MorphX была в том, чтобы сделать предельно простой механизм для быстрого "допиливания" системы под нужды конкретной бизнес-практики....
Цитата:
Сообщение от trud Посмотреть сообщение
Че-то мне кажется все гораздо проще - т.е. в разработку продукта приходят люди которые хотят показаться нужными и придумывают как-бы все переделать чтобы оказаться нужными
Цитата:
Сообщение от mazzy Посмотреть сообщение
это те же самые программисты.
просто поставлены в другие условия. поэтому и критерии лучшести у них другие.
...
по факту большая часть кода является технической, обслуживающей.
...
Постоянные попытки внести внутренние, технологические, девелоперские изменения,
которые уменьшают трудозатраты разработчиков МС при решении задач внутри МС в окружении и с инструментарием МС.
Оverengineering - это проявление болезни программизма у 90%. Я очень сомневаюсь в том что в других условиях эти же программисты не будут страдать этой заразой. Поднявшись по служебной лестнице им и в голову не придет что перенос на .NET и переход на VS - это Оverengineering.
Если бы этой деформации реальности в мозгах технических специалистов не было - то и не случалось бы постановки таких задач и создания таких условий. Психическая Болезнь.

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

Цитата:
Сообщение от mazzy Посмотреть сообщение
мысль понятна.
но чтобы получить ответ стоит сформулировать полностью: будет хуже кому? в чем выражается хужесть?
Хуже всем. Клиенту, партнеру, вендору.
Выражается в удовлетворении (куда входит и цена-качество) и в удобстве. Для всех участников.
То есть при отсутствии ненужных изменений в технической стороне как проявления Оverengineering в сознании специалистов всех уровней
нахождение на технической платформе 3.0 (к примеру) было бы лучше для всех участников эко-системы.
Все изменения абсолютно иррациональны и ни что иное как деформация сознания на всех уровнях и отсутствия чувства оverengineering. Даже в бизнесе это понимание простоты логики критически необходимо для успеха.
Старый 15.06.2017, 16:47   #15  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,739 / 571 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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 и программизма. С чистого листа это тоже явный программизм но таки меньший.С учетом того что имеем - разумное решение. Меньшее зло.
Старый 15.06.2017, 17:39   #16  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
758 / 152 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от ax_mct Посмотреть сообщение
нахождение на технической платформе 3.0 (к примеру) было бы лучше для всех участников эко-системы.
Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.
__________________
Axapta 3.0 sp - хз какой, kr2
За это сообщение автора поблагодарили: olesh (1), Ace of Database (3).
Старый 15.06.2017, 17:54   #17  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
700 / 528 (19) +++++++
Регистрация: 14.10.2004
Цитата:
Сообщение от egorych Посмотреть сообщение
Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.
Когда МСу надоест заниматься ERP, с его стороны было бы очень красивым жестом отпустить Аксапту в свободное плавание в Open Source в том виде, в котором она была в AX2009.Да пусть даже и в том виде, как она была в AX3. Все-таки DirParty сильно напрягают, и еще самому себе делать assert в коде тоже напрягает. В АХ 3 было классно без assert'ов. Но в AX2009 пакетники лучше работают, чем в AX3.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/

Последний раз редактировалось Ace of Database; 15.06.2017 в 17:58.
Старый 15.06.2017, 18:20   #18  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,739 / 571 (23) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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 как проявление дурной болезни.

Последний раз редактировалось ax_mct; 15.06.2017 в 18:44.
Старый 15.06.2017, 21:53   #19  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,011 / 2151 (80) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Более того если увижу 2000 строк в одном месте - ругаться не буду. Да, это under-engineering но на практике это может быть и дешевле чем оver-engineering когда этот код разбит на пол-сотни классов обслуживающих не бизнес-логику, а междусобойчик паттернов кодирования.
Вполне возможно, что тут причина отчасти и в том, что у вендора, партнера и клиента разные задачи по отношению к этим 2000 строкам. Вендору надо их поддерживать все, патртнеру только те, которые использует он (у меня давнишний опыт на проектах, но я помню, например как работоспособность доработок проверялась только при наборе галочек включенных у конкретного клиента, при переключении галочек в настройках требовалась доработка модифы), а у клиента я один разок видел вообще не компилящееся приложение.

Так что для каждого отсутсвием овержнжиниринга был бы разный уровень избыточности кода.
Старый 15.06.2017, 22:01   #20  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,011 / 2151 (80) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
придет что перенос на .NET и переход на VS - это Оverengineering.
Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

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

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ModelElementData_HasModelId_LayerId". The conflict occurred in database "YourDataBaseName_model", table "dbo.Model" Blog bot DAX Blogs 0 23.05.2014 13:11
Dynamics AX Sustained Engineering: Performance issue in "Open Transaction Edit" form Blog bot DAX Blogs 0 26.10.2009 20:05
Зачем нужны "Параметры кодов аналитики"? Кирилл DAX: Программирование 2 16.04.2004 14:22
Зачем нужна "Потребность в номенклатуре" Tony Green DAX: Функционал 4 02.02.2004 00:24
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 22:52.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.