Как фронтенд-архитектор, делайте все с нуля (1)

0. Предварительное резюме

0.1 Фон

Мне надоело работать сверхурочно в Али, поэтому следующей остановкой в жизни я выбрал государственное предприятие.

Как мы все знаем, в сегодняшнем Китае, несмотря на некоторые нестыковки, есть только две самые прибыльные отрасли, то есть IT и финансы.

Так вот, умный я, раз я уже работал в IT, то конечно дальше буду работать в финансовой сфере...! - О нет, это ИТ в финансовой сфере.

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

0.2 Текущая среда

Это трастовая компания и государственное предприятие.

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

Когда я впервые пришел в эту компанию, я столкнулся с беспорядком, оставленным моим бывшим. В частности, есть следующие:

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

В частности, поговорим о проблемах, связанных с этим фронтенд-инжинирингом:

Доступ ко всем внутренним интерфейсам является междоменным.С одной стороны, внутренняя часть открыта для междоменного доступа. С другой стороны, при доступе к внутреннему интерфейсу путь, используемый внешним интерфейсом, является абсолютный путь;
Существует четыре среды (разработка/тестирование/подготовка/производство), и при упаковке в разные среды необходимо выполнить четыре разные команды (помните первое правило, URL-адрес интерфейса абсолютного пути), то есть четыре виды пакетов;
Нет автоматического развертывания (т.е. CI/CD), нужно вручную запаковать, потом скопировать код, (антивор: автор: ноль и ноль вода, вичат: qq20004604) залить на разные сервера через фтп. Так легко злоупотреблять;
В основном ничего другого.

В общем, просто бардак и похвалить нечего.

Единственное, что повезло, так это то, что с поддержкой руководителей все в порядке.Хотя я могу набирать только аутсорс-разработку, право набирать людей полностью делегировано мне.Я сказал, если хочу, то наберу.

0.3 Предыдущий блог

В мае 2019 года я написал 8000-словную статью «Об архитектуре фронтенда крупномасштабных проектов», когда «Наггетс» в свое время поднялись на третье место в списке истории (кумулятивный показатель близок к 12w, а лайков 3500+). Однако некоторые люди сообщали, что они считают это немного поверхностным и не имеют конкретных методов реализации.

Но это еще более поверхностно, это было 8000 слов, эта статья относительно предыдущего блога, уточнение говорит о еще нескольких, я прошелся по этому предложению, наверное, было 8000 слов. .

Так что дело не в том, что я не хочу говорить немного глубже, а в том, что я хочу написать немного глубже. В каждом пункте может быть более 8000 слов. Я старался изо всех сил.

1. Решить устаревшие проблемы

1.1 Настройся

Прежде чем что-то делать, нужно иметь четкое представление. Несколько принципов:

обеспечить существующую устойчивость;
Сначала делайте вещи с низкими затратами и высокой производительностью;
Считайте долгосрочные затраты как можно более низкими;

В свете вышеизложенного делаю вывод:

Самое главное — человеческий фактор;
Второй — определить приоритет проблемы и решать ее поочередно;
Последнее — ежедневно создавать и оптимизировать интерфейсную техническую систему и пытаться улучшить качество кода каждого с помощью инструментов и спецификаций.

Хотя я могу решить все вышеперечисленные проблемы сам и сделать это хорошо, я не могу написать все проекты сам. Неважно, насколько я способен, по мере расширения команды предельная выгода неизбежно будет уменьшаться.

1.2 Знакомство с членами команды

Поэтому я сначала общаюсь с каждым одноклассником индивидуально, чтобы понять их мысли и личную ситуацию, и подготовиться к следующему действию.

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

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

[хорошо, решение человеческих проблем]

1.3 Приоритетный анализ

Проанализируйте и оцените существующие проблемы:

вопрос	строгость	Стоимость ремонта
изменение интерфейса	Высокий, сильно влияет на прогресс	Низкий, если он хорошо скоординирован с серверной частью
Отсутствует CI/CD	середина	Низкий, нужно написать скрипт для автоматической синхронизации кода с gitlab
некачественные строительные леса	середина	Среднее, большое влияние на старые проекты
Междоменный интерфейс	высоко	В существующем коде новый проект низкий
Код члена команды не стандартизирован	высоко	высоко, нужно время
забыл перечислить	*	*

