第二屆搞基建|芋頭 - 如何在大前端團隊實現基建價值突破

前端早早聊大會，前端成長的新起點，與掘金聯合舉辦。加微信 codingdreamer 進大會專屬內推羣，贏在新的起跑線。前端

第十四屆|前端成長晉升專場，8-29 即將直播，9 位講師(螞蟻金服/稅友等)，點我上車👉 (報名地址)：小程序

正文以下

本文是第四場講師 - 芋頭的講稿文字版，來看看他是如何講的，視頻及 PPT 將來在公衆號放出。後端

第一部分我的和團隊介紹

我的介紹

大搜車資深技術專家
大無線相關架構、創新團隊管理
從業 10 年，作過和帶過前端、客戶端、服務端
熱愛分享，活躍於技術社區
沒夢想，有活幹就很開心了

團隊介紹

300 左右無線相關開發人員
總體創新和沉澱意識在集團內也是很是突出的
綜合型團隊較多，上升空間大
從 17 年開始就成立幾十人的無線基礎設施團隊
前端、客戶端、Node.js 領域均有較爲成熟的基礎沉澱

我的和團隊職責變化歷程

公司 13 年開始組建開發團隊不久以後我就加入了，最開始負責公司的前端開發相關事宜，由於我之前就是在天貓作前端的。不過雖然主業是前端，可是我當時一直以爲本身應該是要走全棧道路的，首先由於開發完整的應用，確定不止是前端一個角色的事情，另外就是前端的生態當時已經開始顯露出邊界擴展的苗頭，特別是 Node.js 的火熱，因此在團隊尚未引入過多技術棧和作過多沉澱的時候，我本身率先去作了這方面的沉澱，具體就是花了大量的時間去學習和實踐 Node.js 開發，並且是奔着完成完整的產品的先後端開發去的，雖然最後沒有說對 Node.js 的底層挖掘有多深刻，可是的確讓團隊具有了初步的使用 Node.js 作開發的條件。當時在公司剛啓動的過程當中，分工不是特別明確，還自學並作過一段時間的 Java 開發，這個經歷對我來講也是很重要的，這些都是團隊後來擴展價值邊界的基礎，因此探討基礎設施建設，爲長遠沉澱的思路是貫穿始終的，是一切的基礎。微信

從這張路線圖來看，其中最重要的幾個拐點：markdown

開始有意識的沉澱
開始用 Node.js 作業務
開始作數據可視化業務
開始整合客戶端開發
Node.js 下沉基礎服務
架構常態化、體系化
集團業務多樣性，團隊分散
基礎設施體系化、產品化、邊界拓展
綜合型團隊

最終團隊的沉澱和發展，一個是這個過程當中的契機決定的，一個是公司業務發展情況決定的，一個是自我沉澱的意識決定的，同時也是團隊積累的方法論決定的。架構

這裏咱們不展開其餘話題了，主要是這些過程，你們能夠參考，能夠拿去映射本身的公司，本身的團隊，用以說服老闆，爲老闆提供思路等。框架

如今團隊大致的狀況

咱們團隊的組織架構其實一直在演化，有時候可能半年兩次的調整頻率，背後也是有一些緣由在裏面的，這個等會兒會有專門的探討，這裏是咱們過年以前大致的組織組成，其實可能 2 周後就不是這樣了，最近我又有一些新的思路，可能變化會很大。異步

首先，我負責的團隊是偏基礎設施輸出的，可是又不是那麼絕對，爲何會是這樣的組織結構呢？是多種緣由形成的，一個是團隊在作技術設施過程當中，嘗試直接影響業務，最終作的一些創新的方向，演變成了創新平臺（相似於創新實驗室的定位，經過技術挖掘直接改變業務進程），另一部分是純粹的架構是很難穩定的獨立存在的，因此基礎設施團隊在到達必定階段以後，須要和業務有一些交叉的邊界，特別是前端領域，千萬不能一條繩子上栓死，無論作什麼最終衡量價值必定是對業務、商業的影響，在前期，團隊和業務爆炸增長，不少架構上的問題須要專人解決，一旦解決能夠大幅提效，可是當核心痛點獲得解決以後，打磨和挖掘是須要的，可是若是大量人力仍是耗在一些須要作可是不緊急的事情上，價值會慢慢削弱，因此，做爲佈局的人，須要認清這方面的事實。oop

