我了解的阿裡無線前端“架構”（半雞湯，少幹貨）

寫在前面的話：

對于文中涉及“脫敏”的内容，連結經常一環套一環，無法輸出，很抱歉...

懷着一個醞釀了蠻長時間的念頭，打開電腦，想對一些思考做一點記錄。關于标題，關于“前端”，關于“架構” 。

其實是有蠻多話想說的，但是前面這幾個字卻打上去了又删掉。想為下面的内容找一個合适的開始。但是似乎總是不那麼如意。

回到這個話題，或許應該從以前的認知慢慢說起。

過往的認知

不可否認的說，曾經很長的一段時間，當我大部分時間還集中在業務上的時候，對“架構”這個詞有點嗤之以鼻。尤其是“前端架構”。覺得說“前端”這個軟體工程化都相對薄弱，還在拼死拼活的往成熟的語言領域，往已有的軟體工程慢慢靠近的的方向，真的需要所謂的“架構”麼。

https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2F0bbaab5f13b2b3e3d013208ac02eb7abd06be7a9%2F687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f38363734303434313834363663666634353039636536633439646538633161666264353561626462

總覺得在這個階段，

• 所謂的前端架構更多的是在紙上談兵，拿以往的軟體工程的思想和概念硬往自己身上套。
• 所謂的做架構的同學更多的是在炫耀自己的技術深度和視野，看到前沿的技術不管合不合适就拿來做方案，硬往業務上推，來成全自己的KPI
• 總覺的所謂的“技術架構”無非就是一些個人主觀化的思路和概念，形成一些看起來成體系的代碼組織方式，以便完成業務後可以說：看，基于我的架構有多好的通用性，擴充性，代碼看起來多優雅...

回到我現在的立場，我看到的目前團隊中不同的同學對于“架構”這個詞的認識和看法，無非有兩種：

• 要麼和之前的我一樣，嗤之以鼻，做架構的有什麼了不起，無非是老闆給你安排個“輕松點的活”，做做方案，不用受業務的壓迫。還得逼着一線每天認真辛苦的碼代碼的同學接受你一時想出來的Idea。
• 要麼是另一個極端，覺得做架構的同學就NB，覺得比做業務的同學從概念上就高一個等級。然後死命的想要往“架構”這個方向靠。

可是當有一天我自己需要站在團隊的角度去思考基礎建設的缺失，思考怎麼才能幫助到團隊的時候。才發現“架構”這個詞既沒有想象中那麼“不堪”，當然也沒有想象中那麼“容易”。同時，也沒有别人眼裡那麼NB，高人一等。 反而是越來越多的謙卑甚至恐慌，當沉下心來想想，确實，我們可能誤會“架構”本身了。我們自己往他身上加了很多的主管臆想。

我了解的架構：是團隊的，不是架構師的

第一條我就想說這個，因為TA的确應該是大前提，如果做架構的同學不是站在團隊的角度來思考問題，思考解決方案，而是以自己過往的經驗，自我的判斷說應該怎麼怎麼樣。那必然是會淪落到被人嗤之以鼻，甚至拖業務和效率的後腿。

• 架構一定不應該成為隻是你想要的樣子，也不能隻是老闆想要的樣子，一定應該是團隊想要的樣子。

在我正式接下為團隊基礎建設方向做規劃和思考這件事情之前。去年在團隊内做了一段時間的“SWAT”，也就是真正意義的上的“靈活資源”，做團隊任意方向的支援。在做“團隊支援”這個期間，參與了不同形态的業務項目，産品化的，營運化的，長線的，短線的，消費者端的，商家端的，前台重視内容和體驗的，背景重視效率和結構化的，等等一系列不同的項目，包括一些不直接透明到業務的專項。目前參與程度深淺不一，但總體這個過程讓我感受到了一件事情：

• 不能憑想象和自我經驗判斷說團隊需要什麼？你要的答案一定要去和團隊對話，和團隊成員對話，或者參與到不同形态的“他們”當中去，去發掘他們想要什麼。

收集資訊和問題是做決策和方案的第一步，這個觀點說出來大家都知道，但是實際做的過程中可能不一定能想得到了。舉個例子：

• 你要做工具，做給新人的，就要站在新人的角度來使用它，發現它是不是真的有用。做給流程規範的就必須站在項目實踐的角度去實踐TA，而且不是你自己覺得好用就樂呵呵，因為你自己并不是“架構”這個方向的真正使用者
• 更典型的例子，前端的自動化測試。做之前第一件事情是弄清楚在目前時間節點下，目前團隊狀況下，團隊是否需要TA。進而才是怎麼在團隊的層面上去落地這件事情。而不是自己想當然的做一套方案。目前的團隊并不需要這個東西，那麼方案再完善又有什麼用？

