![]() |
#21 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
![]() Дык с этим же никто и не спорит. Я ж тоже утрировал немного. Просто вот совершенно недавно видел ситуацию, что сотрудник клиента (система уже давно работает в промышленной эксплуатации и активной разработки не ведется) изменил некий код, при этом никто из сотрудников не знал всех мест где аукнется это изменение (чтобы не быть голословным - скажу - что изменили длину поля, и не знали в каких из хранимых процедур, не относящихся к штатной поставке АХ нужно произвести соответствующие изменения). И они решили оставить такую ситуацию, зная, что где-нибудь это вылезет. И это вылезло. И это поправили. А нашли нужное место отладчиком. Прямо на рабочей базе в рабочем процессе.
Конечно - данный подход заведомо неприменим к софтверной компании. Однако - он вполне устраивает клиента, т.к. в этом случае время, потраченное на исправление (пусть и в "горячем" режиме) на порядок меньше времени, потраченного бы на тестирование. А рабочий процесс позволяет выполнить данную процедуру в "горячем" режиме. Другого клиента такой подход мог бы и не устроить - у него стоимость простоя могла быть выше стоимости тестирования. В этом и гибкость системы - она устраивает двух клиентов. При запрете отладки на рабочей БД - один клиент из этих двух может отпасть - что приведет к уменьшению количества клиентов АХ (а мы, специалисты - в этом явно не заинтересованы). Клиенту нужно первое. А второе - это только один из способов. Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать. Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных? |
|
![]() |
#22 |
Участник
|
Цитата:
Сообщение от mifi
![]() Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов. Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать. Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных? Иногда повтор ситуации займет 2-4ч реала или бакап Террабайтной базы ( это тоже не 1 час) + останов системы на Х часов. Речь о том, что система отладки нужна на любой версии, а вот как ее применять (запрещать) - это осознанная методология внедрения\эксплуатации. Но инструмент должен быть! Это как шуроповерт или простая отвертка дома - она нужна не всегда, но бывает момент... и опа, она есть, а не нужно идти к соседу, а потом ее нести обратно. Вот и тут так же - это все (отладка на рабочей) не нужно и нештатно - но это должно быть в ассортименте. Просто в проекте есть моменты, когда это уж очень нужно и становится штатным (опытная эксплуатация на 1-3 недели). Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно). Че уж говорить о "теоретиках", которые даже глаз внедренца не видят ![]() Последний раз редактировалось BOAL; 20.01.2011 в 14:35. |
|
![]() |
#23 |
Участник
|
Цитата:
НО, если вендор может себе позволить отвечать на любой запрос об ошибке в срок от недели до года, то первая линия поддержки заказчика не может себе позволить такой роскоши. По критичному запросу вынь и положи решение в течение полудня. Иначе заказчик может разориться и уже счета по работам поддержки оплачивать уже будет некому... Я так прикидываю, что без возможности дебага на рабочей версии, время обратотки особо заковыристых вопросов может подскочить на тысячи процентов сразу. Такой запрос вылезает может и раз в год, но по закону подлости это бывает или прямо перед сдачей налоговой отчетности или когда идет вал отгрузок перед праздниками. |
|
![]() |
#24 |
Administrator
|
Цитата:
Сообщение от BOAL
![]() Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят ![]() ![]() Цитата:
- исправления в коде ошибок, не выявленных на тестировании - неверную настройку каких-то параметров (в этом случае можно как ошибку считать отсутствие информативного сообщения об этом) - ошибки самих пользователей, на которые не сделана "защита от дурака" или которые невозможно защитить "от дурака". Цитата:
Сообщение от mifi
![]() Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных? Опять-таки: - на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя - на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек ![]()
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#25 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
![]() Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди
![]() Все так, с уточнением, что под фразой "фиксить баги" мы понимаем: - исправления в коде ошибок, не выявленных на тестировании - неверную настройку каких-то параметров (в этом случае можно как ошибку считать отсутствие информативного сообщения об этом) - ошибки самих пользователей, на которые не сделана "защита от дурака" или которые невозможно защитить "от дурака". Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо. Опять-таки: - на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя - на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек ![]() ![]() |
|
![]() |
#26 |
Участник
|
А меня вот парят эти вот пол-часа - час, там где их раньше не было вообще (1-5 мин или 60 мин -это все же х12-60 разницы, при этом эти 5 мин еще и на тесте тратить). Да и выгружать по-живому куски таблиц тоже работа. То есть в ущерб чему-то или спец чел. И кто сказал, что в Тб базе эти нужные куски тоже не маленькие - вдруг там контрольный пример как раз неверная сумма на кучи данных?
В общем, выжить будет можно, станет сложнее на пустом месте, дольше в суппорте, а значит выше цена владения. И сложности (отпугивание) при продажах. Зато сильно методологичнее на уровне хардхода, а не выбора галок и методологии применения самого инструмента. Электрорубанком при определенном усердии (таком же, как ты, Миша, предлагаешь) и с выключенном электричеством можно строгать ![]() Цитата:
Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди
Тут скорее "мне за державу обидно"(С) В смысле систему. |
|
![]() |
#27 |
Участник
|
Речь не идет о разработке на рабочем окружении. Речь идет о поиске и выявлении причин неадекватного поведения продуктива системы.
Особенно это актуально на запуске системы. Если такой возможности не будет в новой версии - это будет катастрофа. Кстати в основном потребность трейсинга для выяснения причин невнятных сообщений об ошибках или что еще хуже - трассировок стека - это "сюрпризы" от MS из-за некачественного тестирования нового функционала. На одном проекте из-за багов в стандарте в новом функционале многопоточного сводника в 2009 под угрозой оказалось продолжение эксплуатации системы. Весь функционал тестировался перед запуском, но баг вылез только на больших объемах. Если бы в этот момент (когда под угрозой стояла поставка в магазины на следующий день) мы предложили сделать копию рабочей базы и не спеша там поискать причину ошибки - проект бы точно остановили. |
|
|
За это сообщение автора поблагодарили: AlGol (2), macklakov (2), sukhanchik (2). |
![]() |
#28 |
Administrator
|
Цитата:
Сообщение от mifi
![]() В общем, все так
![]() Я не очень помню - отменяли ли правило "разрешенных трех приложений" в лицензионной политике - но если не отменяли - то нет возможности так плодить базы. А если есть возможность, то получается нужно иметь помимо рабочей БД еще: - разработческую - тестовую - демонстрационную (для обучения новых пользователей) - суппортную (которая постоянно обновляется) Так много баз обычно не держат и часто совмещают базы, в результате чего нет настроенного постоянного бекапа так, чтобы можно было восстановить чисто изменения и посмотреть что где. В результате для актуализации данных нужно разворачивать полный бекап. По поводу интеграции. Ошибки могут быть где угодно. И в АХ в том числе. А вот для выявления этих ошибок как ни крути нужен дебаггер. Особенно - если ошибка не на стороне АХ. А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#29 |
Administrator
|
Цитата:
А если баг проявляется только в многопользовательском варианте? Всех загонять в тестовую? Утопия это. Просто скорее всего все это кончится тем, что отладку будут включать на рабочей БД, клиенты будут мучаться с производительностью, а в МС гадать - а чем же производительность АХ их не устраивает.
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#30 |
Участник
|
пересмотрите видео - отладка там есть
|
|
![]() |
#31 |
Microsoft Dynamics
|
Цитата:
Сообщение от belugin
![]() пересмотрите видео - отладка там есть
![]() ![]() |
|
![]() |
#32 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
![]() А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).
|
|
![]() |
#33 |
Участник
|
Многие действительно забывает о существовании разработчиков у самого клиента. Я работал и в консалтинговой компании и на клиенте. У внедренца есть время все протестить и перепроверить. На клиенте обычно происходило так: какой-нибудь пользователь что-то отчебучил в системе, что-то поломалось, и он побежал жаловаться начальству. И все, куча писем, телефоны обрывают, нужно решить проблему быстро. А когда еще и генеральный прибегает с пеной у рта...
И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд... Опять же не нужно забывать о наличии багов как в стандарте, так и в российской локализации. Так что иногда дебаг на боевом приложении иногда очень нужен первой линии обороны. И говорить что они криволапые и руки им нужно оторвать... ну не совсем разумно наверное. |
|
![]() |
#34 |
Banned
|
Фича - сверхнужная, смех здесь неуместен. Другое дело, что использовать ее надо как можно реже и как можно короче из-за опасности блокировок в многопользовательском режиме.
|
|
![]() |
#35 |
Microsoft Dynamics
|
Цитата:
Сообщение от greench
![]() Многие действительно забывает о существовании разработчиков у самого клиента. Я работал и в консалтинговой компании и на клиенте. У внедренца есть время все протестить и перепроверить. На клиенте обычно происходило так: какой-нибудь пользователь что-то отчебучил в системе, что-то поломалось, и он побежал жаловаться начальству. И все, куча писем, телефоны обрывают, нужно решить проблему быстро. А когда еще и генеральный прибегает с пеной у рта...
И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд... Опять же не нужно забывать о наличии багов как в стандарте, так и в российской локализации. Так что иногда дебаг на боевом приложении иногда очень нужен первой линии обороны. И говорить что они криволапые и руки им нужно оторвать... ну не совсем разумно наверное. ![]() |
|
![]() |
#36 |
Administrator
|
Цитата:
Сообщение от mifi
![]() О чем говорит данный сценарий? На мой взгляд, как раз о том, что пользователь начал использовать новую функциональность без тестирования и пользовательских процедур. Ввел что ему в голову взбрело. И это хорошо, если он попросил консультации "что у него не так". А если забил/не обратил внимание и наплодил таких данных за месяц, прежде чем ошибка обнаружилась?
Дело-то в другом. Внедренец (если это сторонняя фирма) сможет сделать такие выводы только после анализа кода в отладчике (если такая ситуация конечно возникла первый раз). Или же нанятый сотрудник клиента, малознакомый с функциональностью также не сможет быстро выяснить причины проблемы без отладки. Но... главный вопрос. МС заинтересован в увеличении числа таких клиентов? Ведь в результате "действования по науке" фирма будет иметь уже бизнес-проблемы, а ведь обвинят в первую очередь систему и именно от нее будут стремиться отказаться. При грамотном подходе можно и SQL Server затюнить и 1С заставить летать и много чего еще. Мы все выбираем соотношение цена/качество - и не стремимся купить бентли для поездки на дачу. Так почему же МС заставляет отказываться от АХ?
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#37 |
Участник
|
Так никто никого ничего не заставляет. Уже выяснили что дебаг на боевой никто не отменяет. Пошла больше дискуссия в стиле "за жизнь поговорить"
![]() |
|
![]() |
#38 |
Administrator
|
Цитата:
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#39 |
Administrator
|
Цитата:
Цитата:
Сообщение от fed
![]() А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок. То есть - либо рестарт боевого AOS, либо работа через Application Domain. Причем скорость второго режима, мягко говоря, бледно смотриться даже на фоне скорости старого интерпретатора.
![]() Ооо - почитал твиттер Брендона: 1. Отладка на сервере возможна только через VS Debugger 2. Чтобы отлаживаться, придется включать App Domain с тормозами. 3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping. В жизни получается (клиент делает такой вывод или ему помогают сделать такой вывод) что режим отладки (Application Domain) должен быть постоянно включен на рабочей БД, что влияет на скорость работы. У клиента наступает разочарование и полное желание отказаться от такой системы (если хватает денег ![]() Клиент меняет систему и имеет систему если не лучше то по крайней мере дешевле. Клиент всем своим знакомым рассказывает - какой отстой - АХ - и ни в коем случае не работайте с МС - там нет компетентных людей.
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#40 |
Участник
|
Отлаживаться можно без APPDomain насколько я знаю.
Горячую замену нужно проводить через APPDomain. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
Теги |
ax2012 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|