как Вы диагностируете с “работами над моей машиной” сценарии
Вы воссоздаете свой магазин каждый раз, когда компонент отображается.
const store = createStore(rootReducer, applyMiddleware(logger, middleware));
export default class Root extends React.Component {
props: Props;
renderApp() {
return (
<Provider store={store}>
<Navigator/>
</Provider>
);
}
render() {
return this.renderApp();
}
}
8 ответов
С точки зрения обучения / процесса:
Обучите свою команду, чтобы она знала, что «работает на моей машине» - это не выход из тюрьмы.
] Иметь автоматизированный сервер сборки .
Иметь автоматическое тестовое развертывание.
Ваши разработчики должны знать, что «работает» определяется как «работает на тестовом сервере», а не только на их машине.
С точки зрения тестирования / отладки:
Разработчику необходимо показать последовательность действий, которые приводят к возникновению ошибки.
Возможно, вы захотите сделать снимки экрана, показывающие ошибку, или, возможно, захват видео ( с использованием таких инструментов, как Camtasia ). Люди могут очень плохо описывать последовательность действий, которые они выполняли в системе, которая привела к появлению ошибки,
Вы должны предоставить разработчику как можно больше информации. Даже те вещи, которые вы не считаете актуальными.
Я не могу сосчитать, сколько раз мне сообщали о проблеме и не мог повторить ее, только чтобы узнать позже часть информации, которая была у пользователя. Первоначально он не был включен, но был ключом к разгадке головоломки.
Вы также должны не принять этот ответ и сказать: «Ну, что-то должно отличаться между вашей установкой и моей, что мы можем сделать, чтобы сделать разберись ".
Это обычная реплика эскапистов, с которой я сталкиваюсь в командах. Мой ответ обычно таков: «Вы знаете, ваша система не является рабочим сервером, и именно там она должна работать». Другими словами, это оправдание просто неприемлемо.
Я также указываю им возможности:
a. Существует разница в конфигурации между локальной системой и сервером.
b. Некоторые зависимости функциональности не обновляются на сервере.
c. Они не очистили кеш браузера.
d. Я копирую проблему на промежуточном сервере и демонстрирую ее им.
e. ... и так далее, в зависимости от случая.
Попытайтесь воссоздать пользователя, который обнаружил систему ошибки в максимально возможной степени: от конфигурации сервера до конфигурации компьютера, включая браузер и ОС, и тому подобное. Вероятно, у вас должно быть несколько различных настроек для тестирования вашего приложения перед выпуском.
IE Tester - хороший инструмент для устранения неполадок такого рода. Если вам нужно протестировать множество браузеров, то вам лучше всего подойдут виртуальные машины, такие как Virtual PC, поэтому на вашем тестовом сервере вы можете установить множество настроек клиента.
ах да ... самое старое оправдание в книге.
Предполагая, что и разработчик, и тестировщик проводят тестирование на одном сервере, я бы попытался выделить ошибку, определив, что Разница между машиной разработчика и машиной тестирования. Это может быть что-то незначительное, например, флэш-версия, различия в браузерах или забыть очистить кеш браузера
. Я бы также рекомендовал использовать автоматизированную среду тестирования и тестировать приложения на выделенном тестовом сервере.
Вы не можете многое сделать как конечный пользователь, но как разработчик вы можете избежать многих из этих проблем, включив большое количество входов в систему. Различия, о которых подумает пользователь просто будьте простыми вещами, которые вы уже тестировали, но хорошая регистрация позволяет вам точно видеть, что происходило, когда система выходила из строя. Я нашел немало ошибок, которые не могли бы произойти таким образом.
Мы решаем эту проблему, располагая средой разработки поверх локальной разработки, максимально приближенной к продуктивной системе с точки зрения настройки, оборудования и т. Д. В результате почти все проблемы, возникающие в производственной среде, воспроизводимы в этой системе разработки, даже если они не могут быть воспроизведены на локальных машинах разработчика.