|
18.06.2017, 15:06 | #1 |
Участник
|
Цитата:
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители. тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных... а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию... Мне кажется, что проблема все-таки в отсутствии механизма, который позволяет рефакторить существующий код. а различия в критериях-подходах дают убийственную смесь. Последний раз редактировалось mazzy; 18.06.2017 в 15:48. |
|
19.06.2017, 05:57 | #2 |
Участник
|
Цитата:
*Handler - это действительно непонятно. *Helper, *Util - лучше класть в тот класс, в котором, собственно, предмет обработки, но если класс чужой а твои методы для него очень специфичны либо это не класс, а интерфейс, то чем плохо положить в *Util? Только надо выбрать один из этьи суффиксов, что в MS не сделано, к сожалению. Цитата:
тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных...
Цитата:
а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...
В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation теперь есть API - то есть если надо его встроить в свой процесс, можно взять и вызвать метод, заполнив контракт, а не вытягивать наружу параметры модифицируя существующий класс |
|
|
За это сообщение автора поблагодарили: mazzy (2), ta_and (4). |
19.06.2017, 10:44 | #3 |
Участник
|
Цитата:
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности. в результате у разработчика не один "плохой" набор RunBase а два совершенно разных. в результате нужно не только знать оба, но и знать как заставить их работать совместно. с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась. а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности. и так во многих местах аксапты за редким исключением типа (subledger, dimension). вводятся новые инструменты-фреймворки. пусть они все замечательные. но старые то не выводятся. |
|
18.06.2017, 16:27 | #4 |
Moderator
|
Цитата:
наступит ясность почему именно "не сложилось". Вообще - автоматизированное тестирование окупает себя только на тиражируемом софте. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно. Только вот я пока не видел вертикальных решений аксаптовских с таким количеством клиентов (гм - может быть у add-ons типа Bartender или Formpipe Lasertnet есть такое количество клиентов). По крайней мере на обычных внедренческих проектах, с разработкой под конкретного клиента, разработка тест-скриптов не окупается. |
|
|
За это сообщение автора поблагодарили: Vadik (1), Ace of Database (3), trud (2), macklakov (5). |
18.06.2017, 17:15 | #5 |
Модератор
|
Цитата:
Цитата:
А ты попробуй продать реальному клиенту идею авоматизированного тестирования
__________________
-ТСЯ или -ТЬСЯ ? |
|
18.06.2017, 18:10 | #6 |
Banned
|
Цитата:
количество багов и последующих hotfixes стало меньше? Так сказать экономический эффект интересен. Мне почему-то не кажется что в AX2012 или Operations стало меньше hotfixes по сравнению с к примеру 3.0. По моему как пользователи работали beta-тестерами так и работают. Поправьте меня, так как не могу сейчас с цифрами в руках. У меня только субьективное впечатление от то здесь то там прочитанных KB и CU. |
|
18.06.2017, 22:44 | #7 |
Участник
|
Цитата:
Я вообще-то писал про умение не только писать тесты но и код который легко можно покрыть тестами, так вот второе не требует дополнительных затрат и автоматически исключает методы "бога" по 2000 строк как нетестируемые. Последний раз редактировалось skuull; 18.06.2017 в 22:47. |
|
18.06.2017, 23:30 | #8 |
Banned
|
Цитата:
Сообщение от Vadik
Для 1611 на сегодня - чуть менее 600 X++ хотфиксов.
... В D365O если разработка по уму организована - это в большинстве случаев.. ... Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы Цитата:
так как это может приводить к - можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O) - легче покрыть автоматическими тестами Корректно выдернул из контекста? |
|
19.06.2017, 06:05 | #9 |
Участник
|
Цитата:
Если есть отдельный кусок, который часто модифицируется, и для которого просто построить тестовое окружение, то его разумно протестировать автоматически. Если у нас типичные задачи аксаптовского внедрения, состоящие в небольших допилах готовых объектов приложения, на которые нам MS не дал готовых тестах это гипертрудоемко. Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем. Это был одноразовый pinning test. А еще тесты надо уметь готовить, а то получается дополнительная боль |
|
19.06.2017, 07:20 | #10 |
Участник
|
Цитата:
Сообщение от belugin
Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test. А еще тесты надо уметь готовить, а то получается дополнительная боль Если вы не про Селениум, конечно.
__________________
// no comments Последний раз редактировалось dech; 19.06.2017 в 07:25. |
|
18.06.2017, 07:02 | #11 |
Moderator
|
Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions.
Во первых - из за того что там очень высокий уровень абстракции, большая часть диагностики сводиться к сообщению "У нас тут какая-то фигня". После этого приходится тратить где-нить от часа до трех времени, чтобы протрассироваться и понять - где-же именно и какую настройку консультанты неправильно сделали. Просто благодаря могучим программистским механизмам, место возникновения ошибки отделено от его причины изрядным количеством вложеных вызовов,классов-фабрик, классов сохранения состояния, классов перехода состоянияи и тд и тп. Поэтому в момент обнаружения ошибки, выдать понятную диагностику просто невозможно. Проверку параметров в унаследованный от Дамгаарда код прогрессоры добавить не догадались. Аналогично - процентов 85 эскалированных в Микрософт ошибок, приходилось на те самые замечательные распределения и сабледжер. При этом чтобы воспроизвести ошибки в стандарте и понять условия их возникновения, приходится тратить достаточно заметное время на трассированние исходного кода. При этом, как я много раз уже писал, subledgers/distributions - это вообще абсурд, не связанный с экономической реальностью. Новая аналитика и ГК - конечно полезна в определенном числе случаев, но с другой стороны - в 98% случаев и старой ГК (как в 2009) хватало. (В том числе для вполне себе крупных внедрений enterprise уровня). Наконец - хочу ввести критерий ovengineering: Это, как несложно было догадаться, отрицательный экономический эффект от изучения новой технологии. Вот я на эту борьбу с ГК и распределениями потратил, в общей сложности, порядка 4 недель жизни. Во первых - далеко не все это время было billable. Клиенты как-то не очень рвутся оплачивать то, что с их точки зрения является ошибкой (не важно - нашей в настройках, или Микрософтовской - в коде). Во вторых - эти знания мне вряд ли пригодятся для каких-то других задач, кроме собственно воспроизведения ошибок MS и поиска ошибок консов. (А это, как я уже заметил, не очень выгодные в финансовом плане и не очень интересные в профессиональном плане задачи). Я точно не буду создавать свой собственный вид source document и вряд ли я буду переписывать разноску в ГК. Так что для меня изучение нового замечательного, богатого на новые программистские технологии модуля дало в целом негативный экономический эффект. Я потратил изрядное время на получение знаний сомнительной полезности и применимости. То есть - конечно если за стажерскую зарплату сидеть и тихонечко разбираться в новых технологиях, то можно не думать об окупаемости этого процесса. Но вот если ты фрилансер, или если ты ключевой сотрудник партнера (и твоя зарплата подпирает сумму выручки), то критерии эффективности очень даже актуальными становятся. |
|
|
За это сообщение автора поблагодарили: Raven Melancholic (2), mazzy (2), ax_mct (3), ta_and (3), mau (1), san2san (1). |
18.06.2017, 08:05 | #12 |
Модератор
|
Ну а я тогда свою копеечку добавлю с бюджетированием. Там правда скорее не over-engineering, а просто уродский дизайн. Куча логики на вызывающих друг друга хранимых процедурах на T-SQL. Часть параметров с которыми эти SP вызываются (BudgetCheckGroup) - живут в рамках сессии и даже перехватив "падающий" вызов - оттрассировать его нельзя (это свежесозданные RecId которые при ошибке откатятся с транзакцией). Зашитый в код applock, из-за которого все проверки выполняются строго последовательно. Решил ты в одной компании проверить по бюджету журнал строк так на 10000 - все приложение встало колом. Ну не прелесть ли?
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 18.06.2017 в 22:53. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
18.06.2017, 08:12 | #13 |
Участник
|
Цитата:
Изучая DAX2012 решил последовать своему же совету. Сказать, что был удивлен это упростить мою реакцию - жена много новых слов узнала. |
|
18.06.2017, 14:53 | #14 |
Участник
|
Цитата:
Сообщение от Raven Melancholic
Я раньше, когда новички обращались с просьбой подсказать где лучше посмотреть реализацию разноски в ГК данных, введенных пользователями, отсылал к текстовой накладной (накладной с произвольным текстом). Типа там все просто и понятно.
Изучая DAX2012 решил последовать своему же совету. Сказать, что был удивлен это упростить мою реакцию - жена много новых слов узнала. И у меня вопрос ЗАЧЕМ? Я пойму если объяснения будут адекватные. Типа стало быстрее, проще, ну или на худой конец все движется вперед - стоять на месте нельзя. Но только двигаться вперед можно и с учетом того , что было раньше сделано, а не по принципу "врач сказал резать, значит резать"
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
19.06.2017, 09:17 | #15 |
Moderator
|
Конечно же, 40-50 клиентов - это эспертная оценка. Вполне возможно что я малость неправ, и на самом деле - правильная цифра 25-30 (или наоборот - 50-60). Вопрос в том, что в любом случае - для одного клиента писать юнит-тесты невыгодно. Наверное уже раза 2-3 обсудили на этом форуме, что главная проблема разработки юнит-тестов в аксапте в том, что покрывать придется не только свой код, но и те места в микрософтовском коде, которые могут быть сломаны доработкой.
Если когда-нибудь микрософт опубликует свои собственные юнит-тесты,автоматизированное тестирование партнерских доработок станет выгодным и для меньшего числа клиентов (типа для 5-7). Но я очень сомневаюсь,что в случае разработки для одного клиента, автоматизированное тестирование когда-нибудь станет экономически оправданым. Всегда стоит помнить что стоимость предотвращения ошибки должна быть ниже чем стоимость исправления ее последствий. При этом в случае одного клиента, в 95% (или даже в 99%) случаев проще просто установить доработку в реальное боевое приложение и просто посмотреть что там реальные пользователи выкопают. Ну то есть - конечно консультанты и ключевые пользователи должны какие-то типовые сценарии потестить, но все равно - сложные случаи выловятся только во время боевой эксплуатации. К слову сказать - первые 5 лет моей аксаптерской карьеры, я работал с версиями 2.1-3.0, которые тестировались в ручную. Там были баги в ядре. Там было много ошибок в российской локализации.В западной бизнес-логике, я за 5 лет столкнулся не более чем с тремя ошибками. В DAX2012, которая реально внедрялась 4 года, я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS. Последний раз редактировалось fed; 19.06.2017 в 12:23. |
|
19.06.2017, 09:34 | #16 |
NavAx
|
Цитата:
Account structures работают? Работают! Default dimensions работают? Работают! Пользователь создал заказ, одобрил, скомплектовал, отгрузил, выписывает инвойс. Ошибка валидации. К кому притензии? Как в той миниатюре Райкина. К рукаву претензии есть? Нет притензий, рукав отлично пошит. Пришит рукав качественно? Да, не оторвешь даже если захочешь. Так что вам не нравится?
__________________
Isn't it nice when things just work? |
|
19.06.2017, 12:33 | #17 |
Участник
|
|
|
19.06.2017, 12:51 | #18 |
Участник
|
Цитата:
У меня только одна просьба - не надо сводить к "недостаткам" людей. Люди везде примерно одинаковые. Не надо приплетать "леность", "неквалифицированность", "боязь" или что-то другое из арсенала "отношений". Правильная постановка вопроса: почему на некоторых задачах пишут тесты, на некоторых нет. сразу выводит на ответ: на задачах, где тесты не дают ощутимого результата на задачах, где трудоемкость по созданию тестов превышает ожидаемый эффект, люди не создают тесты. во всех методичках и руководствах говорится: тесты дают эффект при достаточно большом покрытии кода. следовательно, если задача состоит в небольшой модификации большого куска кода, не покрытого тестами, то под эту модификацию отдельные тесты никто писать не будет чисто по экономическим соображениям. ============== естественно, чисто по индукции, подход "алкоголь в малых дозах безвреден в любом количестве" может привести (и приводит) к тому, что и на больших проектах тесты могут отсутствовать. ============== решить задачу "сделать так, чтобы люди писали тесты" очень просто. для этого не нужно изобретать Систему Воспитания. для этого нужно предоставить доступ к тестам, которые есть. Например, так как это делается для любого нормального проекта на gitHub. Последний раз редактировалось mazzy; 19.06.2017 в 13:01. |
|
19.06.2017, 12:58 | #19 |
Moderator
|
Цитата:
А ответ на твой вопрос - достаточно прост: Если ISV разрабатывает add-on типа печати баркодов, хранения электронного архива или чего-то подобного, то точек пересечения с базовым функционалом не так уж много. В этом случае, есть шансы разработать автоматические тесты с более или менее разумными затратами на это (и есть шансы что разработка тестов окупится при меньшем количестве клиентов - типа 15-20-25). Если же ISV разрабатывает отраслевое вертикальное решение, то во первых, точек интеграции будет слишком много чтобы можно было бы покрыть тестами весь стандартный функционал, который может сломаться; Во вторых - в большинстве случаев, такие вертикальные решения собираются пост-фактум, просто добавлением в базовую ветку проектного функционала, разработанного под конкретного клиента. И как мы уже обсудили, при разработке под конкретного клиента, писать автоматизированные тесты просто не выгодно. И к слову сказать - я вообще считаю что в Аксапте рынка вертикальных решений нет. В 99% случаев, смысл вертикального решения состоит в том чтобы продать консалтинг от их авторов. Я пока только одно отчуждаемое вертикальное решение видел, которое реально можно внедрить не эскалируя 85% проблем его авторам. Остальные вертикальные решения либо вообще в принципе не продаются другим партнерам, либо продаются, но при этом другой партнер реально только базовую настройку делает и пользователей учит (а реальное проектирование решения все равно остается разработчикам вертикального решения).. |
|
19.06.2017, 16:13 | #20 |
Banned
|
d
Цитата:
Все технические изменения сделанные программистами и для программистов - программизм который чаще всего оverengineering. Как грамотно замечено Fed, критерий - отрицательный экономический эффект. У меня у одного чувство что меня обворовали? |
|
Теги |
sysoperation framework |
|
|