前端，真的是讓我哭笑不得的職業(yè)，從幾年前作為打醬油的理想職業(yè)到現(xiàn)在的熱門職業(yè)，無疑在這個(gè)過程中，門檻變高了，而且還是非常高。一大堆的框架和庫(kù)，像什么vue啦、react啦、angular啦、webpack啦等等等等。讓人眼花繚亂

首先說說工作場(chǎng)景。目前做的項(xiàng)目是微信h5相關(guān)的，選擇的是react那一套的技術(shù)棧。

現(xiàn)在前端js中，基本上已經(jīng)是普及了模塊化的概念，從很早的seajs、requirejs到現(xiàn)在的es自帶的模塊化系統(tǒng)，已經(jīng)是越來越完善。

import request from 'superagent' import { getToken } from "../../actions/global"; import { Toast } from "antd-mobile"; import { getQueryString, url_for, isWeiXin } from "../global_agency";

都是通過import的方式很方便的來引用各個(gè)模塊里面方法，但隨著項(xiàng)目的不斷迭代，文件越來越多，就很容易會(huì)出現(xiàn)下面這種情況。

這就造成了模塊間的方法很混亂的傳遞。這樣的情況在一開始是無傷大雅的，項(xiàng)目的前期，每個(gè)模塊的每個(gè)方法的作用都是很明確的對(duì)應(yīng)著項(xiàng)目的某個(gè)地方，依然保持著簡(jiǎn)潔。但是到了項(xiàng)目的中后期，就會(huì)出現(xiàn)破壞性的混亂。為什么這樣說呢？試想一下，當(dāng)你某個(gè)方法使用的地方從一開始固定的一個(gè)變成了后來的不知道多少個(gè)，方法的遷移以及方法對(duì)應(yīng)模塊文件的遷移就會(huì)變得特別困難，雖然目前的IDE足夠完善到已經(jīng)可以做文件遷移后相應(yīng)文件位置的批處理了，但或多或少的還是讓人不安。經(jīng)歷過的人會(huì)明白我的感受！

混亂也意味著后期開發(fā)會(huì)越來越難，這也意味著代碼耦合度高，準(zhǔn)確的說應(yīng)該是項(xiàng)目結(jié)構(gòu)的耦合度高。一個(gè)模塊到處可以使用import引入使用確實(shí)很方便，卻也給我們帶來了煩惱。我們要做的就是通過增加模塊傳遞的約束條件來讓結(jié)構(gòu)耦合度變低，當(dāng)然代價(jià)就是失去這種完全的便利，也可以說是規(guī)范這種便利。

那么我們應(yīng)該怎么做呢？一圖勝千言！

如上圖所示，我們可以建一個(gè)中轉(zhuǎn)文件，把我們覺得可以統(tǒng)一管理的但又比較分散的模塊文件中的方法統(tǒng)一import到這個(gè)中轉(zhuǎn)文件中，如下圖：

這就有點(diǎn)像一個(gè)中介者模式，說形象點(diǎn)就像是飛機(jī)場(chǎng)、飛機(jī)以及工作人員的關(guān)系，假設(shè)每架飛機(jī)都有固定的工作人員，但是所有的飛機(jī)的工作人員都是由飛機(jī)場(chǎng)管理的，就算是這一架飛機(jī)需要另一家飛機(jī)的工作人員幫忙，也是要通過飛機(jī)場(chǎng)來調(diào)控。

我們的代碼結(jié)構(gòu)也是一樣的道理。這樣做的好處是在讓結(jié)構(gòu)清晰、可讀性變強(qiáng)的同時(shí)，結(jié)構(gòu)耦合度也降低了，到后續(xù)我們還能很方便的在各個(gè)模塊內(nèi)部做一些適當(dāng)?shù)姆庋b以滿足更多的需求。就像一架飛機(jī)里面有機(jī)長(zhǎng)、副機(jī)長(zhǎng)、乘務(wù)人員等等，他們都有不一樣的工作職能。

以上就可以是一次架構(gòu)提升，我相信我們的日常工作中可以有很多這樣的架構(gòu)提升的機(jī)會(huì)。

文章題目是關(guān)于前端架構(gòu)，那么有的同學(xué)可能就會(huì)想:前端還需要架構(gòu)嗎？這個(gè)問題我自己也不知道，其實(shí)很早之前就聽說過前端架構(gòu)這個(gè)詞，也只是只見過豬跑沒吃到肉。我聯(lián)想到前端架構(gòu)之前的第一個(gè)問題是在我做的項(xiàng)目快要百八十個(gè)文件的時(shí)候，自己感覺有點(diǎn)亂，雖然自己也還可以接受，畢竟項(xiàng)目也是在正式環(huán)境好好地運(yùn)行著，但是如果這個(gè)項(xiàng)目交到下一個(gè)項(xiàng)目負(fù)責(zé)人手里，那他的日子就不好過了，在我這里的有點(diǎn)亂，到了他那里就會(huì)變成非常亂。于是我還是為自己積積德，去整理一下。

于是乎我在網(wǎng)上下載了一本電子書，名叫《恰如其分地軟件架構(gòu)》，是之前有幸跟閑魚的宗心交流的時(shí)候他推薦的（值得一提的是，大公司還是有很多有大家風(fēng)范的人的）。這本書里面都是傳授架構(gòu)的思想，并沒有很明確的架構(gòu)的具體方法。所以這是一本好書，授人以魚不如授人以漁嘛。

當(dāng)我們選擇了諸如react、vue、angular等這些技術(shù)棧，其實(shí)我們就已經(jīng)選擇了一整套的現(xiàn)成的架構(gòu)，視圖寫在哪里、接口調(diào)用寫在哪里、路由寫在哪里等等的做法都已經(jīng)有很成熟的范式給我們運(yùn)用。

往往在同一個(gè)項(xiàng)目面前，會(huì)有三種不同的人：不做架構(gòu)的人、選擇做架構(gòu)的人和完善架構(gòu)的人。

選擇了技術(shù)棧，我們還僅僅是選擇做架構(gòu)的人，但是還不是完善架構(gòu)的人。所謂的完善架構(gòu)，也就是架構(gòu)提升。就跟剛才說的，我們已經(jīng)選擇的技術(shù)棧，選擇了一套現(xiàn)成的架構(gòu)，但是請(qǐng)相信我，這套架構(gòu)絕對(duì)不是沒有任何缺點(diǎn)了。我們?cè)谧鲰?xiàng)目的過程中，可能這也是發(fā)現(xiàn)現(xiàn)成架構(gòu)缺點(diǎn)的過程，那么在這個(gè)過程中，或者在這個(gè)過程之后，我們可不可以想法設(shè)法去完備它？答案是肯定的。怎么樣才算完備？這就要問我們自己了。

總結(jié)

以上是生活随笔為你收集整理的记录一个前端架构的想法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。