Я был занят тушением пожаров на прошлой неделе, и я снова здесь на выходныхTweb Conf(Участвую в таком мероприятии впервые), поэтому выхода нет. Но эта неделя напряжения, занятости и беспокойства заставила меня кое-что понять и написать эту статью, ничего сухого, просто бессвязное повествование.
На прошлой неделе для меня наступила важная веха достижения уровня Nuggets.LV5. Цель достигнута, что является облегчением, я больше не хочу писать статьи, чтобы получить больше лайков и больше чтений, и мне больше не нужно выбирать какие-то громкие заголовки, и мне больше не нужно ничего доказывать. Я обнаружил, что частота открытия Наггетсов резко снизилась, раньше я мог заходить десятки раз в день.
В новом году я надеюсь успокоиться, глубже копнуть в своем направлении и посвятить больше сил участию в open source.
контур
- Дилемма внешнего интерфейса малых и микро/аутсорсинговых предприятий
- Концепция мидл-офиса
- Разделение передней и задней части
- Минималистский стек технологий
- Избегайте «единой точки отказа»
- Коллективные интересы перевешивают индивидуальные
- Разговор о личном развитии: смена работы и смена работы в пути
- Суммировать
- расширять
Дилемма внешнего интерфейса малых и микро/аутсорсинговых предприятий
Я считаю, что лишь несколько главных программистов остаются на крупных фабриках, а большинство фронтендов по-прежнему живет вМалые и микропредприятияКоманда фронтенда (🔴Примечание: относится к командам со слабыми инженерными возможностями, за исключением крупных заводов и крупных стартапов.), глядя на стены большого завода. Представьте их яркими и полными страсти. То же и завинчивание, так же практикуется фронтенд-инжиниринг, и ковши семейства Vue и React тоже используются.Другие делают заклепки на авианосце, а вы закручиваете винты с двойным сверлением от Audi.
Большие заводы говорят о высоких технологиях, архитектуре и сценариях. Малые и микропредприятия говорят о еде и одежде на переднем крае, и мы более или менее сталкиваемся со следующими дилеммами:
маргинализованный
В такой компании нет внешнего интерфейсаПраво говорить, они представляют собой простую реализацию страницы, называемую Chetuzai.
По сути, характер и масштаб бизнеса определяют, что фронтенд-работа не будет занимать слишком много веса, и естественно ей не будет уделяться слишком много внимания, а заменяемость тоже высока. Такие компании, как правило, работают в традиционных отраслях, таких как производство оборудования, электроэнергетика. Наоборот, опираясь на конечные отрасли, такие как электронная коммерция и социальные сети, статус внешнего интерфейса будет намного выше.
В этой среде фронтенд не будет слишком заботиться о бизнесе, конечно, легко быть маргинализованным и играть роль похвалы в перекрестных разговорах.
Помощь хаосу/слабой инфраструктуре
Малые и микропредприятия, поскольку общий уровень персонала невысок, сотрудничество обычно хаотичное и нерегулярное. Это относится к общему сотрудничеству в области исследований и разработок в рамках проекта.
Для внешнего интерфейса наш вверх по течению может быть задней частью, а качество кода и стандартизация задней части будет иметь особенно большое влияние на интерфейс. Например, интерфейс сбивает с толку, документация не стандартизирована, сценарий приложений не рассматривается, интерфейс не проверяется и т. Д. В этой рабочей среде эффективность будет очень низкой, а вспомогательное развитие будет очень болезненный.
Занятый
Чувствую себя очень занятым каждый день, но вроде ничего не сделало. Ежедневная работа повторилась снова и снова, разметное время.
остров
Как и на изолированном острове, знания и информация закрыты, и людям трудно совершить крупный прорыв в своих способностях и технологиях. Модель компании определяет модель человека.
Кадровые изменения
Отличные таланты не привлечь, а отличные таланты не удержать, общий уровень низкий, технологическое осаждение и развитие затруднено.
Идеал/корпоративная культура
Мы только для того, чтобы делать деньги, не говорите мне об идеалах. Нам кажется, что нас тискают, мы машины, и счастья в такой работе нет.
подожди подожди...
Концепция мидл-офиса
В этом году концепция Китай-Тайвань очень популярна, и я не обращал на нее особого внимания, так как считаю, что она еще далека от нашего фронта, и на это способны только крупные производители. доTWeb ConfслушатьЧжан Юньлунсказал«Безголовая CMS — решение для мидл-офиса для малых и микропроектов»Меня заинтересовал «Чжунтай».
Вот статья"Комикс: Что такое Чжунтай? 》Популярно объяснил концепцию Чжунтай.
Это не большая фабрика, которая может практиковать промежуточную стадию.Я обнаружил, что наши приложения также имеют много повторяющихся сервисов.Каждый раз, когда создается новое приложение, серверная часть должна многократно копировать и реализовывать эти сервисы. Это пустая трата ресурсов для бэкенда и катастрофа для фронтенда. Поскольку мы обнаружили, что, хотя внутренний бизнес по существу повторяется, по человеческим причинам интерфейсы и процессы, предоставляемые каждой копией, более или менее несовместимы с предыдущим приложением, а внешний интерфейс необходимо каждый раз заново адаптировать. .
Чжан Юньлун представил бизнес-мидл-офис, подходящий для небольших и микропроектов.Strapi: ЭтоHeadless CMS, в переводе на китайский язык — «безголовая» система управления контентом.Самым большим отличием от традиционной CMS является Headless, то есть она предоставляет только интерфейс и не имеет фиксированного интерфейса.
С его помощью вы сможете добиться:
- Визуальное и быстрое создание бизнес-модели. Подобно созданию модели базы данных (независимой от базы данных), различные типы полей (в дополнение к примитивным типам также поддерживаются почтовые ящики и загрузка файлов) и отношения модели могут быть гибко настроены.
- Откройте канонический интерфейс. служба поддержки
Restfulа такжеGraphQL. Встроенная поддержка сортировки, разбиения по страницам, фильтрации, автоматического создания документов - Встроенная система контроля доступа. Роль, JWT-аутентификация
- Простая интеграция внутренних систем. Гибкость взаимодействия с собственными внутренними системами
- Расширяемость. Система плагинов
Headless CMS — это решение среднего офиса для малого и микробизнеса. С помощью Strapi мы можем быстро построить простую периферийную бизнес-модель и повторно использовать общие сервисы и подключаемые модули.
Вы также можете думать об этом как о многоуровневой архитектуре, которая изолирует основной бизнес от периферийного бизнеса. Внешний уровень является более изменчивым и сложным, чем внутренний уровень.Средний уровень Strapi изолирует пользовательский интерфейс и основные службы, что позволяет основным службам погрузиться и сосредоточиться на реализации более общих служб; С помощью Strapi можно быстро построить производную бизнес-модель неосновных периферийных устройств и представить парадигму стандартизированного интерфейса, которая, с одной стороны, может своевременно реагировать на изменяющиеся потребности внешнего интерфейса, а с другой — с другой стороны, он может обеспечить стандартизированную и согласованную парадигму интерфейса, что также может снизить затраты на связь и повысить эффективность разработки. Исходя из этого, внешний интерфейс также может создавать свои собственные повторно используемые бизнес-компоненты.
Конечно, как сказал Чжан Юньлун, Strapi — это игрушка по сравнению с большими фабриками и средней сценой. Тем не менее, для малых и микропредприятий быстрая разработка прототипов является хорошим лекарством для реагирования на потребности рынка и повышения эффективности НИОКР.
Разделение передней и задней части
Вы обнаружите, что систематизация и упорядочение фронтенд-разработки на самом деле углубляются с разделением фронтенда и бэкенда:
-
Пангу Кайтиан: нет различия между передней и задней частью
-
Возраст шаблона: Согласно архитектуре MVC, серверная часть отвечает за MC, реализует бизнес и предоставляет данные во внешнюю часть. Фронтенд отвечает за V, то есть за написание шаблонов. Разделения в структуре проекта после фронтенда не было, но обязанности стали расходиться.
-
эпоха интерфейса: серверная часть предоставляет интерфейс HTTP/WS, а внешняя часть отвечает за запрос интерфейса и реализацию рендеринга страницы. Технология CSR (рендеринг на стороне клиента) начала стремительно развиваться, Backbone, Angular, React... В структуре проекта интерфейс был отделен от сервера. Дальнейшее повышение эффективности разработки. Интерфейс — это контракт, по принципу контракта сначала фронт и бэкенд могут разрабатываться параллельно. Тем не менее, реализация внутреннего интерфейса на этом этапе по-прежнему должна заботиться об отображении страницы, и должен быть предоставлен интерфейс, который может удовлетворить требования к отображению пользовательского интерфейса.
-
Эпоха лучших друзей: BFF расшифровывается как Backends for Frontend. При родовых схватках передний и задний концы еще больше разделяются. Основных причин две: разнообразие терминалов, рабочий стол, iOS, Android, интерфейс, апплет... У разных клиентов разные требования к интерфейсам, и эти требования изменчивы. Кроме того, внутренний бизнес также превратился в микросервисы, поэтому внутренний интерфейс будет иметь тенденцию быть атомарным, с большим количеством отдельных функций и более общим назначением.
Однако это также болезненно для фронтенд-разработки: реализация страницы требует вызова множества интерфейсов, и производительность страницы также снизится. Многоуровневая архитектура снова пригодится, поэтому добавьте еще один уровень — BFF, который позволяет разработчикам клиентов приклеивать внутренние общие службы к стороне сервера в соответствии со своими потребностями. Это избавит серверную часть от необходимости заботиться о пользовательском интерфейсе. В эпоху BFF большое внимание привлекли GraphQL и NodeJS.
-
Бессерверная эра: Реализация BFF требует хорошей инфраструктуры и поддержки процесса НИОКР, а структура относительно сложна, поэтому обычно это могут сделать только крупные производители. С помощью облачной платформы Serverless снижает зависимость от инфраструктуры и сложность разработки и обслуживания. Поэтому порог для BFF на основе Serverless ниже. Serverless — это нечто большее, чем фронтенд-разработка, настоятельно рекомендуется«Бессерверные технологии запускают новые технологические изменения во внешнем интерфейсе»Эта статья.
Бэкэнд не хочет заботиться о данных, необходимых для рендеринга пользовательского интерфейса, а только о реализации бизнеса. Фронтенд также хочет избавиться от нижестоящих зависимостей бэкенда, так как все чувствуют себя неуместными, лучше их разделить.
Возвращаясь к предложению в начале, систематизация и упорядочение фронтенд-разработки сопровождается разделением и разделением фронтенда и бэкенда. Концепция «Чжунтай», введенная Чжан Юньлуном в предыдущем разделе, в некотором смысле является углублением разделения переднего и заднего концов.
Поэтому если ваша команда чувствует боль, то это на самом деле означает, что бизнес компании на подъеме, если нет аварии, вы встали на путь, по которому шли предшественники, а бэк-энд еще больше разорвется.
Минималистский стек технологий
Keep it Simple, Keep it Stupid. Последний глубокий опыт по этому принципу. Маленькая и микротехнологичная команда отбора технологии не должна идти с потоком, следуйте за горячими новыми технологиями, но следует выбрать минималистский стек технологии в соответствии с их собственной командой и уровнем условий бизнеса.
Эти четыре принципа очень важны:
- Простой
- автоматизация
- Четкая и качественная документация
- ограничение
Приведу несколько примеров:
"Простой" в основном для снижения порога обучения и уменьшения нагрузки на ум.Чем проще интерфейс, тем лучше:
- Соглашения > Конфигурация
- Явный > Неявный
- Декларативный > Императивный
- Протокол интерфейса: JSONRPC > Restful
- Инструменты сборки: Parcel > Webpack, в дополнение к Vue-cli, create-react-app
- Framework: случайный пример Vue > React. Начать работу с Vue «относительно» легко, React слишком гибок, сообщество полно цветов, и, как бы мне это ни нравилось, это не мешает людям делать глупости.
- Управление состоянием: Mobx > Redux > Rxjs.
- Конечно, конкретный анализ конкретных сценариев
«Автоматизация», то есть то, что можно решить автоматически, не зависит от спецификаций документов и устного общения:
- ESlint, Styleint, HTMLlint, Markdownlint... *Lint. Существует множество инструментов lint и рекомендованных сообществом спецификаций, которые автоматически определяют соответствие каждой ссылке.
- Более красивое форматирование кода. Есть только один стиль кода, не BB
«Документация», важность очевидна. Прочитайте документ заранее, а затем спросите других
«Ограничение», я чувствую отчаяние, когда что-то выходит из-под контроля. На этом этапе вы захотите иметь больше ограничений и попытаться держать код под контролем. Например, Typescript, различные *Lints. Спецификация всегда является просто спецификацией, если нет механизма ограничений.
Избегайте «единой точки отказа»
Небольшие и микрогруппы фронтенда имеют очень ограниченные кадровые ресурсы, и каждый человек часто отвечает за разные проекты, что может привести к «единой точке отказа». Если человек, отвечающий за проект, возьмет отпуск или уйдет в это время, люди будут застигнуты врасплох. С одной стороны, процесс передачи проекта будет длительным, а с другой стороны, стоимость переключения контекста других участников также высока. Особенно мы боимся браться за проект, в котором царит беспорядок.
Единственный способ устранить единую точку отказа — привлечь больше участников к перекрестному участию в разных проектах, а ответственность за проект лежит на команде, а не на отдельных лицах. Кроме того, он может взаимодействовать с такими средствами, как проверка кода, и различными способами позволяет членам команды ознакомиться с кодом проекта.
Спецификация кода и общий код также могут сыграть здесь большую роль. Если «знания» можно повторно использовать и совместно использовать в нескольких проектах, стоимость переключения контекста для проектов будет относительно низкой.
Коллективные интересы перевешивают индивидуальные
Будь то большая компания или маленькая компания, коллективные интересы всегда будут перевешивать индивидуальные интересы.
На прошлой неделе я принял два неверных решения: одно — утвердить руководителя экстренного проекта, чтобы тот попросился в отпуск, а второе — возглавить команду для участия в Tweb Conf до того, как проект будет полностью протестирован и запущен. Эти два решения вели к большому риску, и они подверглись критике со стороны начальства, но, к счастью, все они в итоге были решены. Обратите внимание на следующие недостатки:
- Коллективные интересы перевешивают индивидуальные интересы. Этому нас учат с детства.В коллективе свои действия и решения нужно нести за коллектив.
- Отсутствие общего контроля над проектом и недостаточная оценка рисков. Несмотря на то, что внешний интерфейс — это только часть законченного проекта, вам как руководителю группы внешнего интерфейса необходимо понимать ход проекта в целом. Вам необходимо знать время начала проекта, крайний срок, время тестирования, ход разработки/тестирования, текущие ресурсы и т. д. Эта информация используется для формулирования планов распределения ресурсов и оценки рисков.
- Повышение эффективности совместной работы. Как руководитель группы вы не можете просто сосредоточиться на технологиях и коде. Нам нужно обратить внимание на каналы сотрудничества между командами, повысить эффективность совместной работы на уровне команды и устранить коммуникативные барьеры для членов команды.
Как я часто говорю нашим товарищам по команде: проблема не ужасна, ужасно то, что вы не знаете, в чем проблема. Если вы хотите стать лучше, вам нужно больше размышлять и больше спрашивать, почему...
Разговор о личном развитии: смена работы и смена работы в пути
Что есть у крупной компании?
У маленькой компании может ничего не быть, нечего делать... Пространство может быть большим, а потолок низким. В большинстве случаев это, вероятно, просто трамплин для вас. Вы либо меняете работу, либо в пути, либо вы оцепенели и растерялись.
В любом случае, передняя часть малых и микропредприятий должна учитывать свое личное развитие. В том числе и я, я все еще думаю, не желая бездарности, пытаясь провести жизнь, на которую можно потратить всю жизнь, а не только работать.
Для личного развития у меня есть следующие предложения:
- 确定自己想要深入挖掘方向。很多所谓的大牛大多都是某一具体领域的专家。前端目前也有很多细分领域。见 这次 Tweb Conf 的会场布置就知道了，它细分了主会场(传统前端)、小程序&工程化、Node&架构、跨端&综合。 Кроме тогоТематическое подразделение конференции GMTCтакже для справки
- Выйдите из своей зоны комфорта и попробуйте что-нибудь новое
- храбрость.人有多大胆，地有多大产。没有勇气会错过很多东西
- Присоединяйтесь к сообществу и создайте свой личный бренд
- Будь голодным будь безрассудным
- Основы важны. Не спешите изучать необычные вещи, не спешите следовать за другими, чтобы увидеть исходный код.
- Постарайтесь понять бизнес, понять законы бизнеса и мирового функционирования, улучшить шаблон и социальные навыки.
Суммировать
Стены малых и микропредприятий не могут быть разрушены одним человеком, а расширение и модернизация бизнеса являются реальными движущими силами. Если вы чувствуете, что ваша компания имеет восходящий импульс и импульс, и вы согласны с ценностями компании, вы могли бы также работать вместе, чтобы способствовать прогрессу компании. Наоборот, мы должны серьезно задуматься о собственном развитии.
Не говори так, береги друг друга и усердно работай