Baidu: как разработать устойчивые компоненты из процесса

внешний интерфейс JavaScript

Фронтенд заранее заболтал конференцию и провел ее совместно с Наггетс. Добавьте codingdreamer в техническую группу конференции и побеждайте на новом стартовом рубеже.

27-е | Front-end Flutter Session, Узнайте о механизмах веб-рендеринга | UI Frameworks | Оптимизация производительности, прямая трансляция с 18:00 до 17:00, 6 лекторов (JD/Manbang/Xianyu и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):

image.png

Все предыдущие серии полностью записаны и транслируются.Начните и разблокируйте все сразу

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

Эта статья шестнадцатая - фронтальный чат раннийСессия компонентизации, также является 111-й сессией раннего чата, от обмена Baidu-Чжэн Лянлян.

1. Общая сводка (tl;dr)

Этот обмен направлен на обсуждение ""устойчивое обслуживание" вопрос.

Основное содержание описывается в следующей структуре:

  • объяснить предысторию & бросать вопросы: Базовое введение в ситуацию внутри команды
    • Представлено «Исследование и разработка сложных систем, предполагающих многостороннее сотрудничество».неуправляемая проблема";
    • Обеспечьте концептуальное понимание «неизбежногоУвеличение энтропии» и что мы должны сделать «во что бы то ни сталоСнижение энтропии";
  • Техническая ветка (обеспечивает основу для обсуждения): Дайте некоторое представление о технической конструкции, прежде чем переходить к фактическим нетехническим (документация и процессы) решениям.
    • при условииплан строительстваИдея (концепции, которые необходимо осветить в документации, будут представлены позже);
    • И дайте несколько дополнительных, которые могут обеспечить способность «снижения энтропии».средства технической поддержки;
  • Нетехнические линии (основные темы для обсуждения): Знакомство с «нетехническими проблемами и решениями», которые легко упустить из виду (Темная сторона Луны).
    • использоватьПример моделирования реальной работыобъяснить проблемы и проблемы, с которыми мы столкнулись;
    • пройти черезосновные инструменты,Документ осадки,Операционный потокТри аспекта, чтобы предоставить некоторые идеи в максимально возможной степени.

2. Кому может быть полезен этот обмен?

  • Если вы отвечаете (или работаете в качестве руководителя группы) за разработку библиотеки компонентов группы внешнего интерфейса
    • Кроме того, ваша библиотека компонентов доступна для использования несколькими линейками продуктов;
    • Более того, вы обнаружите, что в работе библиотеки компонентов есть много «магических изменений» и «дифференциации версий», и вы очень обеспокоены этим;
    • тогда это совместное использование может относиться к вам;
  • Если вы закончили роль, но не обнаружили этой проблемы или не заморачивались по этому поводу
    • Тогда есть три возможности:
      • а) Возможно, вы не сталкивались с вышеперечисленными проблемами, поэтому также рекомендуется пройти этот обмен;
      • б) Возможно, у вас уже есть свое собственное решение, если да, я надеюсь, что вы понимаете содержание этого обмена, вы можете просмотреть мой WeChat в конце, я очень надеюсь и рад услышать ваши решения и идеи;
      • в) Вы знаете об этой проблеме, но определили, что это не проблема или не требует решения, то рекомендуется прочитать часть перед "нетехнической строкой". Если вы все еще не считаете это проблемой, то, скорее всего, этот обмен не поможет.
  • Если ваша работа никак не связана с созданием библиотеки компонентов, но вы испытываете следующие ощущения от работы:
    • Для технической работы, которая требует сотрудничества множества людей, трудно достичь консенсуса на концепцию и не хватает чувства командной работы;
    • В ходе проекта трудно контролировать проект, например, вещи, которые необходимо сделать, расходятся и трудно сходятся;
    • Высокие затраты на коммуникацию со связанными совместными ролями, такими как повторное сообщение об аналогичных вещах, доработка из-за неясного общения и т. Д .;
    • Тогда вам может быть полезно прочитать это совместное использование (обсуждение некоторых идей и методов разработки с помощью библиотеки компонентов).

