Отладка на рабочей базе

[sukhanchik]

Цитата:

Сообщение от mifi

В ответ на вопрос пользователя нужно дать правильный ответ.У меня есть подозрение, что достаточно существенный процент ответов (а тем более фиксов), сделанных "в течение максимум часа" приведут, извиняюсь, к еще большей фигне.

Из возможности отладки на рабочем приложении не следует необходимость делания фиксов, которые "быстро заливаются". Отладка в большинстве случаев необходима чтобы разобраться в причине неадекватного поведения.
Сравните время поиска ответа в документации (которого в ней может не быть или он может быть сильно завуалирован) со временем прохода в отладчике и понимании что "кто-то не заполнил вот такое-то поле" или "кто-то выключил вот такую-то галку" или (в крайнем случае) "при написании и тестировании кода не учли такую-то ситуацию".

Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая:
а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал)
б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы
в) может в принципе не воспроизводиться на любой БД кроме рабочей

Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.

[mifi]

Цитата:

Сообщение от sukhanchik

Из возможности отладки на рабочем приложении не следует необходимость делания фиксов, которые "быстро заливаются". Отладка в большинстве случаев необходима чтобы разобраться в причине неадекватного поведения.
Сравните время поиска ответа в документации (которого в ней может не быть или он может быть сильно завуалирован) со временем прохода в отладчике и понимании что "кто-то не заполнил вот такое-то поле" или "кто-то выключил вот такую-то галку" или (в крайнем случае) "при написании и тестировании кода не учли такую-то ситуацию".

Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая:
а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал)
б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы
в) может в принципе не воспроизводиться на любой БД кроме рабочей

Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.

У нас пошел офф-топик от основной темы, поэтому предлагаю выделить данную подветку отдельно.
А насчет "экономически выгодно" - слов нет. Вроде как считается, торговля наркотиками - один из самых экономически выгодных видов деятельности. Но это же не значит, что всем нужно срочно на него переключаться?
Понятно, что если переносить нетестированный код (думаю, я правильно понял эвфемизм "вместо тщательного тестирования"), то потом надо будет судорожно дебагить рабочее приложение и фиксить все "максимум в течение часа"

[gl00mie]

Цитата:

Сообщение от mifi

Понятно, что если переносить нетестированный код (думаю, я правильно понял эвфемизм "вместо тщательного тестирования"), то потом надо будет судорожно дебагить рабочее приложение и фиксить все "максимум в течение часа"

Тю!.. вот только не надо "ля-ля" про нетестированный код! Кто-то так хорошо тестировал RCashVoucher (в RU5, по крайней мере), что забыл обрамить обращения к RCashTrans в unchecked(Uncheck::TableSecurityPermission) (хотя Best Practices все знают и Writing Secure X++ Code, наверно, все читали - иначе с чего бы повесили AOSAuthorization на таблицу), из-за чего у пользователей без доступа к ключу RCashTables, но с доступом к самой таблице и всем формам не разносятся кассовые журналы.