|
20.01.2011, 14:00 | #1 |
Участник
|
Мнение и аргументы тех, кто работал только со стороны исполнителя, будут неполными. И тех, кто работал только у заказчика, тоже будут неполными. Только тот, кто работал и со стороны заказчика, и со стороны исполнителя, кто знает и теорию правильной разработки и реальную жизнь, смогут адекватно между собой обсуждать данную тему. Иначе будет разговор глухих со слепыми.
Имеет смысл вообще закрыть ветку. |
|
20.01.2011, 14:03 | #2 |
Microsoft Dynamics
|
Цитата:
Сообщение от Logger
Да никто не спорит что разрабатывать и отлаживать надо по науке. Пишем на дев, тестируем на тесте. Работаем на рабочей.
Но иногда просто необходимо на рабочей что нибудь отладить. К сожалению, иногда воспроизвести глюк на тесте - отдельная большая задача. Плюс не всегда есть уверенность что это тот же самый глюк. А на боевой удобно посмотреть, быстро ясна причина. Время реагирования на запрос снижается кардинально. P.S. Аксапта это, к сожалению, не iPhone 4 Её с руками не отрывают. И кризис в IT никуда пока не делся. Надо думать как предоставить клиенту лучший сервис. Если люди на ваши слова нервно реагируют, то это не логотип виноват, а наболело у них. А вы просто под руку подвернулись То, что следует сесть вместе с пользователем и посмотреть, что у него происходит - вроде как с этим никто не спорил. А вот дебагить разноску инвойса на терабайтной базе с парой сотен работающих пользователей.. хм. |
|
20.01.2011, 14:35 | #3 |
Участник
|
Цитата:
НО, если вендор может себе позволить отвечать на любой запрос об ошибке в срок от недели до года, то первая линия поддержки заказчика не может себе позволить такой роскоши. По критичному запросу вынь и положи решение в течение полудня. Иначе заказчик может разориться и уже счета по работам поддержки оплачивать уже будет некому... Я так прикидываю, что без возможности дебага на рабочей версии, время обратотки особо заковыристых вопросов может подскочить на тысячи процентов сразу. Такой запрос вылезает может и раз в год, но по закону подлости это бывает или прямо перед сдачей налоговой отчетности или когда идет вал отгрузок перед праздниками. |
|
20.01.2011, 15:27 | #4 |
Участник
|
А меня вот парят эти вот пол-часа - час, там где их раньше не было вообще (1-5 мин или 60 мин -это все же х12-60 разницы, при этом эти 5 мин еще и на тесте тратить). Да и выгружать по-живому куски таблиц тоже работа. То есть в ущерб чему-то или спец чел. И кто сказал, что в Тб базе эти нужные куски тоже не маленькие - вдруг там контрольный пример как раз неверная сумма на кучи данных?
В общем, выжить будет можно, станет сложнее на пустом месте, дольше в суппорте, а значит выше цена владения. И сложности (отпугивание) при продажах. Зато сильно методологичнее на уровне хардхода, а не выбора галок и методологии применения самого инструмента. Электрорубанком при определенном усердии (таком же, как ты, Миша, предлагаешь) и с выключенном электричеством можно строгать Цитата:
Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди
Тут скорее "мне за державу обидно"(С) В смысле систему. |
|
20.01.2011, 15:32 | #5 |
Участник
|
Речь не идет о разработке на рабочем окружении. Речь идет о поиске и выявлении причин неадекватного поведения продуктива системы.
Особенно это актуально на запуске системы. Если такой возможности не будет в новой версии - это будет катастрофа. Кстати в основном потребность трейсинга для выяснения причин невнятных сообщений об ошибках или что еще хуже - трассировок стека - это "сюрпризы" от MS из-за некачественного тестирования нового функционала. На одном проекте из-за багов в стандарте в новом функционале многопоточного сводника в 2009 под угрозой оказалось продолжение эксплуатации системы. Весь функционал тестировался перед запуском, но баг вылез только на больших объемах. Если бы в этот момент (когда под угрозой стояла поставка в магазины на следующий день) мы предложили сделать копию рабочей базы и не спеша там поискать причину ошибки - проект бы точно остановили. |
|
|
За это сообщение автора поблагодарили: AlGol (2), macklakov (2), sukhanchik (2). |
20.01.2011, 15:37 | #6 |
Administrator
|
Цитата:
А если баг проявляется только в многопользовательском варианте? Всех загонять в тестовую? Утопия это. Просто скорее всего все это кончится тем, что отладку будут включать на рабочей БД, клиенты будут мучаться с производительностью, а в МС гадать - а чем же производительность АХ их не устраивает.
__________________
Возможно сделать все. Вопрос времени |
|
20.01.2011, 15:39 | #7 |
Участник
|
пересмотрите видео - отладка там есть
|
|
20.01.2011, 15:47 | #8 |
Microsoft Dynamics
|
Цитата:
Сообщение от belugin
пересмотрите видео - отладка там есть
|
|
20.01.2011, 16:01 | #9 |
Banned
|
Фича - сверхнужная, смех здесь неуместен. Другое дело, что использовать ее надо как можно реже и как можно короче из-за опасности блокировок в многопользовательском режиме.
|
|
20.01.2011, 16:18 | #10 |
Administrator
|
Цитата:
__________________
Возможно сделать все. Вопрос времени |
|
02.04.2012, 11:32 | #11 |
NavAx
|
Мне кажется, что после первого судебного прецендента, когда вендор покроет издержки, понесенные клиентом из-за ошибки в ядре, эта фича перестанет быть сверхнужной.
__________________
Isn't it nice when things just work? |
|
20.01.2011, 16:01 | #12 |
Участник
|
Многие действительно забывает о существовании разработчиков у самого клиента. Я работал и в консалтинговой компании и на клиенте. У внедренца есть время все протестить и перепроверить. На клиенте обычно происходило так: какой-нибудь пользователь что-то отчебучил в системе, что-то поломалось, и он побежал жаловаться начальству. И все, куча писем, телефоны обрывают, нужно решить проблему быстро. А когда еще и генеральный прибегает с пеной у рта...
И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд... Опять же не нужно забывать о наличии багов как в стандарте, так и в российской локализации. Так что иногда дебаг на боевом приложении иногда очень нужен первой линии обороны. И говорить что они криволапые и руки им нужно оторвать... ну не совсем разумно наверное. |
|
20.01.2011, 16:08 | #13 |
Microsoft Dynamics
|
Цитата:
Сообщение от greench
Многие действительно забывает о существовании разработчиков у самого клиента. Я работал и в консалтинговой компании и на клиенте. У внедренца есть время все протестить и перепроверить. На клиенте обычно происходило так: какой-нибудь пользователь что-то отчебучил в системе, что-то поломалось, и он побежал жаловаться начальству. И все, куча писем, телефоны обрывают, нужно решить проблему быстро. А когда еще и генеральный прибегает с пеной у рта...
И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд... Опять же не нужно забывать о наличии багов как в стандарте, так и в российской локализации. Так что иногда дебаг на боевом приложении иногда очень нужен первой линии обороны. И говорить что они криволапые и руки им нужно оторвать... ну не совсем разумно наверное. |
|
20.01.2011, 16:35 | #14 |
Участник
|
Отлаживаться можно без APPDomain насколько я знаю.
Горячую замену нужно проводить через APPDomain. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
20.01.2011, 18:43 | #15 |
Гость
|
|
|