目前來看，咱們團隊如今的總體組織架構是比較健康的：佈局

基礎設施，這部分已經比較成熟，更可能是標準化、打磨、產品化。
基礎服務，Node.js 的練兵場，也是直接影響業務的前沿陣地，固然一些小的基礎服務也很成熟了，大的基礎服務，還須要服務公司雲平臺、PaaS 平臺的建設輸出，這是具備長遠價值，並且很深入的事情。
創新實驗室，高精尖，探索業務最前沿，利用基礎沉澱大幅提高業務能力，也是團隊邊界探索的前沿陣地。
業務團隊，先後端一體團隊，一個是利用基礎設施更快的孵化業務，一個是成爲基礎設施的試煉場，共贏，同時也是團隊承擔更多責任的突破口。

第二部分核心基建介紹

本節，我會簡單羅列一下咱們的基建覆蓋場景，由於內容太多，因此沒有把內容展開，也沒有講某個領域咱們具體作了什麼，我會適當展開一下，你們感興趣能夠會後找我，或者只是把這個當作一個目錄參考。

對於咱們作過的基建，我也簡單的作了一下分類：

應該有的：最基本的，必備的，行業常見的，完整的，專人負責的，到了某個階段必需要有的基礎設施。
平常沉澱：能夠沒有，可是有了能夠在某個領域提效的，經過長時間有意識積累出來的，偏最佳實踐的基礎設施。
影響生存的：作很差，這個領域就混不下去的，例如 Node.js 基建。
創新探索的：端的領域拓展，全棧領域拓展，創新價值探索的，每每是一些看起來無關緊要，可是能夠給業務帶來巨大想象力的事情。
產品化探索：慢慢將基礎設施產品化，而不是純粹是技術方面的輸出。

具體內容，這裏不展開了，這個章節仍是但願可以提供一個索引目錄，當你們沒有思路的時候，能夠從這裏面尋找一下是否有可參考價值的內容。

另外，在這些目錄以外，簡單總結下經驗：

從平常痛點中挖掘基建內容
- 時刻抱有沉澱意識，無論是大到大型系統，仍是小到一個方法，時刻考慮提效、複用、可維護
- 培養有以上意識的人，給予足夠空間和引導
主動挖掘業務痛點
- 不要等待別人指派任務，常常停下來看看業務上、商業上、產品上，有沒有經過技術手段能夠高效解決的問題，例如偏創新的沉澱，業務不敢想或者想不到，咱們站在他們的角度去想一想
適當時機打造正規軍
- 正規軍須要有正確的職責定義，須要自我挖掘和解決問題，強調產品思惟，團隊價值可感知
邊界試探
- 行政上，向上說服，或者是技術上，不斷打破邊界是很是必要的，最基本的，不要給本身設界

第三部分典型項目簡介

除了提供以上的目錄索引以外，雖然鑑於時間有限，不能針對某些內容展開詳情，若是是這樣，可能每一個事情均可以講 1 個小時，可是又想既然提到這些內容，仍是應該簡單展開幾個內容，表面介紹一下，可能會給聽的同窗帶來一點更具體的價值，因此這一章節，我想簡單介紹下幾個事情的大致解決思路或者方案，正好關注某一塊事情的同窗能夠借鑑或者探討。

移動標準容器和移動平臺

如今不少互聯網公司的業務都是基於移動端開展的，因此移動端的基礎設施是很重要的，而移動端的發展趨勢，總體又是在向跨端開發的方向演進，無論是 H5，仍是 RN，仍是如今流行的 Flutter，咱們把這類業務運行的環境成爲「容器」，容器和容器之間偏向於獨立，每一個容器是一個業務單元或者一個運行環境，之間經過路由調度，另外也經過路由能夠和 Native 原有的生態互相調度，能夠說「容器」是承載移動端業務最核心的部分，其餘基礎設施要麼隱藏其後，要麼直接和它關聯，容器是業務和基礎設施之間互通的惟一出口。

針對容器這塊，初期咱們作了大量的工做，把公司大部分移動端業務都從 Native 開發轉移到 H5 和 RN 的技術棧上，其實使用 H5 和 RN 自己並無過高的技術壁壘，只是把問題放到場景裏就會變得複雜，團隊的構成，業務的性質和量，組織架構，都會帶來不少問題須要解決，而做爲基礎設施的開發，須要不斷去平衡和解決這其中出現的問題，克服重重困難把方案落地，最終解決根本的痛點。

