基本目標

因應開發時程、成本，以做出

最小可提供服務之系統，以確認商業價值
高彈性，可因應需求快速變更之系統
高開發速度，可儘快滿足開發規格之系統

通盤來說，系統開發的完成度，跟系統的賺錢程度並不是那麼呈正比的，甚至可以說是無關，一切還是要看市場的狀況。因此，在確認營運狀況前，高效能的系統可能不是最重要的。

達成手段

而要做到這般"漸進式開發"，在程式開發時，可以多留意

程式擴充性
- 以快速擴充功能，如果能做到像是插件那樣，引入即可用就更好了
程式可讀性
- 以避免快速變更時，難以找到切入點進行更改，或不小心改到變更範疇外的功能
程式模組性
- 將功能模組化起來，甚至是變成黑盒子般的物件，以便於做到擴充性、可讀性
技術債
- 債是要還的，累積了過多之後，很容易導致系統難以變更
未來優化空間
- 系統的用途是會逐漸收斂定型的，因此也要考慮好哪些功能是重要的，將程式的耦合處理好，降低未來優化難度

舉例來說

Timer

以一個前後端連動的timer功能來說，當系統開發還在很初期的階段時

最快的開發方式，是不管時區，然後前端也直接TimeOut做倒數計時去開發，以體驗功能的效果

而當認定功能是需要的以後，就可以再補上後端驗證，避免業務邏輯出錯

如果一開始的客戶很少，又都是本地，那這樣的開發方式是比較符合效益的

畢竟在開發的工很多的情況下，火力只能集中在最重要的功能上

而當業務成長，或是時間允許後，可以再考慮的周全一點去開發，像是用Timer前後端同步這篇的方法

把時區，手機等等的狀況也考慮進去開發

RWD

RWD 必須考量許多裝置狀況進行開發，不同的裝置，css實作，js運行邏輯都可能有些微差異

這些差異累積起來，將可能使開發時間成指數倍成長

在系統開發初期，其實並不適合一開始就開發的太完整，這樣花的時間太長

當 User 有想法、有靈感，急於驗證時，設置好開發的防火牆，埋下技術債

這樣風險比較可控，同時又比較能滿足 User 的需求

因此若 User 想看手機的顯示，那就可以在開發時切好顯示的組件(將元素模組化、元件化)

這樣若 User 很滿意，並希望能有電腦版的顯示時，就只需要把原來的組件加上裝置的判斷

若判斷為電腦版，切換為電腦版元件，這樣就可以做到不影響既有功能、架構的情況下，漸進式開發