Vue實戰—從目錄結構談可擴展項目架構設計

不少人都會用項目腳手架，也會跑hello world，而後再寫寫簡單的todolist。可是再往下深刻就難了。好比不少教程和老師都會說，你們要多問一個爲何。其實我想說多問你妹啊。我都不知道問爲何怎麼多問？！好比若是我不說，不多有人會去思考和研究爲何vue的項目目錄要如此設計，這麼作好處。

先不說說別的，咱們先看看vue的目錄，一圖抵萬言，不墨跡。

好的項目代碼結構會大大提高項目的維護性和可擴展性。同時咱們能夠提供友好的說明，以便其餘成員理解項目和快速定位。

其實有一點比較重要，就是公共組件、工具等同類的文件，放置一塊兒維護會比較好。並且還有個小 技巧，咱們能夠在搭建項目的時候，在 README.md 裏面描述下該項目下的代碼和文件結構。

多說無益，我這裏直接給你們一個示意圖，你們能夠按照我給的這個項目結構組織項目。

這裏我強調兩點，

1.第一點注意每個組件的大小寫。

2.注意每一個組件所用到的圖片的位置。

不少人寫組件的時候被命名或者大小寫或者分隔符弄的暈頭轉向，這裏我就說說代碼規範。

代碼規範實際上是團隊合做中最重要的地方，使用相同的代碼規範，會大大減小咱們接手別人代碼時候臥槽的次數。

好的寫碼習慣很重要，命名習慣、適當的註釋，會對代碼的可讀性有很大的提高。可是習慣是每一個人都不同，因此在此之上，咱們須要有這樣統一的代碼規範。

一些工具能夠很好地協助咱們，像 Eslint、Tslint等，加上代碼的打包工具協助，能夠把一些規範強行標準化，來獲取代碼的統一性。還有像 prettier 這樣的工具，能自動在打包的時候幫咱們進行代碼規範化。

除了這些簡單的什麼駝峯啊、全等啊、單引雙引等基礎的規範，其實更重要的是流程規範。最基礎的是改動公共庫或是公共組件的時候，須要進行 code review。一般咱們使用 Git 維護代碼，這樣在合併或是版本控制上有更好的體驗。

但其實最重要的仍是溝通，溝通是一個團隊裏必不可少同時很容易出問題的地方，要學會溝通方式、表達方式。

不少人以爲命名了或者項目目錄了這些不重要，非得把複雜的功能實現出來才牛逼，這纔是技術大牛或者腦殼上閃耀着光環的架構師的範兒。其實，項目的維護全部程序員都須要，並且要想成爲一個架構師，你寫的代碼別人是否能看得，用着舒服，架構是否健壯可擴展，這些是基本功。你連文件目錄都設計很差，我拿什麼相信你能設計出來可擴展的程序？