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

[Vadik]

Цитата:

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

.. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно

Это палка о двух концах. Да, найти незастолбленную нишу на 50+ клиентов - непросто. Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Цитата:

А ты попробуй продать реальному клиенту идею авоматизированного тестирования

Такие идеи как мне кажется надо продавать инвестору, или ОЧЕНЬ "жирному" клиенту. И, да, типичные проектные финтифлюшки покрывать автоматизироавнными тестами пожалуй себе дороже будет

[ax_mct]

Цитата:

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

Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования
количество багов и последующих hotfixes стало меньше? Так сказать экономический эффект интересен.

Мне почему-то не кажется что в AX2012 или Operations стало меньше hotfixes по сравнению с к примеру 3.0. По моему как пользователи работали beta-тестерами так и работают.

Поправьте меня, так как не могу сейчас с цифрами в руках. У меня только субьективное впечатление от то здесь то там прочитанных KB и CU.

[Vadik]

Цитата:

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

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования количество багов и последующих hotfixes стало меньше?

Для 1611 на сегодня - чуть менее 600 X++ хотфиксов. Много это или мало ? Я не знаю, немало это точно, пускай половина и для проектов \ expense management \ GER которые мы пока не сильно (вернее практически никак) не используем. А сколько у Вас хотфиксов доступных, но не установленных - знаете ? У нас - вот столько (снимок с продуктива, там взяли небольшую паузу пока готовились на 1611 перескакивать, вот и поднакопилось). А сколько будет стоить их поставить, возьметесь посчитать? Предвосхищая реплики "да кому они нужны эти ваши хотфиксы" - нужны. У меня в этом году уже двум клиентам в Европе в связи с налоговыми заморочками вынь да выложь надо ставить хотфиксы для 2012 и 2009 которые за собой по древней традиции пол-аксапты тянут. При текущем уровне закастомизированности там одного code merge недели на две, я уж молчу про тестирование. И да - разработку придется остановить или вести параллельно в другом приложении и потом снова мерджить

Цитата:

Так сказать экономический эффект интересен

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы

[macklakov]

Цитата:

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

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили

Ок. Может усложнение исходников и оправданно. Если учесть что MS реально со всей дури впрягся за "вылизывание" стандарта, то вроде как традиционная "доработка напильником" на местах уходит в прошлое. Остаются только разработчики "вертикальных" решений. А им может и стоит задумываться над тем, как изолировать свое решение от стандарта.
Но, есть другой немаловажный момент. Данные! Вот уж что порублено на фарш, та это данные. В результате "программизма", размер таблиц стал чудовищным. При этом несмотря на невероятные усилия по оптимизации, включая переписывание кусков на хранимках, все равно есть места где откровенно подтормаживает. Но главное даже не в этом. Главное что данные нечитаемые. А это приводит к жутким проблемам с BI. Жутким проблемам с миграцией. Жутким проблемам с нарушением целостности.
В результате применения таких "правильных и прогрессивных" паттернов и нормализации, AX превратилась в систему, у которой очень большие проблемы с построением отчетности.