3. Отказ от ответственности и важные уведомления

  • Вторая ревизия после шаринга, убрать "отказ от ответственности" в шаринге, и закрепить здесь (поправка на тему шаринга);
  • Это личное действие, поэтому, если есть что-то неуместное, пожалуйста, не связывайте это с компанией, в которой вы работаете;
  • Из-за ограничений личного познания и опыта могут быть недостатки в обмене мнениями.Я надеюсь вдохновить других и вдохновить вдохновение;
  • Тема обмена не «охватывает все аспекты создания библиотеки компонентов», а в основном делится некоторыми идеями и навыками, связанными с «построением устойчивой системы библиотеки компонентов»;
  • Примечание. Эта рукопись основана на фактическом совместно используемом содержании, поэтому обычно в ней содержится пояснительный текст пары PPT (конечно, есть некоторые исключения, но их нетрудно определить);
    • Кроме того, я чувствую, что изображение PPT немного велико, пожалуйста, имейте в виду и поймите.

3. Обо мне

4. Основное введение

Условия бизнеса

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

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

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

Поскольку первоначальная разработка бизнеса и разработка библиотеки компонентов выполнялись одновременно, давление было относительно высоким, и некоторые вещи в первой версии были относительно грубыми. Поэтому в июне 2017 года, когда давление со стороны бизнеса ослабло, начался запуск версии 2.0.В это время началась погоня за качеством, и благодаря более запланированным и гарантированным инвестициям примерно в ноябре версия 2.0 была почти завершена. Когда версия 2.0 будет в основном завершена, она будет обновлена ​​до версии 2.1 и начнет заменять версию 1.0, а также продолжит синхронную оптимизацию некоторых вещей.

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

Итак, вот вопрос:Почему системная работа всегда заканчивается неконтролируемостью?

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

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

Так что же является источником увеличения энтропии? Он выводится из неограниченного дифференциального накопления. Разница возникает из-за некоторой случайности. Затем случайность исходит из когнитивной неопределенности каждого члена команды, а также неопределенности самого процесса. Следовательно, можно считать, что «неопределенность познания и процесса внутри команды» является фундаментальным источником увеличения энтропии.

Например, мы сейчас разрабатываем компонент типа календаря, и есть требование: использовать компонент для выбора даты. Затем при проектировании и реализации этого взаимодействия возникнет ряд подробных проблем, например, как сделать макет пользовательского интерфейса, как представить детали стиля пользовательского интерфейса и как насчет деталей взаимодействия для конкретной операции выбора?

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

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

Следовательно, накопление различий в этих деталях в конечном итоге приведет к несовместимым различиям версий. Поскольку количественные изменения в конечном итоге (могут) привести к качественным изменениям, результирующая разница «совершенно новых» версий почти несовместима.

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

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

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

В итоге вы получите очень интересное эволюционное дерево, похожее на эволюцию биологических видов, но в большинстве сценариев это не очень хорошо.

Одна из мыслей нашей команды после неконтролируемого периода: как сделать так, чтобы вся инфраструктура работала устойчиво?

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

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

Некоторые, вероятно, показать карту

Некоторые конструкции компонентов (подсчитано, что мир похож).

Тестовое покрытие и компоненты Демонстрационный сайт (подсчитано, что мир похож).

5. Техническая линия

Панорама проекта

Первая часть представляет собой введение технической линии.

Прежде всего, посмотрите на панораму, если не случайно, полки базовой библиотеки компонентов имеют почти одинаковую длину.

Во-первых, существует базовая лежащая в основе ответственность за создание набора инструментов R&D и Ci. Затем некоторые базовые логические библиотеки и нижележащие материалы образуют базовый слой, поддерживаемый сборкой верхнего уровня.

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

Ей соответствует еще одна строчка, «демонстрационный сайт», который библиотека компонентов должна иметь нативно, который делится на front-end и server-side.