[Существующие вопросы уточняются]

1.4 Уточнение задач архитектора

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

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

Итак, разделите свои собственные задачи на следующие три категории:

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

Я хочу коснуться вышеперечисленных трех аспектов, которые могут не только решить существующие проблемы, но и обеспечить поддержку в долгосрочной перспективе.

【Четкое направление】

Итак, я приступил к работе, и на следующую работу ушло 4 месяца.

2. Проектирование инфраструктуры

2.1 Внешний конвейер

Основой проектирования инфраструктуры является проектирование процессов. Хороший процесс может работать эффективно и с минимальными затратами, и в то же время с помощью процессизации можно избежать большого количества проблем.

Базовая схема процесса выглядит следующим образом:

В этом процессе код делится на три слоя: [персональный код — код основной ветки — онлайн-код], а онлайн-код делится на три версии: dev, qa и pro.

Разработчики контролируют только личный код и не могут напрямую влиять на изменения в коде основной ветки.Когда им нужно отправить в основную ветку, им нужно инициировать запрос на слияние, и после того, как администратор проверит код, код сливается в основная ветвь.

Код основной ветки изолирован от онлайн-кода (антивор: автор: ноль и ноль вода, вичат: qq20004604) администратором для выпуска указанной версии кода в указанную среду. Независимо от того, какой это dev, qa или pro, указанный коммит будет извлечен непосредственно из gitlab, а затем упакован и выпущен.

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

Благодаря описанному выше процессу интерфейсный код может гарантированно работать на стороне сервера с высоким качеством и высокой стабильностью.

2.2 Контроль версии кода

В традиционных проектах с разделением front-end и back-end код front-end обычно развертывается независимо самим front-end.После того, как пакет завершен, он развертывается непосредственно в указанном каталоге. Но у этого процесса есть несколько серьезных проблем:

Проблема с кешем: чтобы повысить скорость доступа пользователей и уменьшить нагрузку на трафик, вызванную загрузкой ресурсов, мы обычно кэшируем статические ресурсы внешнего интерфейса. Но недостаток в том, что когда нам нужно выпустить или откатить версию, неизбежно, что пользователи будут обращаться к кешированным статическим файлам.
Медленный выпуск версии и откат: в традиционных решениях код выпуска необходимо переупаковывать каждый раз, когда его нужно выпустить или откатить. (Автор: Zero Zero | Water, wechat: qq20004604) С одной стороны, этот процесс относительно медленный, с другой стороны, он может быть не точно упакован в конкретную подачу (неаккуратно).

Поэтому, согласно фактической ситуации, используйте саморазвиванную интерфейс управления питанием. Ядро имеет следующие моменты:

Управление версиями кода: для кода, который необходимо отправить на онлайн-сервер, добавьте к нему тег в gitlab, и только код с правильным тегом будет упакован и опубликован в Интернете. Ключ к этой операции лежит в статических файлах ресурсов, таких как css и js, с номером версии в качестве каталога папки, и несколько версий существуют в сети одновременно. HTML не кэширует и в качестве записи вводит разные версии. Пример каталога выглядит следующим образом:

На уровне nginx html обрабатывается без кеширования, и при каждой загрузке загружается самый последний. Остальные статические ресурсы кэшируются, а срок действия составляет 15 дней.Процесс публикации показан на рисунке выше. При переключении версий детали следующие:

2. Сосуществование нескольких версий: Из-за относительно небольшого размера ресурса самого статического файла (поскольку общедоступный статический файл извлекается, он на самом деле меньше), (Автор: Zero|Zero Water). В настоящее время вторая фаза Fortune только 16 МБ после упаковки, а следующие два После субоптимизации он упадет примерно до 10 МБ. Таким образом, даже если на сервере размещается несколько версий одновременно, это не занимает много места.

Метод управления заключается в том, что html-файл, используемый в качестве записи, уникален.Путем изменения номера версии статического файла ресурсов, на который указывает в html, указывается номер версии, к которой в настоящее время обращается пользователь. Блок-схема доступа пользователей выглядит следующим образом:

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

Однако html не выполняет обработку кэша, что может помешать пользователям получить доступ к страницам старой версии после выпуска новой версии, что приведет к ненормальной деловой обработке.

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

2.3 Частные источники npm

