|
20.01.2011, 11:45 | #1 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
Из возможности отладки на рабочем приложении не следует необходимость делания фиксов, которые "быстро заливаются". Отладка в большинстве случаев необходима чтобы разобраться в причине неадекватного поведения.
Сравните время поиска ответа в документации (которого в ней может не быть или он может быть сильно завуалирован) со временем прохода в отладчике и понимании что "кто-то не заполнил вот такое-то поле" или "кто-то выключил вот такую-то галку" или (в крайнем случае) "при написании и тестировании кода не учли такую-то ситуацию". Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая: а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал) б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы в) может в принципе не воспроизводиться на любой БД кроме рабочей Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать. А насчет "экономически выгодно" - слов нет. Вроде как считается, торговля наркотиками - один из самых экономически выгодных видов деятельности. Но это же не значит, что всем нужно срочно на него переключаться? Понятно, что если переносить нетестированный код (думаю, я правильно понял эвфемизм "вместо тщательного тестирования"), то потом надо будет судорожно дебагить рабочее приложение и фиксить все "максимум в течение часа" |
|
20.01.2011, 12:55 | #2 |
Участник
|
Тю!.. вот только не надо "ля-ля" про нетестированный код! Кто-то так хорошо тестировал RCashVoucher (в RU5, по крайней мере), что забыл обрамить обращения к RCashTrans в unchecked(Uncheck::TableSecurityPermission) (хотя Best Practices все знают и Writing Secure X++ Code, наверно, все читали - иначе с чего бы повесили AOSAuthorization на таблицу), из-за чего у пользователей без доступа к ключу RCashTables, но с доступом к самой таблице и всем формам не разносятся кассовые журналы.
|
|
|
За это сообщение автора поблагодарили: Daiver (1). |