我理解的阿里無線前端“架構”

寫在前面的話：

對於文中涉及“脫敏”的內容，連結經常一環套一環，無法輸出，很抱歉…
懷著一個醞釀了蠻長時間的念頭，開啟電腦，想對一些思考做一點記錄。關於標題，關於“前端”，關於“架構” 。
其實是有蠻多話想說的，但是前面這幾個字卻打上去了又刪掉。想為下面的內容找一個合適的開始。但是似乎總是不那麼如意。
回到這個話題，或許應該從以前的認知慢慢說起。

過往的認知

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

總覺得在這個階段，

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

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

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

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

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

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

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

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

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

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

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

“架構是屬於團隊的”，這個觀點一個方面是上面所說的，他的需求和解決方案應該來源於當前團隊。另一個方面是架構的進展和設計一定也是對團隊透明和公開的。

如果進展和方案不能隨時保持對於團隊的公開和透明，也很難保證當到了最終產出的時候，還能保持最開始的方向一致性。

今年上半年開始，我們的週會內容有了小小的變動，把以往的單純的團隊內分享的例會轉變為一個始終圍繞團隊基礎建設，團隊發展，和個人發展的交流會。植入了一個每週固定的環節，就是“基礎建設進展和問題一週彙總”。
保持公開和透明，也可以隨時就問題進行討論。給自己和團隊一個面對面的機會。
確保是大家想要的，同時也希望能潛移默化的形成大家對於團隊建設的方向感和全域性觀。

我理解的架構：是橫向全域性的

這應該是做“架構”最基礎的要求。也就是需要對整個團隊，結合整個行業的發展保持全域性的觀望和了解。並且可以在此基礎上基於團隊現狀做出對未來的基本判斷。

“做出判斷”這件事情，說簡單也簡單，說難也難。簡單的是無非就是做幾個選擇題，選出今年，或者近期內要做的事情。難得是怎麼來保證你的選擇在當前的團隊來看，是正確的。什麼階段做什麼事情。

我記得今年上半年開始，我開始嘗試擔起前端團隊的基礎建設收斂相關的事情的時候。結合去年和今年的現狀，整理過一個簡單的框架圖。在 “手淘前端在工程化道路上的“匍匐”” 文章裡面有Po過。後來有過一些更新和小調整。大致如下：

歸結起來是

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

八個方向中，落實到兩個中心的必然是今年的重點。工具和效能是去年的重點，今年在已有基礎上升級。其他的子方向在今年會開始探索。

這其中由於團隊歷史和現狀的原因，其實有一些點是大家都在火熱在抓的，但在我們團隊中並沒有放到今年的重點。比如

• 前後端分離

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

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

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

個人覺得做出判斷的前提確實是需要了解別的優秀的團隊在做什麼，行業在做什麼。再結合團隊的現狀才有可能知道我們需要做什麼。
然而，瞭解別人的過程，其實反而也是讓人“謙卑”的過程。

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

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

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

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

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

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

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

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

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

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

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

同理，工具層面，規範層面，工程流程，效能，單元測試，前端安全等等，期望儘可能深的參與到具體的實踐和落地上去。(包括程式碼的具體實現…)

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

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

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

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

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

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

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

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

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

我在 上週的週報:不聊技術，聊感受 中其實提到了一些關於“技術棧”和“技術棧”之前的壁壘問題，也包含“前端”本身團隊壁壘的問題。

我的觀點是：

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

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

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

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

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

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

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

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

最近在團隊內開始推動一個叫做 “取經之路” 的計劃，其實也就是希望團隊的同學都能保持有心思去發掘其他團隊的優秀的東西，以取經的形式主動去了解，再帶回來傳道授業解惑。
希望團隊本身能從中開拓視野和思路，同時對於做“唐僧”的同學來說，本身也是一種成長。

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

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

換句話說：

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

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

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

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

舉個例子：

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

所以，架構和方向不應該朝著“高精尖”的方向走，那不應該是目標，“合適”的，才是最好的。

在適當的時候，用適當的方案去做對應適當的事情，就好比，在適當的時候，遇上對的人。