Так как мы обычно обращаемся к внутренней сети, нам нужно рассмотреть проблему изоляции между внутренней и внешней сетью в будущем. Поэтому соберите приватный исходник npm и заранее решите задачу с уровня базового дизайна. Частный источник использует технологическое решение с открытым исходным кодом Verdaccio. Преимущества заключаются в следующем:

Легкий: verdaccio разработан на основе Node.js, занимает меньше ресурсов, быстро работает и легко настраивается, что подходит для реальной ситуации в нашей компании;
Низкая сложность конфигурации: вы можете быстро настроить группы пользователей, разрешения, рабочие порты, адреса хранения и т. д., которых достаточно для общих сценариев;
Обеспечьте стабильность версии зависимостей: по сравнению с размещением зависимостей на сторонних удаленных источниках более стабильно размещать их локально, с одной стороны, это может повысить скорость загрузки (поскольку некоторые сторонние зависимости нестабильны для подключения к внешним сети), с другой стороны, он может гарантировать, что зависимости всегда существуют (кешируется в локальный частный источник npm);

Благодаря сочетанию трех вышеперечисленных пунктов на архитектурном уровне решается проблема неопределенности опубликованного онлайн-кода и повышается надежность внешнего кода.

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

2.4 Кэш общедоступных статических ресурсов

В дополнение к бизнес-коду во внешнем интерфейсе будут некоторые общедоступные статические ресурсы, такие как файлы Vue js, файлы ресурсов ElementUI, файлы ресурсов Echarts и некоторые файлы изображений.

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

Поэтому, установив публичный статический путь и настроив его в скаффолдинге, когда вам нужно загрузить эти ресурсы, прямо укажите статический сервер nginx для загрузки и сделайте долгосрочный кеш, что может повысить эффективность доступа и производительность.

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

2.5 Другие

Все вышеперечисленное реализовано, и есть еще кое-что, но они слишком тривиальны - собственно, основная причина в том, что я больше не могу это писать, поэтому писать не буду.

3. Инженерный проект

3.1 Кастомный каркас веб-пакета

Чтобы улучшить качество кода при низких затратах и высокой эффективности, исходя из реальной ситуации в компании, был разработан индивидуальный каркас веб-пакета для решения следующих проблем:

Избегайте неограниченного внедрения сторонних библиотек: неограниченное внедрение сторонних библиотек — это поведение, которое часто упускается из виду, но может легко вызвать проблемы (например, vue + jquery и т. д.). Поскольку разработчики обычно не читают исходный код сторонних библиотек, нет гарантии, что они безопасны и надежны. Пользовательские скаффолдинги предоставляют все зависимости, необходимые для разработки, и строго контролируют введение новых зависимостей, чтобы обеспечить безопасность всего проекта. (Противоугонное: wechat:qq20004604)
Ограничивайте спецификации кода разработчика. Наиболее распространенная проблема при разработке заключается в том, что спецификации кода хаотичны, каждая написана отдельно, что приводит к высоким затратам на обслуживание. Эти проблемы решаются введением eslint, форсированием стиля кода и автоматическим сообщением об ошибках в коде, который не соответствует спецификации. А так как IDE поддерживает автоматическое форматирование кода путем применения правил eslint. Это также снижает стоимость ограничений для разработчиков и снижает сложность реализации спецификаций кода.
Удобно предоставлять другим разработчикам стандартную основу и оказывать техническую поддержку (например, технологический стек, который может унифицировать интерфейс).

Скаффолдинг, который я использую, — это мой собственный каркас vue, основанный на конфигурации webpack5, который содержит различные конфигурации.

3.2 Встроенная консоль отладки

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

Как показано ниже, нажмите кнопку тестирования, форма будет заполнена автоматически:

Благодаря встроенной консоли отладки у вас есть следующие преимущества:

Уменьшение неэффективного поведения повторяющихся операций: автоматическое заполнение форм является наиболее распространенным сценарием. Когда требуется бесконечная выпадающая загрузка, также можно напрямую загрузить указанный номер страницы или увеличить количество загрузок на страницу, чтобы данные определенной страницы можно быстро получить без необходимости модификации бизнес-кода;
Дополнительные сведения об отладке: по сравнению с использованием пользователем иногда необходимо отображать больше информации на странице во время разработки, но изменять исходный бизнес-код не слишком элегантно. Так что включайте и выключайте отображение этих дополнительных сообщений через консоль отладки. А поскольку он по умолчанию закрыт и независим от локальной среды, его также можно использовать при онлайн-отладке;
Онлайн-отладка: после добавления системы скрытых точек в будущем, когда пользователь столкнется с ненормальной ситуацией, которую невозможно воспроизвести, вы можете научить пользователя открывать консоль отладки, а затем нажать кнопку, чтобы активировать исторические операции пользователя. Затем вы можете проанализировать поведение пользователя на стороне сервера, чтобы увидеть причину проблемы.

3.3 Многостраничный дизайн ведущий-ведомый

Для реальных бизнес-потребностей компании — workbench — основная платформа, подключаются другие страницы, а backend — микросервисный дизайн. Поэтому идея дизайна заключается в многопроектном многостраничном управлении master-slave. В частности, это следующие моменты:

Мульти-инжиниринг: учитывая, что в будущем мы развернем рабочее место в качестве ядра и мультисистемного доступа. Таким образом, фронтенд-проект разделяется, при этом верстак является основной записью, а затем истории, разработчики, системы и т. д. делятся на несколько мелких и средних фронтенд-проектов. Благодаря такому разделению снижается сложность разработки и обслуживания кода, а также снижаются затраты на сотрудничество между различными разработками историй;
Несколько страниц: для проекта долгосрочного обслуживания необходимо учитывать сложность долгосрочного обслуживания. Поэтому, в сочетании с моим предыдущим опытом хождения по ямам и ведения исторических проектов, страница фронтенда оформлена как многостраничный режим. В частности, каждая история делится на разные страницы в соответствии с функциональными точками, а обмен данными между страницами осуществляется с помощью локального кеша, параметров браузера и т. д. Благодаря такой изоляции независимо от того, требуется ли последующее действие добавить новые функции на новые страницы, реконструировать одну страницу или опробовать новые технологии на новых страницах, затраты будут очень низкими;
Управление «ведущий-ведомый»: техника вмешательства. Если на верстаке нужно открыть другие страницы, их нужно предварительно зарегистрировать и вызывать для открытия через id страницы. Таким образом, посредством централизованного управления можно запретить сторонним веб-страницам открывать нелегальные страницы на рабочем месте, а также повысить безопасность системы;

Благодаря такому дизайну традиционные крупномасштабные интерфейсные проекты делятся на микроинтерфейсные проекты, аналогичные внутренним микросервисам, что повышает эффективность разработки, особенно эффективность параллельной разработки. Управление разрешениями также улучшено для обеспечения безопасности кода.

Конкретная структура конструкции выглядит следующим образом:

Поток взаимодействия между ними выглядит следующим образом

Как бы вы не отставали, но поскольку он перенаправляется через nginx, на поверхности пользователь получает доступ к одному и тому же URL-адресу, что не влияет на познание пользователя.

4. Управление командой

4.1 Контроль разрешений

Разрешения здесь в основном относятся к управлению правами на код, и цель состоит в том, чтобы гарантировать, что код безопасен, а проблему можно контролировать, чтобы избежать отслеживания.

Конкретные меры управления заключаются в следующем:

Гарантия стабильности версии зависимостей: код принадлежит компании, поэтому на основе gitlab код изолирован по разрешениям, все права доступа закрыты по умолчанию, и для каждого проекта на разработку даются указанные разрешения в соответствии с реальными потребностями. . Это может избежать потери имущества компании из-за утечки кода;
Разрешение на фиксацию: разрешить отправку разработки в отдельную ветку, но когда речь идет о слиянии основной ветки, слияние должно быть отправлено, а затем лидер группы может отправить его в основную ветку после проверки кода. В таком виде код основной ветки должен быть управляемым и не будет создавать серьезных проблем;
Разрешения на публикацию: для публикации кода в dev, qa и pro разрешения конвергенции назначаются лидеру группы, и только лидер группы может публиковать. Преимущество в том, что, с одной стороны, он может предоставить надежную и контролируемую версию онлайн-кода, а с другой стороны, снижает требования к навыкам разработчиков.

4.2 Управление стыковкой внешнего и внутреннего интерфейсов