這個問題，在作 RN 落地的時候，體會最爲明顯，大概講一下落地 RN 須要考慮的問題：

團隊構成，移動端相關業務，客戶端居多
業務性質，偏 B 端，業務線多，短時間內指數級增加
組織架構，業務線之間關係比較獨立
技術問題，平臺差別仍然存在，性能和體積等

針對這些問題須要作的解決方案：

面向 Native 開發友好，不須要花大量時間學習 React，甚至 JS，不須要花時間瞭解 RN 固有的一些機制和問題
面向傳統流程友好，開發、部署、聯調、提測、發佈、更新，原有 APP 的流程習慣儘可能不破壞，不然須要改變一大批人的工做習慣
業務粒度控制，業務單元隔離
平臺差別抹平，業務變薄，基礎變厚，犧牲靈活性，帶來標準化等

最終咱們對 H5 和 RN 開發的諸多賦能慢慢演化成這些部分。

關於整個移動端開發，除了容器和業務開發比較緊密以外，其實咱們的輸出是更大的一個總體，這個總體的價值輸出，可能不限於開發上的提效，還包含一些產品層面的沉澱，甚至是商業上的沉澱。

移動平臺分幾個階段？

第一階段，偏工程層面，開發標準化，運行環境標準化，平臺基礎能力標準化
第二階段，偏產品層面，與業務無關的能力標準化平臺化，賦能快速搭建（不止是開發層面）新的業務 APP
第三階段，偏業務層面，賦能內部 APP 業務層面平臺化，應用互通
第四階段，偏行業層面，平臺化 APP 的能力對行業開放，另外助力生態公司快速搭建本身的 APP

這幾個階段不必定是遞進，有交合，也要有孵化沉澱的意識，有些事情從如今可能就要考慮將來的形態。

具體能夠作哪些事情？我認爲核心兩個方面：

第一個方面，移動架構的基礎沉澱，意義：集團全部業務線基礎複用、H5/RN 跨業務遷移複用、高效標準的工程能力。賦予這些意義的能力，包含：
- 基礎的運行環境（容器/路由/公共組件等）
- 業務開發提效設施（開發腳手架/持續集成/發佈更新）
- 配套的基本的開發系統（託管/日誌/報警）
第二個方面，快速低成本搭建或完善 APP 的能力，於內部、子公司、生態公司、行業公司。賦予這些意義的能力，包含：
- 開發基礎設施層面的快速搭建（包含第一個方面的全部能力）
- 產品層面的快速搭建（消息中心、閃屏、更新、客服、IM、掃一掃、搖一搖，數據等）
- 業務層面的快速搭建（業務單元化後在 APP 間無縫遷移，外部業務快速集成等能力）

持續構建和持續部署

接下去介紹下咱們再持續集成方面作的嘗試，嚴格來講，咱們提供的不是持續集成的流程最佳實踐（團隊太多，整個流程不急着標準化），而是持續構建和部署的能力。

這裏面的複雜度主要是：

技術棧不少，Vue、React、React Native、iOS、Android、小程序、Node.js。
- 上層抹平技術棧
業務線和項目不少，前端項目接近 1000 個，RN 項目接近 300 個
- 打包資源要保證
- 構建部署方式須要標準化、集中化

最終，咱們把全部無線的技術棧的集成流程作了抽象，每一個技術棧的腳手架來適配，例如：

環境抽象（測試/穩定/預發等）
動做抽象（建立/打包/部署等）

而後把全部這些抽象到一個集中的服務中，提供出 PaaS 服務，上層只須要告訴我項目是什麼技術棧，須要作什麼動做，其餘就能夠不關心了，固然咱們也有默認的上層最佳實踐實現，可是業務也能夠本身構建上層的持續集成流程。針對集中打包部署的性能問題，引入 tekton 集羣流水線處理任務。

這裏，其實咱們提供的不是一個持續集成的基礎設施，而是持續集成更底層的抽象沉澱，將來它能夠適應業務各個階段不一樣的訴求，屬於基建底層的基建。

Node.js 框架生態

每一個前端團隊都應該關注一下團隊在 Node.js 方面的積累和沉澱，Node.js 在咱們團隊如今發揮着各類各樣的做用，其中不少領域不是一天兩天的沉澱能夠作到的。

