Цитата:
Сообщение от
mazzy
А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!
нафига НАМ (партнерам и клиентам) нужен какой-то левый инструмент, который Майкрософту (!) показывает "все ОК", хотя мы видим баг? Нафига нам нужен этот сферический конь в вакууме?
НАМ (партнерам и клиентам) нужно, чтобы правильно работал функционал, с которым МЫ работаем.
пусть пишут скрипты на Аксапте. либо пусть всю Аксапту переводят на C#.
По-моему, так.
Популизмом занимаешься.
Во первых - если при тестировании логистики вылезут ошибки .net bc, то логистика ведь тоже не оттестируется нифига, правда ? Могу предположить что в такой ситуации по полной программе вставят комманде .net bc, но в результате логистику зарелизят неоттестированой (потому что ждали починки .net bc вместо того чтобы тестировать).
Во вторых - то что средство тестирования и тестовая среда должны быть разделены - это некоторый очевидный постулат. Как я могу померить производительность системы, если средство измерения само съедает тики ? Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.
А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...