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

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

選擇了技術棧，我們還僅僅是選擇做架構的人，但是還不是完善架構的人。所謂的完善架構，也就是架構提升。就跟剛才說的，我們已經選擇的技術棧，選擇了一套現成的架構，但是請相信我，這套架構絕對不是沒有任何缺點了。我們在做項目的過程中，可能這也是發現現成架構缺點的過程，那么在這個過程中，或者在這個過程之后，我們可不可以想法設法去完備它？答案是肯定的。怎么樣才算完備？這就要問我們自己了。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。