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