寫在前面的話：

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

過往的認知

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

[[147693]]

總覺得在這個階段，

• 所謂的前端架構更多的是在紙上談兵，拿以往的軟件工程的思想和概念硬往自己身上套。

• 所謂的做架構的同學更多的是在炫耀自己的技術深度和視野，看到前沿的技術不管合不合適就拿來做方案，硬往業務上推，來成全自己的KPI

• 總覺的所謂的“技術架構”無非就是一些個人主觀化的思路和概念，形成一些看起來成體系的代碼組織方式，以便完成業務后可以說：看，基于我的架構有多好的通用性，擴展性，代碼看起來多優雅…

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

• 要么和之前的我一樣，嗤之以鼻，做架構的有什么了不起，無非是老板給你安排個“輕松點的活”，做做方案，不用受業務的壓迫。還得逼著一線每天認真辛苦的碼代碼的同學接受你一時想出來的Idea。

• 要么是另一個極端，覺得做架構的同學就NB，覺得比做業務的同學從概念上就高一個等級。然后死命的想要往“架構”這個方向靠。

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

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

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

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

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

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

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

• 你要做工具，做給新人的，就要站在新人的角度來使用它，發現它是不是真的有用。做給流程規范的就必須站在項目實踐的角度去實踐TA，而且不是你自己覺得好用就樂呵呵，因為你自己并不是“架構”這個方向的真正用戶

• 更典型的例子，前端的自動化測試。做之前第一件事情是弄清楚在當前時間節點下，當前團隊狀況下，團隊是否需要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個人以上的團隊才能支撐，那時再做合理的分工也不遲。

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

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

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

[[147695]]

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

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

我的觀點是：

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

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

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

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

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

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

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

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

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

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

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

換句話說：

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

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

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

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

舉個例子：

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

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

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