這個月來很感謝我的主管鼓勵我參加這個有意義的活動，末學所知甚微，承蒙追文的IT邦友不嫌棄，讓我有持續PO文的動力。

由於今天是最後一天，我們不講程式碼，分享購物網站設計時所學習到的經驗

[優惠活動]
完善的購物網站的背後存在不少設計理念，例如網站的優惠本身就是一個模組，當有促銷活動時，該如何設計才能保持彈性．這裡指的彈性有很多種層面，例如新增活動的彈性，活動模組計算折價的彈性等。

以下為幾個優惠活動常遇到的類型：

• A商品折價 (單一商品折價)
• 買A送B
• AB配 (紅綠配)
• 優惠券折抵
• 紅利折抵
• 滿千送百
• ...

以上有些可能在系統設計之初就已經預想到並且預留下程式的接口，也有可能是系統開始營運後才加入的功能(苦笑~ ╮(╯◇╰)╭ )，其實要各自完成這些功能並不難，但是判斷以及計價是不容易的，所以一定要能使用可插拔的設計方式來動態加入目前網站的活動模組，即使初期插拔這個動作是hard code也沒關係，當然最後的目標一定是要能使用設定的方式來決定目前活動模組有哪些( 可以使用config檔案 或是 DB內部來紀錄與設定 )
結論 ： 活動模組最好使用插拔(Plug-in)的方式設計

[上線前測試]
測試本身不難，但是有些測試的次數是有限制的，例如金流，通常想要真正去測試是否有被扣款以及有無收到款項，是必須真實的去扣款的，這種測試次數一定有某種限制，比較合適的做法是將此段邏輯寫成一個獨立的模組，並且有真實扣款與模擬扣款兩種切換的機制．
通常一個系統與錢相關的程式碼都需要非常小心測試與修改，最好每個步驟都寫入Log，系統上線後也一樣．
結論: 與錢相關的邏輯要非常小心，log是必要的。

[功能除錯]
有時功能在測試時沒問題，但使用者一多可能會出現無法預期的錯誤。例如訂單狀態，有可能出現幽靈訂單、重複下定，也有可能有所謂訂單狀態異常(會員已付款訂單卻顯示未付款，或未付款結果顯示已付款)，這些通常都是在上線前無法測試出的。這類無法預防的狀況我們需要著重在治療時期有越多資訊越好，最好使用者的每個步驟都有紀錄(Log)來幫助我們排除錯誤。
結論: log很重要，上線初期Log最好還是保留Debug Mode模式。

[網站外觀]
網站的外觀設計不是問題，問題是特殊節日活動時可能需要改變外觀 ，這部分可以用hardcode去改，等節日過了後再改回去．較好的做法是CSS可使用Sass方式來設計，在修改外觀時可以節省時間．甚至可以考慮把常見的修改(例如萬聖節)可以在後台使用theme的方式直接設定。
結論: 網站外觀可能需要保留彈性，初期可忽略。

[負載平衡]
通常要考慮這個問題時，網站已經有一定的規模了，也許在同時上線人數超過一定數量就會開始很慢。這也同時意味著網站有一定收入囉，此時除了增加網站頻寬，也可以考慮使用多台Web Server來解決，不過可要考慮使用者的Session問題，看是要集中一台Session Server，還是說使用其他機制來保證每次使用者都可以瀏覽至相同的Web Server，例如Nginx。
結論: 初期不需煩惱人太多這種問題。

這三十天我們所完成的是非常基礎(極致簡陋?)的購物網站，其中還缺乏很多功能的實作(例如實際的金流串接)，或是檢核機制(例如結賬時填入的手機格式)，抑或是最簡單的列表分頁功能(Paging)，就交給有需要的人自己擴充了。

感謝耐心看完文章的各位。m(_ _)m