專案資料夾架構
今天談談專案資料夾的結構,在還沒開始寫任何程式前,可以思考的是檔案要怎麼收納。
不知道各位情場高手都怎麼收納前男友或前女友們的禮物呢? 是按照物品種類來分類? 還是依照對象來分類? 或是直接丟掉?
隨著數量上升後管理的難度也會上升,以小編這幾年看過不少專案的經驗下來,覺得程式碼也跟收納一樣分成兩種流派
- 按照屬性分類
- 按照功能分類
接下來就讓我們看看兩種收納的差別吧!
屬性分類
會看屬性分得多細,若是分類比較粗一點,當衣服的數量變多就會變成很難找到整套運動服該如何正確搭配,屬性分類用衣服的概念來看就是分類成
- 全部的內衣
- 全部的內褲
- 全部的褲子
- 全部的上衣
- 全部的外套
依專案來說,小編認為小專案較適合這種配置,比較適合拿來學習新知識時使用。
功能分類
當衣服變多的時候也知道怎麼依照功能找到全部相關的配套,不過由於依照功能區分,就會需要比較多的種類,功能分類就會是
- 慢跑外套、上衣、褲子、內衣、內褲
- 登山外套、上衣、褲子、內衣、內褲
- 約會外套、上衣、褲子、內衣、內褲
- 上班外套、上衣、褲子、內衣、內褲
- 居家外套、上衣、褲子、內衣、內褲
- 休閒外套、上衣、褲子、內衣、內褲
依專案來說,小編認為大專案較適合這種配置,每個功能都會有自己屬於的資料夾,對菜鳥工程師來說則是快樂小天地。
React.js 前端專案架構
一般會有元件、API、資料流、樣式相關分類。
React 是 component-based 的前端 UI 函式庫,通常會配合其他函式庫使用:
- react-router: 處理 SPA 的路由
- redux: 做統一的狀態管理,協助元件之間的溝通
- redux-thunk or redux-saga: 處理 AJAX 的 side effect
前端專案依屬性分類
比較小的專案如果不包含 Redux 可以簡單分類
api/
├─ ProfileAPI.js
└─ UserAPI.js
components/
├─ Footer.js
├─ Footer.css
├─ Profile.js
├─ ProfileHeader.js
└─ ProfileHeader.css
搭配 Redux 後,主要就是增加元件之間需要溝通工具,會有以下特性:
- 單向資料流
- 公共的狀態儲存 (Store)
專案架構也會受到這種概念去分類:
- actions: 觸發狀態改變用的 function
- pages: 頁面容器元件
- containers: 有連接 Store
- components: 沒有連接 Store
- reducers: 收到 action 後的資料邏輯
所以專案資料夾架構依照屬性去分類就會長成下面這個樣子,在完成任務的過程中需要在多個不同的資料夾中來回,覺得較適合小型專案。
└── src
├── actions
│ ├── typeOneActions.js
│ └── typeTwoActions.js
├── api
│ ├── apiHandler.js
│ ├── typeOneApi.js
│ └── typeTwoApi.js
├── components
│ ├── TypeOneComponent.jsx
│ ├── TypeOneListComponent.jsx
│ ├── TypeTwoComponent.jsx
│ ├── TypeTwoPageComponent.jsx
│ └── HomePageComponent.jsx
├── containers
│ ├── TypeOneContainer.js
│ └── TypeTwoPageContainer.js
├── pages
│ └── HomePageContainer.js
├── index.js
├── reducers
│ ├── typeOneReducer.js
│ └── typeTwoReducer.js
├── routes.js
├── store.js
└── utils
以之前弄的小專案當例子,如果有加上 redux 的話,專案架構大概會長成下面的樣子,在比較簡單的專案中可以更簡化。
├── .storybook
├── src/
│ ├── constants/
│ ├── utils/
│ ├── pages/
│ ├── containers/ # containers 放置與 Redux 連接的相關元件,單元測試檔案為 `元件名稱.test.js`
│ ├── components/ # components 放置相關元件,單元測試檔案為 `元件名稱.test.js`
│ │ └── Root.js # 路由根目錄
│ ├── hooks/ # hooks 相關
│ ├── middleware/ # 資料處理相關
│ │ ├── API.js # axios 的 instance
│ │ └── redux-api.js # redux-api
│ ├── styles/ # 樣式檔們
│ ├── index.js # 程式入口
│ ├── serviceWorker.js
│ └── setupTests.js # 測試相關設定
├── .eslintrc # ESLint 設定檔
├── .prettierrc # prettierrc 工具設定
├── .travis.yml # 持續發佈工具
├── package-lock.json
├── package.json
└── README.md
Side Effect 處理
平常不太會去特別注意的名詞,我們用這個來分類 function 或元件:
- Pure function or UI 元件
- 每次送進去固定的輸入,出來就會是固定的結果
- 相同的 props, 產生相同的 component,會放在 components 資料夾
- 不寫商業邏輯
- 不加入有 side effect 的 code
- 有 side effect 的 function or 元件
- 因為與狀態相關所以就會放在 containers 資料夾
- AJAX,相關程式在 react hooks 中就會放在 useEffect,class component 就會放在 componentDidMount
- AJAX 跟 redux,side effect 交給 redux-thunk 或是 redux-saga 去管理
最近開始接觸單元測試後,也深刻感覺到 side effect 越少,測試也越好寫,所以我想如果刻意去寫出好測試的元件,最後也會讓專案的結構變得更好偵錯與維護。
前端專案依功能分類
對新加入專案的工程師來說,最多的時間就是花在找尋相關的程式,其實可以透過小訣竅可以去優化前端開發者體驗,那在資料夾的架構方面,其實很簡單的透過把相近功能的程式碼放在一起 (Co-located) 就可以大量省去尋寶的時間,也能夠更方便的管理。
├── Login/
│ ├── SocialButton/
│ │ ├── LineButton.js # 社群登入的 Line 按鈕
│ │ └── FacebookButton.js # 社群登入的 FB 按鈕
│ ├── Modal/
│ │ └── ModalLogin.js # 登入的 Modal
│ └── index.js # 登入邏輯與主要 Layout
比較大的專案,就會把相關功能的元件都放在同個資料夾中降低相依性、增加內聚性,這樣在維護和修改時可以確定只要照顧好這個資料夾中的檔案即可。
使用 ReduxToolKits 後按照功能搭配分類,覺得較適合大型專案,依照功能就會分成
- typeOne
- typeTwo
- typeThree
每個功能所需要的 action、components、containers、reducers 都會放在一起,所以在開發時,每個工程師都可以在獨立的資料夾中完成該次的任務。
src
└── features
├── typeOne
│ ├── TypeOne.js
│ ├── TypeOne.styles.scss
│ └── typeOneSlice.js
├── typeTwo
│ ├── TypeTwo.js
│ ├── TypeTwo.styles.scss
│ └── typeTwoSlice.js
└── typeThree
├── TypeThree.js
├── TypeThree.styles.scss
└── typeThreeSlice.js
元件如果複雜一些也是依照功能區分,覺得較適合大一點的專案。
.
└── admin
└── UserCard
├── layouts
│ ├── UserCard.mobile.tsx
│ └── UserCard.desktop.tsx
└── UserCard.tsx
簡化架構的函式庫與框架
對於專案或是後端收到的資料,若沒有太多需要客製化的部分,可用底下函式庫與框架簡化:
- storybook: 用故事書元件的角度設計,元件通常就能夠獨立且好測試
- 將 Redux 常用的寫法封裝來減少寫太多重複的程式碼,簡化架構
- Redux Toolkit
- RTK Query
- createSlice
- Redux Toolkit
- axios,Promise based HTTP client for the browser and node.js
- 前後端共構
- 使用客製化 instance 的方式可以將收跟送的邏輯統一實作,減少重複的程式碼
- Next.js,是一套以 React.js 生態系打造出來的完整的框架,幫我們配置了
- AMP
- 路由
- CSS-in-JS
- 靜態頁面輸出
- 伺服器渲染
後端專案架構
通常 Mongoose 會搭配一個後端的框架來做使用,像是 Express 或是 Koa 等等,那在網路上有看到常見的兩種架構。
後端專案依屬性分類
依照屬性性,controller、routes、models 集中放置在各自的分類資料夾,覺得較適合小型專案。
├── src/
│ ├── controller/ # 資料庫 CRUD
│ ├── routes/ # API 設定
│ ├── models/ # Schema 定義
│ └── index.js # 程式入口
├── .eslintrc # ESLint 設定檔
├── package-lock.json
├── package.json
└── README.md
後端專案依功能分類
依照資料功能去做區分,把同個資料表的 model、controller、route 集中存放,覺得較適合大型專案。
├── src/
│ ├── entities/ # 按照資料表去區分
│ │ └── user/ # 使用者表
│ │ ├── model.js # Schema 定義
│ │ ├── controller.js # 資料庫 CRUD
│ │ └── route.js # API 設定
│ └── index.js # 入口
├── .eslintrc # ESLint 設定檔
├── package-lock.json
├── package.json
└── README.md
喜歡這篇文章,請幫忙拍拍手喔 🤣