記錄一個前端架構的想法

前端，真的是讓我啼笑皆非的職業，從幾年前做爲打醬油的理想職業到如今的熱門職業，無疑在這個過程當中，門檻變高了，並且仍是很是高。一大堆的框架和庫，像什麼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等這些技術棧，其實咱們就已經選擇了一整套的現成的架構，視圖寫在哪裏、接口調用寫在哪裏、路由寫在哪裏等等的作法都已經有很成熟的範式給咱們運用。

每每在同一個項目面前，會有三種不一樣的人：不作架構的人、選擇作架構的人和完善架構的人。

選擇了技術棧，咱們還僅僅是選擇作架構的人，可是還不是完善架構的人。所謂的完善架構，也就是架構提高。就跟剛纔說的，咱們已經選擇的技術棧，選擇了一套現成的架構，可是請相信我，這套架構絕對不是沒有任何缺點了。咱們在作項目的過程當中，可能這也是發現現成架構缺點的過程，那麼在這個過程當中，或者在這個過程以後，咱們可不能夠想法設法去完備它？答案是確定的。怎麼樣纔算完備？這就要問咱們本身了。