Серия мастеров "Front-end" (1): Что должен делать квалифицированный мастер? Техническая команда JD Cloud

Автор: JD Retail Лю Вэйдун

Эта статья является первой в серии статей и представляет собой краткое введение, цель которого состоит в том, чтобы позволить фронтенд-практикам и непрактикам, интересующимся этой областью, иметь беспороговое понимание темы «фронт- конец".

«Что такое фронтенд-функция»

Говоря о «внешнем интерфейсе», Википедия позиционирует эту техническую роль так: «внешний интерфейс (англ. Front-end) и бэк-энд (англ. Back-end) — это общие термины, описывающие начало и конец процесса. Внешний интерфейс занимается сбором входной информации, внутренней обработкой. Стиль интерфейса и визуальное представление компьютерных программ относятся к внешнему интерфейсу». прозрачный. Внешний интерфейс — относительное понятие по отношению к внутреннему, и его рабочая роль должна уделять больше внимания двум частям «сбора и представления».

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

«Что включает в себя кодирование?»

Заинтересованные стороны переднего отдела исследований и разработок включают дизайн продукта и пользовательского интерфейса, а необходимые входные данные включают документацию по продукту и рукописи дизайна пользовательского интерфейса. код реализации логической обработки.

Продукт должен выдавать PRD (аббревиатура от Product Requirement Document) команде R&D для подробного описания конкретных функциональных деталей продукта или итерации, а также проводить «языковой анализ» с персоналом R&D и дизайнерами на совещании по обзору требований. и перевод», который может четко выразить всю логику продукта для разных специалистов, что является наиболее важным звеном в доставке всех требований. Для новых или сложных требований дизайнерам взаимодействия и персоналу по продукту необходимо совместно выводить рукописи дизайна взаимодействия, чтобы объяснить логику требований к продукту из другого измерения. рукописи Строгость и качество очень важны.

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

Связь с внутренним персоналом НИОКР является главным приоритетом в работе НИОКР.В конце концов, набор пакетов кода, распознаваемых внешним и внутренним персоналом НИОКР, которые прошли самопроверку использования курения случаев является квалифицированным выходом на этом этапе. Спецификации интерфейса, соглашения и партнеры по стыковке с высокой степенью молчаливого понимания — это идеи, которые отрасль продолжает повышать эффективность и снижать затраты в процессе отладки НИОКР, совместной отладки и дымового тестирования. «Все зависит от людей» и «согласие важнее привычки» — все они выдвигают требования к мягкой силе и строгости процесса.

Последним шагом в процессе НИОКР является переход в режим онлайн после принятия UAT. Для выхода в онлайн необходимо использовать метод «конвейерной автоматизации», который все часто называют «CI/CD». Только так мы можем гарантировать, что код основной версии полностью соответствует версии кода онлайн, и что основная ветвь не станет украшением, потому что локальный код скомпилирован и упакован искусственно и выпущен онлайн; все слияния, связанные с онлайн, компиляция, упаковка. Основные процессы, такие как публикация, — это все сценарии, которые автоматически запускаются конвейером и заранее развертываются на каждом узле конвейера, чтобы избежать онлайн-проблем, вызванных человеческими «ошибками».

"На линии?"

Выход в онлайн — это тема, которую стоит обсудить, потому что для НИОКР только коды, которые выходят в онлайн и имеют ожидаемую или превышенную ценность для бизнеса, могут рассматриваться как вносящие небольшой вклад в компанию и общество, а личная ценность может отражаться на работе. Является ли завершение онлайн-разработки окончанием научно-исследовательских и опытно-конструкторских работ? Для многих R&D команд это последний шаг. Однако на этом процесс НИОКР только останавливается и не соответствует стандарту «квалификации». Набор кода, только после того, как он выйдет в сеть, может быть протестирован и использован реальными пользователями, а результат работы сотрудников НИОКР можно считать «началом жизни». При использовании пользователем функции продукта, "соответствует ли производительность ожиданиям", "есть ли граничное исключение", "есть ли ситуация, при которой страница не может быть открыта", "есть ли ненормальная ситуация отображения", и другие вопросы должны быть результатом исследований и разработок Темы, требующие внимания.

