除錯

轉眼間樹狀結構已經寫完了，現在開始進入單元測試。可是一進入單元測試，馬上就發現作為底層的SQL物件功能上有重大的缺陷。於是開始設法修改SQL物件。

但大幅修改物件，結果是原有的介面可能不敷使用。特別是我原有的SQL物件只支援簡單的"select * from table1 where c=2;"這種簡單的Query，查詢條件連大於小於都弄不出來，突然間要想辦法讓一樣的介面做出"select * from table1 where a>2 and (b=1 or b=2);"這種稍微複雜一點的功能頭就開始痛。有點想乾脆做一個新的function，但這意味著code開始疊床架屋，Select1()，Select2()開始出現，所以目前還是決定利用php對於參數型別檢查的寬鬆之處，來在不破壞相容性的情況下塞入新的使用方式（假如參數不是陣列，則老方法，假如參數是陣列，則......）。不過這也代表同一個模組裡面的code flow變得很複雜，測試和除錯都不容易。（現階段就發現很多沒跑過的code branch有很離譜的錯....）

一邊改SQL物件一邊除錯，自己開始思考：把SQL弄成物件，吃陣列參數是否有所必要？固然把SQL弄成物件有不少優點：比如因為傳入的是陣列而不是字串，所以在操控query的時候可以不必使用骯髒的字串操作，可以用乾淨、好閱讀的關聯陣列。query的過濾可以完全自動化進行，並且用優雅的方式條空。不過底層需要把關聯陣列轉成字串意味著效能的降低，用固定的陣列吃下SQL query，也意味著能夠進行的操作種類減少，日後這種不斷硬塞介面的事情還有可能不斷發生，而且以SQL query來說，其實長期弄熟了以後，「優雅」帶來的可讀性上升以及進而帶來的錯誤發生率下降就沒有那麼顯著。所以有點想是不是把原有的SQL物件整個扔了，改用adodb之類stable的東西順路支援所有的database。不過這牽涉到一大堆苦力，所以還在考慮中，等測試profiling幹完再說盃。

SQL物件除錯完成以後，在上面的樹狀結構則應該沒什麼大礙，基礎的單元測試已經完成，接下來應該可以專心針對樹狀結構除錯。再把權限系統的功能疊上去。 全文連結