前端，真的是讓我哭笑不得的職業，從幾年前作為打醬油的理想職業到現在的熱門職業，無疑在這個過程中，門檻變高了，而且還是非常高。一大堆的框架和庫，像什麼vue啦、react啦、angular啦、webpack啦等等等等。讓人眼花繚亂
首先說說工作場景。目前做的專案是微信h5相關的，選擇的是react那一套的技術棧。
現在前端js中，基本上已經是普及了模組化的概念，從很早的seajs、requirejs到現在的es自帶的模組化系統，已經是越來越完善。
import request from 'superagent'
import { getToken } from "../../actions/global";
import { Toast } from "antd-mobile";
import { getQueryString, url_for, isWeiXin } from "../global_agency";
複製程式碼都是通過import的方式很方便的來引用各個模組裡面方法，但隨著專案的不斷迭代，檔案越來越多，就很容易會出現下面這種情況。
這就造成了模組間的方法很混亂的傳遞。這樣的情況在一開始是無傷大雅的，專案的前期，每個模組的每個方法的作用都是很明確的對應著專案的某個地方，依然保持著簡潔。但是到了專案的中後期，就會出現破壞性的混亂。為什麼這樣說呢？試想一下，當你某個方法使用的地方從一開始固定的一個變成了後來的不知道多少個，方法的遷移以及方法對應模組檔案的遷移就會變得特別困難，雖然目前的IDE足夠完善到已經可以做檔案遷移後相應檔案位置的批處理了，但或多或少的還是讓人不安。經歷過的人會明白我的感受！
混亂也意味著後期開發會越來越難，這也意味著程式碼耦合度高，準確的說應該是專案結構的耦合度高。一個模組到處可以使用import引入使用確實很方便，卻也給我們帶來了煩惱。我們要做的就是通過增加模組傳遞的約束條件來讓結構耦合度變低，當然代價就是失去這種完全的便利，也可以說是規範這種便利。
那麼我們應該怎麼做呢？一圖勝千言！
如上圖所示，我們可以建一箇中轉檔案，把我們覺得可以統一管理的但又比較分散的模組檔案中的方法統一import到這個中轉檔案中，如下圖：
這就有點像一箇中介者模式，說形象點就像是飛機場、飛機以及工作人員的關係，假設每架飛機都有固定的工作人員，但是所有的飛機的工作人員都是由飛機場管理的，就算是這一架飛機需要另一家飛機的工作人員幫忙，也是要通過飛機場來調控。
我們的程式碼結構也是一樣的道理。這樣做的好處是在讓結構清晰、可讀性變強的同時，結構耦合度也降低了，到後續我們還能很方便的在各個模組內部做一些適當的封裝以滿足更多的需求。就像一架飛機裡面有機長、副機長、乘務人員等等，他們都有不一樣的工作職能。
以上就可以是一次架構提升，我相信我們的日常工作中可以有很多這樣的架構提升的機會。
文章題目是關於前端架構，那麼有的同學可能就會想:前端還需要架構嗎？這個問題我自己也不知道，其實很早之前就聽說過前端架構這個詞，也只是只見過豬跑沒吃到肉。我聯想到前端架構之前的第一個問題是在我做的專案快要百八十個檔案的時候，自己感覺有點亂，雖然自己也還可以接受，畢竟專案也是在正式環境好好地執行著，但是如果這個專案交到下一個專案負責人手裡，那他的日子就不好過了，在我這裡的有點亂，到了他那裡就會變成非常亂。於是我還是為自己積積德，去整理一下。
於是乎我在網上下載了一本電子書，名叫《恰如其分地軟體架構》，是之前有幸跟閒魚的宗心交流的時候他推薦的（值得一提的是，大公司還是有很多有大家風範的人的）。這本書裡面都是傳授架構的思想，並沒有很明確的架構的具體方法。所以這是一本好書，授人以魚不如授人以漁嘛。
當我們選擇了諸如react、vue、angular等這些技術棧，其實我們就已經選擇了一整套的現成的架構，檢視寫在哪裡、介面呼叫寫在哪裡、路由寫在哪裡等等的做法都已經有很成熟的正規化給我們運用。
往往在同一個專案面前，會有三種不同的人：不做架構的人、選擇做架構的人和完善架構的人。
選擇了技術棧，我們還僅僅是選擇做架構的人，但是還不是完善架構的人。所謂的完善架構，也就是架構提升。就跟剛才說的，我們已經選擇的技術棧，選擇了一套現成的架構，但是請相信我，這套架構絕對不是沒有任何缺點了。我們在做專案的過程中，可能這也是發現現成架構缺點的過程，那麼在這個過程中，或者在這個過程之後，我們可不可以想法設法去完備它？答案是肯定的。怎麼樣才算完備？這就要問我們自己了。