эффект айсберга

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

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

Возьмем пример, с которым мы столкнулись в библиотеке компонентов, например, в библиотеке компонентов нам нужна общая библиотека utils, здесь выбор — lodash. В начале зависимости в библиотеке компонентов написать очень простоdependency: lodash.

Однако, поскольку мы надеемся сделать встряхивание дерева лучше, мы заменили его на другой пакет lodash-es, поэтому мы изменили его наdependency: lodash-es.

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

Однако мы обнаружили, что некоторые проекты всегда сообщали об ошибках при внедрении библиотеки компонентов, некоторые из-за отсутствия lodash-ов, а некоторые из-за более низкой версии, поэтому для того, чтобы библиотека компонентов сообщала о как можно меньшем количестве ошибок, мы изменили это кdependency: lodash.

Но мы также обнаружили, что если бы мы изменили его таким образом, мы фактически потеряли бы очень хорошуюДелайте техническую рекламуБолее того, если в проекте есть lodash, легко запаковать несколько копий одного и того же из-за проблем с версиями, что наносит ущерб объему сборки. Итак, мы положилиdependencyИзменить наpeerDependency. Однако в настоящее время его контроль версий будет достаточно ослаблен, и в процессе после установки вводится этап активной печати найденных проблем и распечатки URL-адреса справочного документа.

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

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

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

  1. метод построения программы;
  2. Средства технической поддержки.

план строительства

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

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

Но этого определенно недостаточно.Мы столкнулись с проблемой или требованием, и мы используем метод Spike, чтобы найти так называемое «решение».Хотя он может обеспечить возможности проверки на базовом функциональном уровне, это только демонстрационный уровень. после всего.

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

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

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

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

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

Предвосхищая, эти две цифры будут повторно упомянуты позже, чтобы объяснить другие вещи.

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

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

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

Схема Строительство Метод: Пример конструкции фундамента

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

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

Поэтому мы приняли модель разработки с субподрядом (Monorepo), а в решении с субподрядом использовалась Lerna, относительно зрелое стороннее решение.

Согласно этой идее, каждый компонент является подпакетом, каждый подпакет имеет свою независимую версию, а затем некоторые подпакеты объединяются по определенной логике и объединяются в Bundle (объединенный пакет), например основной , объединенный пакет также имеет свою автономную версию.

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

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

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

Кроме того, поскольку мы находимся в форме субподряда и поскольку мы являемся библиотекой компонентов пользовательского интерфейса, нам необходимо поддерживать возможности настройки темы, поэтому нам нужно разделить логику и стиль (то же самое, что и Ant Design).

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

Далее, для представления пользователя одно из требований, которое мы получили в начале, заключается в том, что пользователь надеется, что в проект можно будет внедрить как CommonJS, так и ES. Поэтому в начале область построения делится на два режима: cjs и es.Продукты сборки пакетов выводятся в разные выходные (lib&es) папки, а затем указываются main и module в package.json.

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

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

Поэтому в процессе построения мы также синхронно выводим src, а затем присваиваем src типы в package.json. Потому что мы думали сказать, что src сам по себе является TS, и если он выводится вместе, пользователь может получить все типы TS библиотеки компонентов.

Тем не менее, мы обнаружили, что проблема была введена, то есть при введении SRC, хотя существует тип компонентной библиотеки, поскольку объединение представляет собой метод повторной экспорта, оно не является удобным для помощи кода IDE.

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

После расследования было принято другое решение, заключающееся в непосредственном создании src с помощью tsc.*.d.tsЗатем вывод в папку с именем types. Эти файлы представляют собой типы библиотеки компонентов, которые экспортируются в содержимое дистрибутива пакета, и указывают типы package.json на папку типов, чтобы пользователь мог правильно использовать функции IDE.

Однако это поднимает еще одну проблему опыта R&D.Как разработчик библиотеки компонентов, он недоволен, потому что теперь у каждого пакета есть своя папка типов, поэтому при разработке в IDE всегда будет выполняться навигация по коду между пакетами. появляться.

