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

[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 в Москве

[trud]

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

[ALES]

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

[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 и программизма. С чистого листа это тоже явный программизм но таки меньший.С учетом того что имеем - разумное решение. Меньшее зло.

[macklakov]

Цитата:

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

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

А вот это уже очень интересно. Ради такого дела навороченный дизайн весьма оправдан.
Зачем? Чтобы развалить AX на множество взаимо-заменяемых модулей из которых можно компоновать решения.

[Ace of Database]

Правильно ли я понимаю, что чтобы решить эту задачу, надо просто скопировать имеющуюся форму в новую, и в новой форме начинать колбасить?
добавить readonly датасорс на форму, для фильтрования
Если я понимаю правильно, то это тоже подход. Тогда АХ7 еще можно переварить. Главное, наработать последовательность рутинных операций, с помощью которых можно быстро удовлетворять клиента.
Тогда АХ7 уже не такая непонятная становится. Просто внешние обработки в ней хранятся не в файлах, как в 1С, а в AOT, вперемешку со стандартными объектами.

[trud]

Цитата:

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

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

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

[Ace of Database]

Цитата:

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

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

Это все понятно. Но как клиента-то удовлетворить? Все равно надо какой-то паттерн действий придумать. Как правильно сделать?
Я обычно ищу примеры в Аксапте или в интернете и копирую их.
Судя по всему, для того, чтобы экстендить форму, надо написать кучу служебного кода. Вы что, каждый раз этот код будете вручную писать?
Я, например, когда создаю класс-наследник от RunBase копирую методы из RunBase в новый класс и правлю их. А при экстендинге придется еще больше повторяющегося служебного кода копировать.

[ax_mct]

Цитата:

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

Ритейл в акс7 построен на хранимых процедурах.
Не приведи господь.

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

Цитата:

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

Вы же сами рассуждаете о том, что способ программирования худше или лучше

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

Цитата:

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

Баааалин.
Докатились.
Теперь злостный копипаст у нас признается нормальным способом.

Злостный копипаст может быть и достаточно часто уместным.
Но это оффтоп если за/против, тут интересно то что как и с хранимыми процедурами, пришли к тому же, только уже в менее удобной форме.

Цитата:

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

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

Да какой там балаган. Это о вполне реальной нашей болезни. Жертвой который и пала Аксапта.

[belugin]

Цитата:

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

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

Что? Журналы ГК до сих пор разносятся через LedgerVoucher.

Цитата:

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

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

[Logger]

Баааалин.
Докатились.
Теперь злостный копипаст у нас признается нормальным способом.

[Pustik]

Цитата:

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

Баааалин.
Докатились.
Теперь злостный копипаст у нас признается нормальным способом.

Люди, никогда не признаю правильной стратегию копипастить. Честно , зло берет.

[ax_mct]

Цитата:

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

Люди, никогда не признаю правильной стратегию копипастить. Честно , зло берет.

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

Если есть нетронутая SYS форма и твои изменения существенны то сдублировать ее - на мой взгляд разумно.
Так же при перегрузке методов - иногда здравый смысл говорит что лучше менять копию если это упростит жизнь тебе и программисту после тебя.
Часто соображения безопасности твоего решения - чем больше сбоку тем меньше претензий к тебе как к подрядчику. Как бы это не противоречило Искусству.

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

[Pustik]

Цитата:

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

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

Если есть нетронутая SYS форма и твои изменения существенны то сдублировать ее - на мой взгляд разумно.

согласен, вообще с многим с вами солидарен, о чем вы говорите.

[trud]

Сделать как раньше, кастомизацией - закроют то только через год, да и то это только в планах
опционально написать о проблеме в микрософт

[Ace of Database]

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

[ax_mct]

Есть White Paper
Using the refactored formletter framework
Date: May 2011
Author: Kenneth Puggaard, Senior Development Lead
http://go.microsoft.com/fwlink/?LinkID=218315

Обоснование
Because the FormLetter classes had so much functionality and no well-defined APIs in Microsoft
Dynamics AX 2009, they were complex for developers to understand and customize.

In Microsoft Dynamics AX 2012, the formletter framework has been refactored to clearly separate the
functionality needed for the posting process into different classes. This has led to a number of new
class hierarchies.

The Microsoft Dynamics AX 2009 base FormLetter class has been split into eight base classes. It also
has been changed to run under the SysOperation framework. Switching to the SysOperation
framework has the advantage of executing the code on the server tier during posting in IL
(intermediate language). Because of the switch to using the SysOperation framework, client callbacks
from code running on the server tier are no longer supported. Client callbacks result in an exception.

Вот сколько старый FormLetter существовал лет? Лет 10 все значит мучились.

Отчасти это редизайн из-за смены Runbase/RunBaseBatch на SysOperation framework.
https://msdn.microsoft.com/en-us/library/gg862488.aspx

SysOperation framework реализует MVC pattern. The isolation of the parameters (model), the dialog (view) and the code that runs (controller) is the essence of the pattern.

Model:
• Member variables
• Pack/unpack (aka serialization)

View:
• Dialog()
• GetFromDialog()
• PutToDialog()

Controller:
• Prompt()
• Run()

Ничего не имею против MVC вообще, но ЗАЧЕМ менять один код на такой же другой, я понять не могу.
Код - такой же. Его просто разбили на пазл паттерном.
Интерпретатору/компилятору - все равно, он все равно соберет все лоскутки в "простыню".
Пользователю - все равно.
Функциональности - все равно.
Программисту? Старым, после многих лет работы с этими классами - сплошная радость. Новым, быть они хоть трижды Java программистами - легче и проще это не делает. А типичные на клиенте - вообще не в состоянии понять.
Зато да, вот оно современное программирование какое

[skuull]

Цитата:

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

Есть White Paper
Using the refactored formletter framework
Date: May 2011
Author: Kenneth Puggaard, Senior Development Lead
http://go.microsoft.com/fwlink/?LinkID=218315

Это не тот о котором я говорил, перед тем как сделать фичу ее надо продать даже внутри МС. Вот кто-то и написал документ как плох текущий фреймворк и как хорошо он его переделает за n часов. Найти его можно было на внутреннем шарепоинте по словам formletter и refactoring/redisign.

[mazzy]

Цитата:

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

Это не тот о котором я говорил, перед тем как сделать фичу ее надо продать даже внутри МС. Вот кто-то и написал документ как плох текущий фреймворк и как хорошо он его переделает за n часов. Найти его можно было на внутреннем шарепоинте по словам formletter и refactoring/redisign.

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

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

Цитата:

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

Есть внутренний документик в МС в котором написано: зачем, что плохо в старом, как новое хорошо и т.д. и т.п. В основном производительность и дублирование кода.

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

типа попытались реализовать концепцию "одно семейство - одна задача".

спасибо. надо подумать.

[skuull]

Цитата:

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

Программисту? Старым, после многих лет работы с этими классами - сплошная радость. Новым, быть они хоть трижды Java программистами - легче и проще это не делает. А типичные на клиенте - вообще не в состоянии понять.

Спорное утверждение, глядя лишь на название классов(*Create, *Post, *Print) уже понятно что они делают и где нужно дописать свой код.
Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось