|
18.06.2017, 14:55 | #1 |
Участник
|
Цитата:
Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
18.06.2017, 15:06 | #2 |
Участник
|
Цитата:
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители. тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных... а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию... Мне кажется, что проблема все-таки в отсутствии механизма, который позволяет рефакторить существующий код. а различия в критериях-подходах дают убийственную смесь. Последний раз редактировалось mazzy; 18.06.2017 в 15:48. |
|
19.06.2017, 05:57 | #3 |
Участник
|
Цитата:
*Handler - это действительно непонятно. *Helper, *Util - лучше класть в тот класс, в котором, собственно, предмет обработки, но если класс чужой а твои методы для него очень специфичны либо это не класс, а интерфейс, то чем плохо положить в *Util? Только надо выбрать один из этьи суффиксов, что в MS не сделано, к сожалению. Цитата:
тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных...
Цитата:
а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...
В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation теперь есть API - то есть если надо его встроить в свой процесс, можно взять и вызвать метод, заполнив контракт, а не вытягивать наружу параметры модифицируя существующий класс |
|
|
За это сообщение автора поблагодарили: mazzy (2), ta_and (4). |
19.06.2017, 10:44 | #4 |
Участник
|
Цитата:
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности. в результате у разработчика не один "плохой" набор RunBase а два совершенно разных. в результате нужно не только знать оба, но и знать как заставить их работать совместно. с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась. а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности. и так во многих местах аксапты за редким исключением типа (subledger, dimension). вводятся новые инструменты-фреймворки. пусть они все замечательные. но старые то не выводятся. |
|
19.06.2017, 13:00 | #5 |
Участник
|
Цитата:
Цитата:
в результате у разработчика не один "плохой" набор RunBase
а два совершенно разных. в результате нужно не только знать оба, но и знать как заставить их работать совместно. В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе: - Как использовать бизнеслогику одного из другого надо разбираться с каждым классом (у SysOP есть API который называется стандартно и представляет просто метод с параметром) - UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог) - Только pack можно использовать из другого pack (с runbase надо разбираться - они паковку не вынесли отдельно) Цитата:
с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности. Цитата:
и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные. но старые то не выводятся. |
|
19.06.2017, 13:41 | #6 |
Участник
|
1. не надо демагогии и слова ВСЕ ))) речь идет о SysOperation, которая должна заменить RunBase.
2. "Реально никто [в МС] не заморачивается" - это и есть причина Оver-engineering с точки зрения остальных разработчиков. Тут, наверное, мне стоит объяснить остальным участникам, что фраза Макса "не заморачивается [API]" вовсе не говорит о том, что разработчики в МС не заморачиваются ничем. В МС самая замороченная процедура приемки кода изо всех что я видел. Поэтому заморачиваться разработчику в МС приходится очень много чем. Просто критерии важности в МС сильно отличаются от критериев важности на проектах заказчиков и партнеров. Следовательно заморачиваются в МС очень другими вещами, чем на проектах (собственно об этом я и говорил выше). Цитата:
пример - хелперы в процедуре закрытия склада. Цитата:
Цитата:
можно я не буду дальше комментировать? собственно одно - просто критерии другие. другие выводы. уверен, что поставь любого разработчика (включая и меня) в условия, в которых живет Макс, дай задачи, которые решает Макс, и система критериев будет такой же. Цитата:
но для определенности, можешь привести пример? Ой, все! вот только не надо как 1Сники валить на другую систему. Типа "у нас гавно, а вот там еще хуже". фиг с ними, с сапами, давай в своей системе разбираться/прибираться. |
|
18.06.2017, 16:27 | #7 |
Moderator
|
Цитата:
наступит ясность почему именно "не сложилось". Вообще - автоматизированное тестирование окупает себя только на тиражируемом софте. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно. Только вот я пока не видел вертикальных решений аксаптовских с таким количеством клиентов (гм - может быть у add-ons типа Bartender или Formpipe Lasertnet есть такое количество клиентов). По крайней мере на обычных внедренческих проектах, с разработкой под конкретного клиента, разработка тест-скриптов не окупается. |
|
|
За это сообщение автора поблагодарили: Vadik (1), Ace of Database (3), trud (2), macklakov (5). |
18.06.2017, 17:15 | #8 |
Модератор
|
Цитата:
Цитата:
А ты попробуй продать реальному клиенту идею авоматизированного тестирования
__________________
-ТСЯ или -ТЬСЯ ? |
|
18.06.2017, 18:10 | #9 |
Banned
|
Цитата:
количество багов и последующих hotfixes стало меньше? Так сказать экономический эффект интересен. Мне почему-то не кажется что в AX2012 или Operations стало меньше hotfixes по сравнению с к примеру 3.0. По моему как пользователи работали beta-тестерами так и работают. Поправьте меня, так как не могу сейчас с цифрами в руках. У меня только субьективное впечатление от то здесь то там прочитанных KB и CU. |
|
18.06.2017, 21:02 | #10 |
Модератор
|
Цитата:
Цитата:
Так сказать экономический эффект интересен
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
19.06.2017, 04:57 | #11 |
NavAx
|
Цитата:
Сообщение от Vadik
Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили
Но, есть другой немаловажный момент. Данные! Вот уж что порублено на фарш, та это данные. В результате "программизма", размер таблиц стал чудовищным. При этом несмотря на невероятные усилия по оптимизации, включая переписывание кусков на хранимках, все равно есть места где откровенно подтормаживает. Но главное даже не в этом. Главное что данные нечитаемые. А это приводит к жутким проблемам с BI. Жутким проблемам с миграцией. Жутким проблемам с нарушением целостности. В результате применения таких "правильных и прогрессивных" паттернов и нормализации, AX превратилась в систему, у которой очень большие проблемы с построением отчетности.
__________________
Isn't it nice when things just work? |
|
18.06.2017, 22:44 | #12 |
Участник
|
Цитата:
Я вообще-то писал про умение не только писать тесты но и код который легко можно покрыть тестами, так вот второе не требует дополнительных затрат и автоматически исключает методы "бога" по 2000 строк как нетестируемые. Последний раз редактировалось skuull; 18.06.2017 в 22:47. |
|
18.06.2017, 23:30 | #13 |
Banned
|
Цитата:
Сообщение от Vadik
Для 1611 на сегодня - чуть менее 600 X++ хотфиксов.
... В D365O если разработка по уму организована - это в большинстве случаев.. ... Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы Цитата:
так как это может приводить к - можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O) - легче покрыть автоматическими тестами Корректно выдернул из контекста? |
|
19.06.2017, 09:34 | #14 |
Участник
|
Цитата:
Я сейчас наверно повторю сказанное ранее, но разбиение 1 класса на 3 есть усложнение для тех кто не понимает MVC и облегчение для тех кто понимает. Плюсы тут уже перечислили. Как по мне, FormLetter стал легче для понимания и использования, а вот Subledger нет. |
|
19.06.2017, 06:05 | #15 |
Участник
|
Цитата:
Если есть отдельный кусок, который часто модифицируется, и для которого просто построить тестовое окружение, то его разумно протестировать автоматически. Если у нас типичные задачи аксаптовского внедрения, состоящие в небольших допилах готовых объектов приложения, на которые нам MS не дал готовых тестах это гипертрудоемко. Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем. Это был одноразовый pinning test. А еще тесты надо уметь готовить, а то получается дополнительная боль |
|
19.06.2017, 07:20 | #16 |
Участник
|
Цитата:
Сообщение от belugin
Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test. А еще тесты надо уметь готовить, а то получается дополнительная боль Если вы не про Селениум, конечно.
__________________
// no comments Последний раз редактировалось dech; 19.06.2017 в 07:25. |
|
19.06.2017, 07:52 | #17 |
Участник
|
|
|
Теги |
sysoperation framework |
|
|