Например, мы нажимаем кнопку и хотим перейти к исходному файлу кнопки, но среда IDE фактически переходит к файлу кнопки button.d.ts.

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

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

Поэтому мы разработали (класс) тег jsdoc, а затем разработали плагин babel для различных ситуаций (около 10 ситуаций), обертывания и повторной обработки собственных компонентов React и некоторых объектов модели. Наконец, создайте версию компонента, изначально поддерживающую mobx. Конечно, ключевое значение этого решения заключается в том, что это решение автоматически завершается, поэтому нам нужно только с радостью разработать нативную версию React, а затем с минимальным обслуживанием мы также можем автоматически сгенерировать версию mobx.

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

Учитывая это, мы обязаны использовать лучшие практики, созданные в команде. Поэтому мы решили удалить версию cjs, то есть наша первоначальная структура изменилась обратно к ситуации, когда cjs нет, а осталась только версия es.

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

средства технической поддержки

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

Сегодня я расскажу о некоторых из них (как показано ниже)

Давайте сначала поговорим о технической проблеме конвергенции. Интересно, есть ли среди одноклассников лестные личности. То есть, когда мы начали создавать библиотеку компонентов, наши первоначальные намерения были очень хорошими. Что мы надеемся сделать? Мы надеемся сделать все возможное, чтобы быть максимально совместимыми, чтобы каждый пользователь был очень счастлив, верно? Нет, реальность не должна этого делать.

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

Итак, вот несколько способов, которыми может проявиться техническая конвергенция:

Кроме того, код должен представлять собой не только «логическую часть», но и вести себя так, как описано ниже:

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

Затем поговорим о «нормализованном процессе устаревания»:

Некоторые уроки нормализации процесса утилизации:

Также автоматизированные тесты:

Некоторые идеи для автоматизированного тестирования:

Вот некоторый опыт автоматизированного тестирования:

Кроме того, это Sass.Основное мышление Sass заключается в том, чтобы сделать все факторы, которые могут и должны быть связаны, как можно более связанными:

Вот несколько советов:

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

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

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

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

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

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

Хорошо, давайте поговорим о другой строке, другая строка основана на семантике, мы упорядочим ряд этих цветовых переменных, а затем, например, основной цвет сильного фона — это color_brand (8) (8-й цвет темы) ), для цветовой переменной компонента (ага, наконец-то мы добрались до этого слоя), это где-то конкретная семантическая переменная, которая в итоге используется для стиля компонента. Это общий процесс, в основном для того, чтобы объяснить, что на самом деле все взаимосвязано и должно быть связано воедино.

Кроме того, стоит инвестировать в формирование контента. Рекомендуется посмотреть plopjs. Это позволяет нам упаковать некоторые повторяющиеся и утомительные задачи в общую автоматизированную задачу.

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

Я не буду вдаваться в подробности о линтинге, потому что у всех может быть больше контактов. Но вот несколько моментов.Во-первых, (если у вашей команды нет согласованной конфигурации) рекомендуется начать с более строгой спецификации с открытым исходным кодом, а затем двигаться вниз, чтобы изучить спецификацию для группового анализа. Кроме того, линтинг должен быть связан с определенной ссылкой на исследования и разработки, например с предварительной фиксацией git. Или, если у команды есть платформа CI, ее можно оснастить процессом linting.

Еще один интересный момент заключается в том, что раньше у разных студентов были разные конфигурации форматирования кода IDE, что приводило к многочисленным «дрожаниям» в стиле форматирования кода.Рекомендуется рассмотреть конфигурацию здесь..editorconfig,илиprettierчтобы избежать этого.

6. Нетехническая линия

The dark side of the moon

Начнем с захватывающей истории:

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

Ядро библиотеки компонентов

Прежде всего, станем по стойке смирно и исправим свою позицию!

Поэтому переосмыслите сложность сборки набора библиотек компонентов:

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

