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

[mifi]

Цитата:

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

Вроде Понтоппидан ясно написал, что по умолчанию выполнение приложения в виде IL-кода средствами CLR включено лишь для пакетников, вызовов каких-то сервисов и отдельных кусков приложения, на которые явно указали разработчики посредством RunAs. Я лично сразу вспомнил про "особенности" отладки кода в NAV 2009 (пишешь на одном языке, отлаживаешь на другом) и подумал, что так сделали именно из-за отладки: пакетники отлаживают не так часто (по крайней мере, именно в режиме выполнения на сервере), но при этом на них может приходиться существенная доля нагрузки на систему, поэтому для них и включили по умолчанию новый механизм исполнения кода, а для бизнес-логики, запускаемой пользователями, - выключили, чтобы ее можно было при необходимости отлаживать, как обычно.
По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа.

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

[sukhanchik]

Цитата:

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

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

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

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

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

[mifi]

Цитата:

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

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

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

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

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

[gl00mie]

Цитата:

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

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

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

[CDR]

Цитата:

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

На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.

Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.

[mifi]

Цитата:

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

Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.

Забавная дискуссия получилась. На утверждение, сопоставимое, на мой взгляд, по тривиальности с "Дети, чистите зубы утром и вечером " в ответ слышно, в основном "Вы там в МС к.. теоретики" В общем, подобная точка зрения тоже имеет право на существование, но зубы все-таки надо чистить/поддерживать рабочую, тестовую и разработческую версию

[Logger]

Цитата:

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

Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.

Вы хотите всего и сразу.
Сначала скажите спасибо, что она вообще появилась.

Производительность, будем надеяться, потом допилят.

Кстати, почитал что нового в RU6 - в отличие от RU5 - нового почти ничего. В основном исправление ошибок и ускорение работы.

[Link]

Цитата:

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

На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.

Как же я вам по хорошему завидую! Меня как единственного разработчика просят все время на боевой не только проекты заливать, но и манипулировать с данными, транзакциями например
Хотел бы я не иметь доступа к боевой системе и базе. У нас конечно есть и тест и дев, которые я создал и использую, но часто нужно вот прямо сейчас, да и уровень тестирования у нас минимальный. Естественно временами возникают какие то недочеты, и приходится фиксить данные

[coolibin]

Конечно же конечные пользователи все разные. В моей нынешней компании, например, процедура обновления приложения регулируется внешними требованиями. Есть другие компании, где это никому, кроме самой компании не важно, как хотят, так и организуют. Если какая-то фича убирается из системы при переходе к новой версии, естественно это обедняет систему. Возможно, не всем это может быть важно, но это другой вопрос.

И бест практис - это же в конце концов не религия, клиент систему покупает не для того, чтобы на бест практис помолиться.