“架構是屬于團隊的”，這個觀點一個方面是上面所說的，TA的需求和解決方案應該來源于目前團隊。另一個方面是架構的進展和設計一定也是對團隊透明和公開的。 如果進展和方案不能随時保持對于團隊的公開和透明，也很難保證當到了最終産出的時候，還能保持最開始的方向一緻性。

今年上半年開始，我們的周會内容有了小小的變動，把以往的單純的團隊内分享的例會轉變為一個始終圍繞團隊基礎建設，團隊發展，和個人發展的交流會。植入了一個每周固定的環節，就是“基礎建設進展和問題一周彙總”。

保持公開和透明，也可以随時就問題進行讨論。給自己和團隊一個面對面的機會。

確定是大家想要的，同時也希望能潛移默化的形成大家對于團隊建設的方向感和全局觀。

我了解的架構：是橫向全局的

這應該是做“架構”最基礎的要求。也就是需要對整個團隊，結合整個行業的發展保持全局的觀望和了解。并且可以在此基礎上基于團隊現狀做出對未來的基本判斷。 “做出判斷”這件事情，說簡單也簡單，說難也難。簡單的是無非就是做幾個選擇題，選出今年，或者近期内要做的事情。難得是怎麼來保證你的選擇在目前的團隊來看，是正确的。什麼階段做什麼事情。

我記得今年上半年開始，我開始嘗試擔起前端團隊的基礎建設收斂相關的事情的時候。結合去年和今年的現狀，整理過一個簡單的架構圖。在 

"手淘前端在工程化道路上的“匍匐”"

 文章裡面有Po過。後來有過一些更新和小調整。大緻如下：

https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2F3f9c3d51b6afe0784ca3b664ca346f78196d77ad%2F687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f37636164373432316231363761613436323462356666626233386230613435656535643130643632

歸結起來是

• 兩個中心 （端和效率）
• 八個方向
  • 基礎庫+功能元件+UI架構 （對應“效率”）
  • “端”的延伸 （對應“端”）
  • 規範和工程流程
  • 工具鍊路
  • 資料和性能
  • 自動化測試+持續內建
  • 前端安全
  • 服務和周邊

八個方向中，落實到兩個中心的必然是今年的重點。工具和性能是去年的重點，今年在已有基礎上更新。其他的子方向在今年會開始探索。 這其中由于團隊曆史和現狀的原因，其實有一些點是大家都在火熱在抓的，但在我們團隊中并沒有放到今年的重點。比如

• 前後端分離

也有在目前團隊現狀還不到時候做的（并不緊迫）的事情，比如

• 前端基礎服務（包括建構和工程的服務化，新人系統，内部項目域名和服務資源申請和部署自動化.. 等等）

以上的資訊可以了解為“架構是橫向全局” 這個觀點的一個表現。

個人覺得做出判斷的前提确實是需要了解别的優秀的團隊在做什麼，行業在做什麼。再結合團隊的現狀才有可能知道我們需要做什麼。

然而，了解别人的過程，其實反而也是讓人“謙卑”的過程。

有時候知道的越多，會讓人覺得越渺小。

你覺得自己在某方面做的還不錯了，但是一定有人有團隊有更優秀的方案和實踐。

是以，“全局”，不僅是對于自己團隊現狀的全局認知和判斷，也是在其他團隊放到一起的“全局”評估。

• 全局意味着 - 清楚的知道團隊在目前階段應該做什麼事情
• 全局意味着 - 清楚的知道團隊的現狀，優勢和問題
  • 不至于高傲的迷失了方向
  • 也不至于卑微的找不到出路

我了解的架構：也是垂直深入的

在我的了解裡，所謂“做架構”的同學們，不應該隻是單純的有“全局觀”。同時也需要對每個垂直的領域保持一定的“絕對深度”。

就拿上面關于“全局”的幾個子方向來說，我希望在目前定下的細分領域，想要做“架構”的同學在任何一個細分領域上都能保持一定的絕對深度。可能對于一個人的精力和資源會有一些挑戰，但是我覺得在一定程度上是應該的。

在精力允許的範圍内，每一個子領域裡應該都需要盡可能的參與方案的探讨，制定，代碼的實作，團隊的落地整個過程。

拿我們自己團隊的情況來說，至少應該知道：