инфраструктура

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

  • своевременные коммуникационные инструменты;
  • Онлайн-платформа для совместной работы с документами;
  • Системы управления задачами (управление проектами);
  • Облачный онлайн-диск (управление автономными документами).

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

Документирование осадков и управление ими

Давайте сначала расскажем историю. . .

Это радостная и грустная история 😂 .

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

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

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

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

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

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

Трудности с документацией

Однако такое построение документации часто бывает сложным, например, следующие распространенные проблемы:

Мы постараемся объяснить, как осуществлять "осадку и управление документами" от "что писать" и "как писать"

Что написать

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

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

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

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

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

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

Так что же это за вещи?

Давайте посмотрим на следующий рисунок, еще одну иллюстрацию метода построения схемы только что.

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

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

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

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

Есть несколько важных моментов, касающихся «в организации».

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

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

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

Еще одна идея — FAQ, часто задаваемый вопрос (список часто задаваемых вопросов). Это очень изящный прием, например, на основе конкретной проблемы кто-то поднял ее, чтобы объяснить, что есть рыночный спрос на эту проблему, включая еженедельный отчет по этой проблеме (например, соответствующие нормы, концепции, знания и т. д.). ).

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

как писать

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

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

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

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

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

Итак, так называемое «как писать» — это действительно проблема, которую нам нужно рассмотреть и найти навыки того, как писать.

Итак, давайте поделимся некоторыми принципами и методами написания хорошей документации:

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

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

О процессе и людях

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

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

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

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

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

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

Также распространенной проблемой, которая очень важна в процессе, является конфликт.

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

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

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

Обслуживание документов, мы должны быть такими.

Во-первых, попросите всех участников сказать, что я не могу что-то найти или что-то не понимаю. Пусть все знают, что вы говорите это не потому, что вы глупы, а скорее потому, что документация плохо написана или поддерживается. В коллективе, если все связывают человека с его IQ, если он что-то не может найти или понять. В конце концов, такие звуки услышат не все, а значит, эти звуки могут стать «Слон в комнате» (The Слона в комнате). И если ни у кого нет этих голосов, команда сильно теряет эту возможность улучшить документацию.

Кроме того, побуждать всех сталкиваться с проблемой, исправлять ее, не игнорировать ее или, по крайней мере, не пропускать ее напрямую, а задавать вопросы. Однако есть предпосылка, что когда вы меняете его, вы должны напомнить всем в соответствующей группе сказать: «Я что-то изменил, все обратите внимание».

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

Пример №1: Разделение и реорганизация документов

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

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

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

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

Пример #2: Обсуждение на основе документов

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

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

Тогда какая польза от этого?

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

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

7. Заключение

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

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

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

8. Присоединяйтесь к нам!

Если вы увлечены технологиями, если вы заботитесь о качественном интерактивном опыте, если вы верите в командную работу и если вы хотите улучшить себя во всех аспектах, добро пожаловать, пожалуйста, обязательно киньте мое резюме! В Пекине, Шанхае и Шэньчжэне есть HC, независимо от того, являетесь ли вы начинающим, средним, продвинутым или старшим экспертом FE, и тогда ваше резюме можно отправить на почтовый ящик здесь.zhengliangliang@baidu.com(Пожалуйста, укажите целевое рабочее место).

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

Наконец, большое всем спасибо. Существует также рекомендуемая книга.Это книга «Выжившие в мире будущего» г-на Жуана Ифэна.Вы можете купить бумажную книгу или проверить электронную версию. Личное резюме в одном предложении: Это относительно пессимистичный подход, чтобы попытаться найти относительно положительное решение для неудержимых технологических изменений. Затем он может стать источником будущего для наших одноклассников, занимающихся технологиями.

Не забывайте прямой эфир с 18-17 часов,Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):

image.png

Все предыдущие серии полностью записаны и транслируются.Начните и разблокируйте все сразу

С нетерпением жду новых статей, например

Категории