在前兩篇文章簡單的談過物品的分類和管理,這篇文章想往更源頭的慾望討論。
大家都說需要就真的需要嗎?
需求管理
有天,小編突然就驚覺自己是不是太老了,在整理房間時發現畢業紀念冊真的有夠占空間,然後驚覺畢業後這 10-20 年一次都沒打開翻過,而且如果把名字遮起來,現在完全無法只看照片叫出名字,而且整本裡面大部分版面充滿著其他班級不認識的同學,這到底什麼爛設計,那到底當初又為什麼要跟著大家一起買?
在系統架構中,有時候可能會因為技術的新潮和複雜性而熱衷於採用最新的技術或添加多餘的功能,但這並不一定是必需的,是否有更簡單的方法達到目標?
小編年輕的時候也常常看大家說需要或覺得不錯就照著網路上的教學做下去,但沒考慮到應該要有自己思考和判斷的過程,當學習 React 的時候最常聽到的就是 Redux 架構,那我們就從這個角度切入來好好談一談。
首先,我們需要思考的是專案需要多複雜的狀態管理?
Redux 是用來管理全域的的狀態,統一定義了單向資料流的操作流程,還提供 time-travel debugging 這種走在潮流尖端的功能,好物推推,不用嗎?
但是,就是那個但是,這個好物在學習時會需要不只一些時間理解核心概念,例如 actions、reducers、store 等等,這會是開發上的基本消費,在一個小專案中,這個低消是否有點太高?
為了狀態管理定義了 actions、reducers、store 新觀念,導致專案中會重複的長出幾乎一模一樣的樣版程式,在還沒有套用工具以前我們每一次需要增加一個狀態時,能做的只有不斷的複製貼上跟前一筆幾乎一樣的 actions、reducers、store,這也是隨著時間而出現 redux-api-middleware、Redux Toolkit 等等工具的原因,透過這些工具來減少並不需要的 SOP 和 boilerplate code。
1 | // Import functions |
1 | import { createSlice } from "@reduxjs/toolkit"; |
所以大家都說需要就真的需要嗎? 人生可以簡單就不要複雜,狀態管理也是,小專案如果狀態簡單也沒有什麼 Debug 的困難用 useState、useReducer 就可以管理,殺雞焉用牛刀?! 但有一天狀態的量多到有點難以管理且需要追蹤時,Redux 這個強大工具的價值就會浮現,但不應該被視為所有專案的必要組成。
適度地採納新技術,不要過度依賴單一技術或過度擴展系統
喜歡這篇文章,請幫忙拍拍手喔 🤣