• 基礎庫群組件庫，UI架構
  • 未來形态的發展應該是什麼樣？
  • CommonJS子產品範式的遷移的自動化實作方案是什麼？代碼實作思路是什麼？
  • 子產品依賴關系弱關系到強關系的包裝需要做哪些事情？
  • 控件的規範是否需要遷移到WebComponents？
  • 如果遷移，規範是什麼，怎麼定最小Feature的polyfill集合？
  • polyfill代碼應該怎麼來實作？
  • UI部分的元件複用應該怎麼來做？可視化還是指令化？
  • UI庫的mixin部分的style-lib群組件層面的view-lib怎麼更好的管理？
  • ...
• 端的部分
  • ReactNative的現狀和痛點是什麼？解決方案是什麼？代碼實作的難點在哪裡？
  • RN的元件庫怎麼來組織建構？一個RN的元件應該怎麼來寫？
  • RN在性能和穩定性上的解法有哪些？現狀是什麼？
  • 業務層面的資料上報方案是什麼？代碼上的思路該怎麼做？
  • 是否能明晰的判斷未來，知道什麼時候該堅持？什麼時候該尋找别的出路？
  • GDOS的目标和意義是什麼？為什麼要做GDOS？
  • 對接通用算法和選品的難點是什麼？怎麼樣定商品化的json schema?
  • 甚至java的部分，hsf的對接是否也能夠參與？

以上舉例，提出每個子方向細化的問題，在心裡對重要的細節有認知，有答案，也是我認為做“架構”的同學所必須要明白的事情。

同理，

工具層面，規範層面，工程流程，性能，單元測試，前端安全等等，期望盡可能深的參與到具體的實踐和落地上去。(包括代碼的具體實作...)

https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2F2589d218d6c73c65c88af78c493404e5f5a66c01%2F687474703a2f2f67772e616c6963646e2e636f6d2f746673636f6d2f5442316c4e494a4946585858586370585658585f5669454b5858582d313434382d313038322e706e675f33303078333030733135302e6a7067 https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2F1cb23f28e4cb928a89df3673d03e6a3a990af7c9%2F687474703a2f2f67772e616c6963646e2e636f6d2f746673636f6d2f54423132666e5649585858585861585856585832444b63464658582d313133322d3530382e706e675f33303078333030733135302e6a7067 https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2Fd99d2e7358e7e28fe9dea0c1955fdb7e11651b00%2F687474703a2f2f67772e616c6963646e2e636f6d2f746673636f6d2f54423158514d33495858585858585f61705858734f33434f5858582d313631382d313232342e706e675f33303078333030733135302e6a7067 https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2F6dcf389452e66fe2622aa44420a078b2993cdc31%2F687474703a2f2f67772e616c6963646e2e636f6d2f746673636f6d2f54423174734a35494658585858616358565858686e5156304658582d313935322d3737302e706e675f34303078343030733135302e6a7067 https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2Fe55890736d3255d3eaa8cd987fa8ce9e939c6dd5%2F687474703a2f2f67772e616c6963646e2e636f6d2f746673636f6d2f5442316749637949705858585862485846585850686f54517058582d313937322d313035362e706e675f34303078343030733135302e6a7067

做架構不是隻有idea，然後全部推動别人去做，更重要的是自己需要深度的參與，才能保持清醒的認知。

這是我個人的認知，不一定對，當然

• “在保持廣度的情況下還要保持一定的深度”

也會對于個人的時間精力有一定的挑戰。

反過來說，如果“架構”已經大到需要5個人以上的團隊才能支撐，那時再做合理的分工也不遲。

我了解的架構：是海納百川，是透明開放的

在之前的表述中，提到“架構”至少是需要對團隊透明的，來源于團隊，尊重團隊，也服務于團隊。而這裡說的海納百川，開放透明更是側指我們以公司機關，那麼理應在公司内也是透明和開放的。

• 對外不用多說，公司自有公司的壁壘，但至少對内，我們應該共享一片藍天。

https://link.juejin.im/?target=https%3A%2F%2Fcamo.githubusercontent.com%2Fbaafd3833c5f9cf9e01dfef218622ec1a150c5ad%2F687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f30326530323865623235346331636537373964343437636463633166386262323066333333626666

當你不關注，不聞不問的時候，或許還不覺得，但是當有心想去了解一些事情的時候，卻發現似乎并沒有想象中那麼透明。

我在 

上周的周報:不聊技術，聊感受

 中其實提到了一些關于“技術棧”和“技術棧”之前的壁壘問題，也包含“前端”本身團隊壁壘的問題。

我的觀點是：

• 團隊技術壁壘不是問題，畢竟每個團隊的業務形态，抓的方向并不一緻。但是不透明是問題，想發掘其他團隊的好東西卻要費點功夫。