例如：

前端生態自己，腳手架、持續集成中的各類服務、資源管理、開發用的服務等，脫不開 Node.js 。
創新應用的探索，無論是偏技術的，仍是偏產品的，要完成一個完整價值的輸出，服務端老是脫不開的，有了 Node.js 沉澱，任何應用均可以大家本身團隊內部孵化，而不須要依賴外部共建。
業務開發或者服務開發，模糊大前端團隊邊界，公司大了，職位高了，職責會愈來愈要求綜合，你的職責就是解決問題，而不是解決前端問題。

爲了作到這些，咱們在 Node.js 探索的過程當中，一直在刻意沉澱：

早期，在團隊內探索，前端生態的，甚至是一些小功能嘗試 Node.js 實現。
後來，Node.js 嘗試作獨立業務，過程沉澱一些最最基礎的 SDK 和最佳實踐，例如配置管理，異步任務、一些常見庫的選型固定等。
後來，Node.js 嘗試作底層服務，穩定性和性能要求等加深，慢慢在社區框架上固定選型，上層封裝腳手架、配置管理、接口管理、文檔管理等。
後來，更進一步模糊和 Java 生態相比的弱勢和差別，Dubbo 接入，全鏈路接入，消息隊列，異步任務等徹底和 Java 打通（而不是從新造輪子），這個階段結束時，作技術選型，技術棧的差別已經不成理由。

正是有這些基建，保證了 Node.js 生態的發展，同時間接促進了團隊承擔更多的責任。

組件庫和功能庫

最後，分享下比較基礎的組件庫沉澱吧，這部分沉澱是比較基礎的，也是早期作了以後發揮價值比較大的部分，主要分爲兩部分，UI 組件庫和功能組件庫。

UI 組件庫，咱們所有都是自建，固然我並不推薦硬造輪子，自建的主要緣由仍是配合公司本身的設計規範去作落地，過程當中咱們也會直接借鑑一些社區組件庫的設計來實現，同時，在建設過程當中，面向集團內跨業務的一些訴求，咱們在全部組件庫之上作了一個統一的主題色管理機制，配合 APP 還能夠自動切換主題，另外就是作了一些業務組件管理的能力，拋開最基本的 UI 組件，一塊兒共建有一些業務特色的業務組件。

在功能組件方面，更可能是來自於業務的沉澱，例如分享庫，整合全部平臺的分享能力，而後內置一些分享鑑權的實現等，最終暴露給業務，是一個簡單配置便可擁有強大功能的庫，基本能夠解決公司全部業務的分享相關問題。相似的組件還有不少。

另外，針對組件庫和功能庫，早期能夠投入專門的人力去開發，可是後續維護，須要慢慢向共建轉變，這個也是咱們的一個經驗教訓，以前有開發夥伴一直專門負責組件庫的開發和維護，投入產出比隨着時間推移，會慢慢下降。

創新平臺

從 18 年末開始，我就一直在想「端」這個詞的另外一層含義，前端、客戶端、服務端，咱們都趟過，可是這還不是所有，我當時就在想「端」能夠有更多機會和價值，放眼到行業裏，雲端、設備端等概念都如雨後春筍般冒出，映射到公司內，技術上、業務上，都有能夠匹配的點，因此後來就下定決心，團隊邊界必定要向設備端這個領域延伸，固然真正的延伸是須要業務上的突破口的，脫離開業務去作物聯網去作設備控制意義不大。

後來隨着公司業務發展，19 年初的時候，咱們敏銳的發現很多新業務想要嘗試新穎的銷售和營銷方式，其中涉及到不少設備的場景，因而咱們順着這些場景去挖掘（甚至比業務看的更超前），慢慢幫助業務實現目標，另外也在設計實現的時候刻意分層，思考將來底層的沉澱和更多場景的賦能。因此後來就有了 SoucheOS 和 Souche IoT 最最基本的基礎設施，把設備能力和遠程控制能力作了去業務場景的抽象，有了這些能力，咱們能夠快速在上層適配各類業務場景，而且順便把集團內的辦公設備在線化、測試機在線等支持了。另外這塊還有對一些社交軟件的控制能力，這個也是基於設備底層能力的挖掘，配合設備平臺，能夠輕鬆實現遠程和羣控。

第四部分組織架構的探索

