|
![]() |
#1 |
Microsoft Dynamics
|
То, что Вы шутили, я понял. Но, в общем, мне не очень весело. Единственная надежда, что только мой логотип вызвал отторжение идеи того, что разрабатывать и отлаживать надо на разработческой версии.
Последний раз редактировалось mifi; 20.01.2011 в 13:46. |
|
![]() |
#2 |
Administrator
|
Цитата:
Конечно - данный подход заведомо неприменим к софтверной компании. Однако - он вполне устраивает клиента, т.к. в этом случае время, потраченное на исправление (пусть и в "горячем" режиме) на порядок меньше времени, потраченного бы на тестирование. А рабочий процесс позволяет выполнить данную процедуру в "горячем" режиме. Другого клиента такой подход мог бы и не устроить - у него стоимость простоя могла быть выше стоимости тестирования. В этом и гибкость системы - она устраивает двух клиентов. При запрете отладки на рабочей БД - один клиент из этих двух может отпасть - что приведет к уменьшению количества клиентов АХ (а мы, специалисты - в этом явно не заинтересованы).
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 20.01.2011 в 14:01. |
|
![]() |
#3 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
![]() Дык с этим же никто и не спорит. Я ж тоже утрировал немного. Просто вот совершенно недавно видел ситуацию, что сотрудник клиента (система уже давно работает в промышленной эксплуатации и активной разработки не ведется) изменил некий код, при этом никто из сотрудников не знал всех мест где аукнется это изменение (чтобы не быть голословным - скажу - что изменили длину поля, и не знали в каких из хранимых процедур, не относящихся к штатной поставке АХ нужно произвести соответствующие изменения). И они решили оставить такую ситуацию, зная, что где-нибудь это вылезет. И это вылезло. И это поправили. А нашли нужное место отладчиком. Прямо на рабочей базе в рабочем процессе.
Конечно - данный подход заведомо неприменим к софтверной компании. Однако - он вполне устраивает клиента, т.к. в этом случае время, потраченное на исправление (пусть и в "горячем" режиме) на порядок меньше времени, потраченного бы на тестирование. А рабочий процесс позволяет выполнить данную процедуру в "горячем" режиме. Другого клиента такой подход мог бы и не устроить - у него стоимость простоя могла быть выше стоимости тестирования. В этом и гибкость системы - она устраивает двух клиентов. При запрете отладки на рабочей БД - один клиент из этих двух может отпасть - что приведет к уменьшению количества клиентов АХ (а мы, специалисты - в этом явно не заинтересованы). Клиенту нужно первое. А второе - это только один из способов. Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать. Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных? |
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от mifi
![]() Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов. Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать. Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных? Иногда повтор ситуации займет 2-4ч реала или бакап Террабайтной базы ( это тоже не 1 час) + останов системы на Х часов. Речь о том, что система отладки нужна на любой версии, а вот как ее применять (запрещать) - это осознанная методология внедрения\эксплуатации. Но инструмент должен быть! Это как шуроповерт или простая отвертка дома - она нужна не всегда, но бывает момент... и опа, она есть, а не нужно идти к соседу, а потом ее нести обратно. Вот и тут так же - это все (отладка на рабочей) не нужно и нештатно - но это должно быть в ассортименте. Просто в проекте есть моменты, когда это уж очень нужно и становится штатным (опытная эксплуатация на 1-3 недели). Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно). Че уж говорить о "теоретиках", которые даже глаз внедренца не видят ![]() Последний раз редактировалось BOAL; 20.01.2011 в 14:35. |
|
![]() |
#5 |
Administrator
|
Цитата:
Сообщение от BOAL
![]() Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят ![]() ![]() Цитата:
- исправления в коде ошибок, не выявленных на тестировании - неверную настройку каких-то параметров (в этом случае можно как ошибку считать отсутствие информативного сообщения об этом) - ошибки самих пользователей, на которые не сделана "защита от дурака" или которые невозможно защитить "от дурака". Цитата:
Сообщение от mifi
![]() Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных? Опять-таки: - на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя - на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек ![]()
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#6 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
![]() Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди
![]() Все так, с уточнением, что под фразой "фиксить баги" мы понимаем: - исправления в коде ошибок, не выявленных на тестировании - неверную настройку каких-то параметров (в этом случае можно как ошибку считать отсутствие информативного сообщения об этом) - ошибки самих пользователей, на которые не сделана "защита от дурака" или которые невозможно защитить "от дурака". Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо. Опять-таки: - на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя - на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек ![]() ![]() |
|
![]() |
#7 |
Administrator
|
Цитата:
Сообщение от mifi
![]() В общем, все так
![]() Я не очень помню - отменяли ли правило "разрешенных трех приложений" в лицензионной политике - но если не отменяли - то нет возможности так плодить базы. А если есть возможность, то получается нужно иметь помимо рабочей БД еще: - разработческую - тестовую - демонстрационную (для обучения новых пользователей) - суппортную (которая постоянно обновляется) Так много баз обычно не держат и часто совмещают базы, в результате чего нет настроенного постоянного бекапа так, чтобы можно было восстановить чисто изменения и посмотреть что где. В результате для актуализации данных нужно разворачивать полный бекап. По поводу интеграции. Ошибки могут быть где угодно. И в АХ в том числе. А вот для выявления этих ошибок как ни крути нужен дебаггер. Особенно - если ошибка не на стороне АХ. А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).
__________________
Возможно сделать все. Вопрос времени |
|