Поэтому персонал отдела исследований и разработок должен заранее зарезервировать в пакете кода возможность «общения» с реальными онлайн-пользователями и принять меры по улучшению, которые могут улучшить пользовательский опыт, анализируя «удобство использования и производительность» пользователей, например, «специальная настройка логики». Отчеты о скрытых точках», «мониторинг границ», «мониторинг времени работы системы» и т. д., только когда они будут выполнены, можно будет сказать, что функция пользователя действительно запущена, и в будущем появится возможность уточнения работы. Однако для многих разработчиков «онлайн — это конец спроса», «онлайн-проблемы возвращаются бизнесом», «есть ли жалобы клиентов?» — все это обычная психология в НИОКР.

Так как же наладить канал связи с пользователями «заранее определенным» способом? Поскольку эта статья посвящена интерфейсу, на этот раз мы говорим только о интерфейсе.

«Общение с пользователями»

Эффективная коммуникация требует эффективной информации в качестве носителя. Для технической реализации необходимо разумно похоронить основные блоки кода. Когда происходит особое поведение пользователя, когда логика обработки кода переходит к ненормальному блоку обработки, когда возникает ситуация, которая не охвачена логикой обработки кода, код сообщения о скрытой точке инициирует выполнение и отправляется в централизованную службу скрытой точки Отправить сообщение. Благодаря анализу информации о скрытых точках, вызванной таким поведением пользователя, технические специалисты могут получить «воспроизведение на месте» «нормальной или ненормальной» ситуации пользователя в процессе просмотра или работы со страницей. повторение может быть информацией о данных , а также снимками экрана или возвратом видео. Конкретный метод воспроизведения поведения пользователя должен быть «эффективным» в качестве цели, а также такими факторами, как «стоимость пользовательского трафика, затраты на исследования и разработки, влияние на производительность и объем хранилища». Стоимость» следует учитывать, чтобы сделать окончательный выбор.

«В режиме реального времени ИЛИ T+1»

Для мониторинга поведения пользователей бизнес-интерфейса и логики триггеров существует два типа мониторинга в реальном времени и асинхронный мониторинг.

В таких сценариях, как внимание в реальном времени к поведению пользователя и анализ в реальном времени, необходимо использовать мониторинг в реальном времени.Этого «реального времени» обычно достаточно на втором уровне, а также можно использовать минутный уровне для некоторых услуг, в зависимости от потребностей бизнеса. Для мониторинга в режиме реального времени поведение отчетов запускается и сообщается с устройства каждого пользователя.Для предприятий с большими объемами сбор, создание отчетов, сбор, хранение, анализ и создание отчетов такого объема данных являются довольно дорогостоящими.Ресурсы. Чтобы сократить расходы и повысить эффективность, служба скрытых точек сначала будет производить выборку пользовательских данных в соответствии со специальными правилами (такими как нормальное распределение), чтобы уменьшить потребление ресурсов и рабочей силы в процессе анализа и создания отчетов.

В таких сценариях, как запрос журнала на стороне пользователя, повторение особых граничных сценариев, а также устранение неполадок и обнаружение ошибок в журнале, "в реальном времени" не требуется. В этом сценарии обычно используется запрос T + 1, но тема периода хранения вводится большое количество журналов уровня. , общих пользовательских журналов уровня предприятия достаточно для сохранения в течение 14 дней, потому что для журналов C-стороны речь идет больше о повторении, обработке и отслеживании сбоев на месте. , Если стратегии алгоритма нужны пользовательские журналы, необходимо обрабатывать пользовательские журналы только один раз в течение определенного периода времени с помощью задач обработки и хранить ключевые данные, такие как выходные метки и характеристики поведения. освободите ресурсы, чтобы предоставить более ценные последние журналы.

Подводя итог, можно сказать, что мониторинг в реальном времени и мониторинг не в реальном времени соответствуют двум сценариям: в реальном времени, соответствующему «доступности службы, исключениям во время выполнения в сети» и другим требованиям использования, и не в реальном времени, соответствующему «показателям производительности, запрос журнала пользователя, повторение поведения пользователя» и т. д. Используйте требования.

"следовать за"

После этого я продолжу говорить о некоторых темах, связанных с «пользовательским опытом, повышением эффективности и созданием страниц».

{{о.имя}}
{{м.имя}}

Acho que você gosta

Origin my.oschina.net/u/4090830/blog/8704612
Recomendado
Clasificación