分享完了一些具體的內容，接下去想和你們探討下在基建過程當中的其餘演化和思考，首當其衝的是組織架構的變化，日常你們都會講，技術不分優劣，更重要的是看場景。組織架構就是場景之一，不一樣的組織架構下可能須要不一樣的作事思路，也會產生對基建的不一樣訴求。不過同時，爲了作好基建，也須要不斷調整組織架構。這裏的組織架構可能更可能是一內一外，上層組織架構決定了要作什麼事情要怎麼作事情，而爲了作好事情，須要不斷調整優化內部組織架構。

內部組織架構調整重點的考量：

基建重點是不斷轉移的，伴隨組織架構的調整
基於技術棧組織，仍是基於項目輸出組織，看階段，看團隊
純粹的驅動力人才培養
業務和基建，創新和基礎，相輔相成

第五部分項目管理的探索

基建項目的管理，歷來不是一件容易事，這有多方面影響：

角色單一，不像正常項目同樣有作規劃的、作項管的、作質量的、作銷售的，在基建項目裏，可能都是一我的
開發人員容易糾結於技術自己，忽略溝通、管理、可控等環節的重要性
技術項目複雜度較高，如何羣策羣力，同時又能正確一致地決策

因此，咱們發現項目管理的幾個重點：

如何立項一個有價值的項目
如何推進項目最終實現交付
如何將項目推向你的目標場景和用戶，產生最終的價值

在咱們團隊，作過不少嘗試，這裏只把一些可能有參考價值的方法介紹一下：

立項

立項包含多個層面，例如方向的確立，項目的確立，迭代的確立。

長遠規劃
- 對於方向的確立，例如在作設備平臺以前，咱們是有對這個事情的想象和探討的，對我我的來講，偶爾會停下來，排除干擾，思考一下一些大方向的可能性，這些思考會站在一些假設之上，例如咱們將來業務會向什麼方向傾斜，因此咱們將來可能會有個什麼平臺，最完美狀態是什麼樣的，如何在業務中發揮極大價值，不過這些想象可能永遠都達不到，可是價值是能夠不斷分層和降級的，想的足夠遠，可是也要分解成階段回到當下。在我思路比較活躍的時候，我會把這些想法寫成「長遠規劃」，而後講給團隊裏的骨幹聽，探討一下，或者同步下站在比較高的角度對這些事情的想象，若是你認同，能夠參考，把事情一步一步作成，若是不認同，能夠發表你的想法

舉幾個以前長遠思考過的幾個方向：

開放平臺服務 -> 開放平臺產品 -> 雲平臺工做窗口 -> PaaS ISV 工做窗口 -> 服務場景管理編排 -> 移動開放平臺等，咱們作的固然還遠遠不夠，將來要作什麼，能夠參考的方向不少。

移動端基礎設施->運營平臺-> PaaS 開發平臺，賦能內部、集團、行業，mPaaS 是可參考的標品。

等等，一般這些思考，會參考行業產品，考察業務、商業上的發展等

調研報告
- 長遠規劃可能更偏向理想狀況，真正要開始一個項目，須要作更爲細緻的分析，確保接下去投入的資源是有價值、可持續的
- 這些事情，其實有點相似於產品經理須要作的事情，作用戶調研，需求調研，或者是本身分析出來的痛點，可是在整理想法後，也是須要和對應的業務方勾兌交流，修正思路

這裏，其實最好能引入一些產品方法論，例如「用戶故事」，需求分析文檔，從不一樣類型的用戶的角度，開始分析背景、問題、思路、方案、改進後的用戶路徑、感覺等。我一直想跟你們強調，作技術設施，必定要鍛鍊本身的產品分析能力，由於沒有人會幫你去分析整個事情的前因後果，須要靠本身去挖掘方向和需求，若是你仍是一直等待需求的出現，那你是走不遠的。

可行性方案
- 最終，在肯定一個項目以前，須要有書面可行性方案，而且組織參與者和相關者對可行性方案進行評審，並作修正

不過這些流程都不是絕對的，看項目類型能夠適當調整，並非絕對的全部項目都要通過最細緻的流程，有時候，過於細緻的流程，雖然能夠保證事情的可控，可是也會拖慢進展，有些技術項目，反而是越快越好，須要快速試錯，這其中平衡，還需不斷調整。

推動

