|
20.01.2011, 08:32 | #1 |
Участник
|
Цитата:
Сообщение от fed
А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок.
1. Отладка на сервере возможна только через VS Debugger 2. Чтобы отлаживаться, придется включать App Domain с тормозами. 3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping. По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа. |
|
|
За это сообщение автора поблагодарили: Logger (2). |
20.01.2011, 09:10 | #2 |
Microsoft Dynamics
|
Цитата:
Сообщение от gl00mie
Вроде Понтоппидан ясно написал, что по умолчанию выполнение приложения в виде IL-кода средствами CLR включено лишь для пакетников, вызовов каких-то сервисов и отдельных кусков приложения, на которые явно указали разработчики посредством RunAs. Я лично сразу вспомнил про "особенности" отладки кода в NAV 2009 (пишешь на одном языке, отлаживаешь на другом) и подумал, что так сделали именно из-за отладки: пакетники отлаживают не так часто (по крайней мере, именно в режиме выполнения на сервере), но при этом на них может приходиться существенная доля нагрузки на систему, поэтому для них и включили по умолчанию новый механизм исполнения кода, а для бизнес-логики, запускаемой пользователями, - выключили, чтобы ее можно было при необходимости отлаживать, как обычно.
По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа. Последний раз редактировалось mifi; 20.01.2011 в 09:12. |
|
20.01.2011, 10:06 | #3 |
Administrator
|
Цитата:
Сравните время поиска ответа в документации (которого в ней может не быть или он может быть сильно завуалирован) со временем прохода в отладчике и понимании что "кто-то не заполнил вот такое-то поле" или "кто-то выключил вот такую-то галку" или (в крайнем случае) "при написании и тестировании кода не учли такую-то ситуацию". Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая: а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал) б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы в) может в принципе не воспроизводиться на любой БД кроме рабочей Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 20.01.2011 в 10:12. |
|
20.01.2011, 11:45 | #4 |
Microsoft Dynamics
|
Цитата:
Сообщение от sukhanchik
Из возможности отладки на рабочем приложении не следует необходимость делания фиксов, которые "быстро заливаются". Отладка в большинстве случаев необходима чтобы разобраться в причине неадекватного поведения.
Сравните время поиска ответа в документации (которого в ней может не быть или он может быть сильно завуалирован) со временем прохода в отладчике и понимании что "кто-то не заполнил вот такое-то поле" или "кто-то выключил вот такую-то галку" или (в крайнем случае) "при написании и тестировании кода не учли такую-то ситуацию". Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая: а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал) б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы в) может в принципе не воспроизводиться на любой БД кроме рабочей Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать. А насчет "экономически выгодно" - слов нет. Вроде как считается, торговля наркотиками - один из самых экономически выгодных видов деятельности. Но это же не значит, что всем нужно срочно на него переключаться? Понятно, что если переносить нетестированный код (думаю, я правильно понял эвфемизм "вместо тщательного тестирования"), то потом надо будет судорожно дебагить рабочее приложение и фиксить все "максимум в течение часа" |
|
20.01.2011, 12:55 | #5 |
Участник
|
Тю!.. вот только не надо "ля-ля" про нетестированный код! Кто-то так хорошо тестировал RCashVoucher (в RU5, по крайней мере), что забыл обрамить обращения к RCashTrans в unchecked(Uncheck::TableSecurityPermission) (хотя Best Practices все знают и Writing Secure X++ Code, наверно, все читали - иначе с чего бы повесили AOSAuthorization на таблицу), из-за чего у пользователей без доступа к ключу RCashTables, но с доступом к самой таблице и всем формам не разносятся кассовые журналы.
|
|
|
За это сообщение автора поблагодарили: Daiver (1). |
20.01.2011, 12:59 | #6 |
MCTS
|
Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.
__________________
Dynamics AX Experience |
|
20.01.2011, 13:10 | #7 |
Microsoft Dynamics
|
Забавная дискуссия получилась. На утверждение, сопоставимое, на мой взгляд, по тривиальности с "Дети, чистите зубы утром и вечером " в ответ слышно, в основном "Вы там в МС к.. теоретики" В общем, подобная точка зрения тоже имеет право на существование, но зубы все-таки надо чистить/поддерживать рабочую, тестовую и разработческую версию
|
|
20.01.2011, 13:35 | #8 |
Участник
|
Цитата:
Сначала скажите спасибо, что она вообще появилась. Производительность, будем надеяться, потом допилят. Кстати, почитал что нового в RU6 - в отличие от RU5 - нового почти ничего. В основном исправление ошибок и ускорение работы. |
|
30.03.2012, 19:04 | #9 |
Британский учённый
|
Цитата:
Хотел бы я не иметь доступа к боевой системе и базе. У нас конечно есть и тест и дев, которые я создал и использую, но часто нужно вот прямо сейчас, да и уровень тестирования у нас минимальный. Естественно временами возникают какие то недочеты, и приходится фиксить данные
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
30.03.2012, 20:30 | #10 |
Участник
|
Конечно же конечные пользователи все разные. В моей нынешней компании, например, процедура обновления приложения регулируется внешними требованиями. Есть другие компании, где это никому, кроме самой компании не важно, как хотят, так и организуют. Если какая-то фича убирается из системы при переходе к новой версии, естественно это обедняет систему. Возможно, не всем это может быть важно, но это другой вопрос.
И бест практис - это же в конце концов не религия, клиент систему покупает не для того, чтобы на бест практис помолиться. |
|