剛過完中秋節連假，該準備收心了，看到上圖中勤奮努力的兔兔們，應該要好好效法。畢竟快領到年終了，「加班一整天，幸福一整年」這句話說得真TMD的好，說到這邊，不禁讓我搧躝淚下，平常在開發API的過程中，似乎就像是建立一個產線的過程，而資料就是這個產線的最終完成品
細數自己擔任PG(程式設計師)和SA(系統分析師)生涯中，或許寫的程式沒有資深前輩的多，但也看了不少的API，大致上API長得就像下圖的架構
由上圖可知剛開始都是針對傳入參數做檢核，不符合規格的就把它丟掉（在程式中就是 return 或是 拋 exception ），就像是在一個工廠裡面，我要的產線是橘子，結果傳進來的是蘋果，很明顯結果與預期不符合，這時候程式就會採用return 或是拋exception 的方式來處理，假設過了參數檢核這關後，接著就是一連串的業務邏輯處理，這個過程就像是玩闖關遊戲，最後勝利者就是回傳值。
其實整個API的資料處理流程就像是橘子加工廠，任務目標就是要將這些橘子做成分裝好的橘子汁，過程中會將脫皮的、果肉爛掉的、長蟲的逐層篩選到，最後挑出真正優良的橘子才能做成橘子汁，對照上圖每一個業務邏輯的區塊，就是每道的關卡，在程式邏輯中就大概會是長成下列這個樣子
其實資料篩選具有兩種方式
1. 負向表列(很像排除法) : 就像是圖二的概念，我假設大部分的橘子是好的，但其中有少部分是NG品，為了要確保所有橘子是好的，因此我選擇的策略是把不好的橘子挑出來，當我透過層層的篩選，就能達成我要的目標，以上透過這樣的方式就是所謂的負向表列。
2. 正向表列(很像包括法) : 其實看名詞應該很容易理解，正向就是相對於負向來做，我假設大部分的橘子是壞的，但其中有少部分是優良品，因此我選擇把品項好的橘子給挑出來，最後留下來的當然就會是不良的橘子。
以上兩種方式都可以解決問題，只是思考方式不同而已，但是要用哪一種方法，可以先思考整個資料是正向的比較多還是負向的比較多，不同的方法會影響判斷式的數量，當然我們會希望判斷的次數越少越好，進而增進系統的效率。