其實回過頭來想想，集團内其實有不少的方式似乎想解決這個問題，比如淘寶的“懶懶”，支付寶的“芝士會” 等等，從定期主題分享的方式嘗試抹平BU間不透明的問題。也有屬于集團層面的技術博 ATA， 包括前端也有自己的 委員會，本質上也是希望打通BU間的資訊。

我們看起來有這些途徑，理應可以解決不少壁壘不透明的問題才對，可是到我真實的感受卻是還有好多有價值的資訊，方案，項目等，我從上面的管道擷取不到的。

可能是“粒度”的問題，可能是“傳達”的問題。咋們暫時先不去細究。說實話，我個人覺得比較直接打破我覺得有壁壘的苦惱的事情是 @拔赤 公開的周報。

我近期了解到很多航旅有價值的資訊，他們近期着重發力的方向，不可置否的說，基本都是從 @拔赤 每周的周報中覓得的。當然，這和他向來高品質的周報内容有直接關系。

是以，我做的第一件事也是把無線前端從今年上半年開始的每周基礎建設，架構的方向和進展以周報的形式公開來。一方面從我們自己開始做到“透明化”，同時也願意以謙卑的心态和大家進行讨論和交流。

阿裡内外的周報系統我覺得是個好的開始。既然有選擇“公開”的選項，我覺得也應該加上“周報關注”的功能，隻要我關注的人某一周的周報内容是“公開”的，不管他的周報有沒有直接抄送我，我都可以收到。

話題有點扯遠了，我要表達的意思是，我期望尋得一種途徑，可以讓我短平快，高效的知道優秀的大家們都在做什麼事情。

最近在團隊内開始推動一個叫做 

“取經之路”

 的計劃，其實也就是希望團隊的同學都能保持有心思去發掘其他團隊的優秀的東西，以取經的形式主動去了解，再帶回來傳道授業解惑。

希望團隊本身能從中開拓視野和思路，同時對于做“唐僧”的同學來說，本身也是一種成長。

我了解的架構：關鍵詞不是“高精尖”，而是“合适”

最近越發的覺得“合适”這個詞的精妙與深意。站在外人的角度，去評判一件事情的好壞，一個技術方案的優劣，不應該從你的角度去看，連行業的普适标準甚至都不一定受用。因為可能在你看來有失偏頗的方案在他的團隊的當下就是“合适”的。

換句話說：

• 在我看來，技術方案優和劣或許沒有絕對之分，隻是因為團隊的曆史原因，團隊現狀，發展出了不同的樣子。隻要它對于目前的團隊是合适的，我就認為它是好的。

說到這裡，我不免又想到了“戀愛”這件事。如果這麼說來的話，不覺得和“戀愛”的情況略像麼。通俗點說：

• 愛美之心，人皆有之；漂亮的女孩子，誰都喜歡，你費勁心思去追一個大家公認的女神，這件事情能不能成，最終是變成“金童玉女”的千古流傳段子還是變成“癞蛤蟆想吃天鵝肉”的惡俗劇情，前提是要認清自己。目前的自己如果如果就是配不上女神，那何必自讨苦吃，還不如努力錘煉自己，到有一天走上人生巅峰再去赢取白富美也不遲不是麼 ;)

比方不一定恰當，但是道理是通的。我想說的是，技術的方案和設計是不是好的，對的，不是看你用的技術，選的方案是不是夠高精尖，夠前沿。而是看TA是不是适合你目前的團隊現狀。

舉個例子：

• ES6 當下被好多團隊在實踐，吵得火熱。可以了解為ES6的産品化，包括周邊polyfill的完善，以及一整套方案的打通，在當下看起來是靠前沿的，面向未來的，高精尖的。 如果我們的團隊就那麼幾個人，如果團隊負責的業務就那麼兩三個，形态也相對單一，那麼我覺得快速的擁抱ES6，嘗鮮，玩新技術沒有任何問題。而反過來，如果目前團隊的體量，現狀，團隊組成不允許一個步子邁這麼大，那麼這件事如果硬按“拔苗助長”的方式推進，有可能會産生很大的副作用，開發效率，品質保障可能都會收到影響。

是以，架構和方向不應該朝着“高精尖”的方向走，那不應該是目标，“合适”的，才是最好的。

在适當的時候，用适當的方案去做對應适當的事情，

就好比，

在适當的時候，遇上對的人。

原文釋出時間為：2018年6月12日

原文作者：github.com

本文來源：

掘金

如需轉載請聯系原作者