基建項目，若是是一我的或者一帶一，推動問題可能還不大，可是一般不少會涉及到跨技術棧角色的合做，甚至是跨團隊的合做，要保證這樣的項目更好地落地，仍是須要較爲規範的項目管理方式的，其實這裏和普通的業務項目沒有太大的差異，技術方案評審，排期，接口文檔等。

這裏提到架構設計，不過說實話，一個系統剛開始的時候，很難給出完整的 C4 架構設計，這裏提到的 C4 架構設計，更可能是在項目迭代過程當中，逐漸梳理細化出來的，用以向外同步信息和內部參考迭代。

另外，一個比較重要的點，是里程碑的分解和制定，基建項目一般體量不可控，若是一開始就設計了一個龐大的完整的方案，交付時間幾個月，這時候就要想一想裏面是否是充滿了不可控的風險，這幾個月任何事情均可能發生，業務訴求、組織架構、人員變更，因此必定要把目標分解里程碑，每一個里程碑有個階段的產出，注意這裏的里程碑不是把一個長的任務直接切開幾份變成短的任務，而是每一個里程碑你交付的可能都是一個最小可用的總體，早期儘快成型，後期迭代優化增長新特性，要養成分解達成的習慣，而不是一蹴而就。

運營

技術運營也是基建的一個逃不開的比較磨人的話題，特別是對於大一點的團隊來講，基建的落地是須要本身去主動推進推廣的，對基建的輸出的要求不是作個庫作個框架這麼簡單，而是輸出一個產品，你須要準備資料，講清楚前因後果，講清楚你的理解，講清楚你的優點，建清楚如何使用，形式可能各類各樣，文檔固然是必備的，白皮書也是須要的（文檔更可能是介紹如何使用，白皮書是告訴別人爲啥要用），分享是基本的但不必定是有效的，工做坊是更有效可是成本較高的，須要本身平衡和探索。另外就是技術運營要是持續性的，而不是一次了事，事不關己高高掛起愛用不用。

下圖裏咱們給團隊的產品甚至都訂作了文化衫，去強化你們對基建產品的瞭解

第六部分其餘經驗總結

經過剛纔講的一些內容，咱們簡單總結一下。

要作好基建，較爲核心的點：

組織架構保障。無論是最初的先行小組，仍是後來專門的基建團隊培養，Leader 要作好組織上的保障，爲基建爭取空間
項目管理推動保障。架構項目的特殊性，須要有方式解決推動管理，確保結果落地
沉澱意識。Leader 本身要很是敏感，同時挖掘培養有沉澱意識的同窗，沉澱都是來自於平常工做
貼近業務價值。不要脫離場景造輪子，沒法發揮價值，也得不到上下級的承認。

另外，一些細節的注意點：

不要給本身和別人挖坑
- 不要盲目擴展團隊技術棧
- 完整的開發過程和使用文檔
- 切忌假大空，上來就規劃一個平臺，最終只有一個爛攤子
- 適當嘗試，適當投入，但也要對風險合理評估，並有規避方案
- 想的能夠儘可能遠，可是要回到當下根據實際狀況分解節奏
可是也要適當造輪子
- 適合本身的實現，按照本身的路徑迭代
- 磨鍊團隊技術能力，增長對技術細節的深刻，爲將來作沉澱
- 系統思惟其實很難養成，須要場景
- 須要平衡，資源、風險、投入產出比、可持續性，對本身的團隊要有一個正確的認知
注重系統思惟
- 學會本身作決策和負責任，而不是執行任務，或者完成交代
- 更透徹的理解一個問題
  - 不斷追問本身爲何要作一個事情
  - 理解的原由是否也是基於某個結論
  - 例如：我要作 xx，由於 xx 業務說他們須要 xxx
  - 爲何要這樣作
- 層次感，規劃、系統架構、價值體現方面，隨時解耦重組
切忌半途而廢
- 逼本身挖掘深度價值
- 固然也不要盲目挖掘，確保大方向是對的
- 慢慢系統化、產品化、嘗試打通任督二脈
- 切忌浮於表面，走馬觀花
克服孤獨感
- 熱愛、相信、投入、開放
- 主人翁意識，爲輸出及其價值負責和決策

第七部分今日分享總結

最後，你們有問題，能夠加我微信探討，或者在行上約我面聊，感謝你們。

第三期 2020.3.28 在線上直播，主題「前端搞搭建」，掃碼關注「前端早早聊」公衆號參與報名：