Каждый раз, когда мне нужно исправить ошибку, я следую одному и тому же рабочему процессу: когда кто-то из группы QA обнаруживает ошибку, он / она отправляет мне отчет об ошибке с инструкциями по воспроизведению (STR) проблемы. И если я не понимаю STR, я обычно прихожу к нему / ему, чтобы он / она мог показать мне ошибку на своем компьютере.
Этот рабочий процесс кажется довольно распространенным во многих компаниях, и я часто говорю себе, что у него должен быть лучший способ получить контекст приложения до того, как произойдет ошибка.
Динамическое объединение
Но что может быть лучше? В идеале было бы здорово сделать снимок приложения до того, как возникла ошибка, чтобы мы могли исправить проблему из этого состояния.
Например, предположим, что у нас есть приложение в желаемом состоянии, и мы можем сохранить это приложение в формате, который затем можно загрузить для восстановления этого состояния. Конечно, исправление будет быстрее и проще.
Фактически, новый рабочий процесс может быть примерно таким:
В этом примере у нас есть приложение todo (базовое приложение TodoMVC) в определенном контексте (с одной задачей). Мы экспортируем контекст приложения в пакет (строковый объект JSON), открываем новую пустую страницу и затем устанавливаем этот пакет. Затем мы видим, что наше приложение работает на новой странице с правильным контекстом. Итак, мы можем начать использовать приложение из этого контекста.
Это означает, что как разработчику мне нужно будет только загрузить JSON, который кто-то из команды QA отправит мне, чтобы получить контекст приложения и исправить эту ошибку. Гораздо проще, правда?
Как это работает?
В видео мы можем экспортировать состояние этого приложения и восстановить его во время выполнения, потому что:
- приложение было разработано как система и
- объекты приложения (компоненты, методы, модели) во время выполнения хранятся в крошечной базе данных NoSQL.
Ваше приложение - это система
Когда мы создаем приложение, мы фактически создаем систему. Система определяется моделью, состоит из компонентов и реагирует на события поведением. Как видите, эти концепции довольно часто встречаются в приложениях, которые мы создаем каждый день.
Так чем же отличается система от приложения? В случае систем мы сначала сосредотачиваемся на дизайне, а затем на коде. Как это сделать ?
- Сначала спроектируйте модель вашей системы,
- затем найдите все компоненты, которые понадобятся вам для запуска системы, и
- затем создайте эти компоненты и реализуйте их поведение (с помощью методов).
Вам необходимо провести полное различие между дизайном и временем выполнения вашей системы. Дизайн всегда должен быть декларативным и обязательным. Как это сделать? Используйте UML, чтобы определить вашу модель и интегрировать ее в рабочий процесс разработки.
Все это документ
Когда система будет готова к запуску, нам нужно сохранить ее в базе данных NoSQL. Это возможно, потому что всем, что вы создали, можно управлять как документом. Допустим, мы хотим сохранить объект в базе данных, нам нужно сериализовать его в JSON, но если мы сохраним только его состояние, этот процесс будет проще. И это то, что показано на видео. Модели и поведения также сериализуются, поэтому вся система хранится в базе данных.
А что насчет времени выполнения? Что, если мы обновим объект в текущем приложении? Поскольку все состояния объектов хранятся в базе данных, у нас есть полный ODM (Object-Document Mapper). Это означает, что обновление объекта системы автоматически обновит его состояние в базе данных.
Итак, теперь экспорт текущего состояния системы похож на создание дампа базы данных. А восстановление состояния системы похоже на импорт дампа в базу данных. Довольно просто, не правда ли?
Хотите узнать больше?
Я буду развивать концепции и шаблоны, о которых я говорил в следующем посте, но если вы хотите создать несколько систем прямо сейчас, вы можете:
- установить System Runtime, библиотеку JavaScript для создания и управления системами и
- прочтите книгу Донеллы Х. Медоуз Системное мышление. Отличное введение в мир систем.