В октябре-ноябре прошлого года была серьезная проблема в совместной отладке front-end и back-end разработки, то есть при изменении back-end интерфейса соответствующие front-end разработчики и тестировщики раньше не уведомлялись и после мероприятия. Эффективность разработки очень низкая, и будут возникать различные нештатные ситуации.

Поэтому, разбираясь в процессе разработки, для бэкэнда обязательно предоставлять документы интерфейса впереди, а в качестве стандарта стыковки требуется контролируемый и стабильный документ интерфейса.

После декабря, по приблизительным оценкам, количество ошибок и проблем с блокировкой разработки и тестирования, вызванных временными изменениями в интерфейсе, уменьшилось на 80%.

Однако на практике все еще будут некоторые интерфейсные документы, которые не соответствуют реальному интерфейсу, в результате чего интерфейсный тест будет вынужден переделывать.Далее нам нужно попытаться уменьшить количество таких проблем.

4.3 Управление персоналом

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

Практические вопросы для вступительного собеседования: сочетайте теоретические вопросы и практические деловые вопросы, чтобы гарантировать, что новобранцы действительно понимают развитие бизнеса и избегают рисков для персонала. После прохождения предварительного собеседования договоритесь о письменном тесте с небольшим объемом кода, но с определенной степенью сложности, чтобы проверить способность решать проблемы и в то же время проверить отношение.
Помощь наставника: после того, как новый человек придет, назначьте человека, который возьмет его, ответит на общие вопросы и сделает с ним историю. По сравнению с непосредственным управлением обучением руководителем команды, это более способствует интеграции новых членов в команду; (антивор: Автор: Zero Zero Water, wechat: qq20004604)
Адаптация к новичкам. Общая проблема новичков заключается в том, что они не понимают своего позиционирования. Таким образом, руководитель группы отвечает за организацию направления развития новых участников, и в первую неделю после вступления новых участников сначала организует их для разработки системы ежедневных отчетов, понимания строительных лесов, а затем организует их для оптимизации существующие страницы, чтобы помочь им понять истории, за которые несут ответственность разные люди;
Ответственность Ясность: Четко определите роль каждого в команде и сделайте ее известной. В соответствии с различными способностями и отношением членов команды организуйте подходящие для них задачи. Например, Ченг Ясюй отвечает за простые страницы и истории самопроверки, Ма Цянь отвечает за основные бизнес-истории, а Ван Чао отвечает за контент, требующий определенных технологических инноваций;

5. Планы на будущее

На самом деле, я сделал еще кое-что, но из-за нехватки места пока не буду их писать. (В основном потому, что я больше не могу это писать, они писались уже неделю~~)

1. Сервер ресурсов статических изображений:

На данный момент картинки запакованы в проект, но этот минус в том, что проект слишком тяжелый, с последующей нагрузкой на сервер nginx. Поэтому в будущем необходимо рассмотреть возможность создания выделенного сервера статического ресурса, после загрузки он будет автоматически загружаться в CDN, а ссылка на изображение на CDN будет возвращена. Затем вы можете напрямую ввести ссылку на изображение на странице;

2. Бэкенд-слой отображает html:

Это направление моей будущей работы. По сравнению с текущим HTML-рендерингом nginx, лучший выбор — бэкэнд-рендеринг html. Преимущества следующие:

Снизить нагрузку на сервер nginx;
Релиз версии, от необходимости ручного выполнения скриптов для замены html, до изменения версии внешнего кода только путем изменения конфигурации;
Вы можете внедрить некоторые общедоступные js и css в виде промежуточного программного обеспечения, такого как скрытые js и т. д.;
Может решить проблему csrf;
Строго ограничить доступ в Интернет;

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

gitlab интегрирует eslint:

По сравнению с требованием, чтобы разработчики сами проверяли качество кода, даже если eslint передается по наследству, эффект не самый лучший. Поэтому лучше всего интегрировать eslint в CI/CD. При разработке и отправке кода в gitlab автоматически выполнять eslint для проверки кода и автоматически перезванивать, если проверка не удалась;

Система погребенных точек:

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

CSRF:

Безопасность финансовой системы очень важна, помимо обычного предотвращения xss-инъекций, необходимо также предотвращать CSRF-атаки (подделка межсайтовых запросов). Решение состоит в том, чтобы использовать csrf-токен, чтобы избежать этого.

конец:

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

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

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

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