雖說是好習慣, 但基本上還是偏執的, 也就是說並無法適用在全面性的地方, 尤其是資料探勘以外的地方, 尤其我本身不是個好的程式設計師, 所以這篇純脆只是給考慮或正在寫 Data Mining 相關程式的人作參考, 且本身就是個程式設計師, 甚至點出來的是寫這種程式須要的不同點是那些, 因此不合適給學寫程式的人看.

在 Data Mining 的程式設計中, 最大的考量有幾點:

1. 效率
2. 自動化

而這邊有關資料庫的部份將留給 給 DBA 建議的那邊, 就不寫在這邊.

1. 不要用 Framework: 效率永遠是 Data Mining 最大的考量, Framework 會讓你更好寫程式, 但相對的會讓你的程式變慢, 當然在很多 UI 中, 人的眼睛是追不過電腦因此用 Framework 是節省你寫程式的時間, 但在大量計算還用 Framework 是增加人在電腦前免等待的時間.

2. 多用記憶體多於硬碟 I/O, 也就是說每次去讀資料一定多少會浪費不少 I/O 的時間, 而最好的話能夠用記憶體作一點 Cache 快取通常能節省比你預期還要多的時間, 畢竟花從 Index 與計算而去從記億體撈資料, 比從硬碟抓資料速度快不只百倍, 尤其是 Array 來放些資訊, 總比每次要甚麼資料都要再抓一次好太多了.

3. 每多一次的 Include 就會多一個 I/O Access 讀取, 若只是這程式偶而執行, 就無所謂, 但若這程式會執行很多次或上千萬次的話, 這個 Include 就會很巨大, 因此通常我會說, 若是在 Batch 背景執行的話就 incude 無所謂, 但若是會讓使用者用到的話, 就盡量避免.

4. 不要用太多的遞迴或物件的程式技巧: 當然我們知道寫成遞迴或用物件導向會讓程式很乾淨很漂亮, 且很好維護, 但每次的呼叫事實上背後系統或程式最後的執行碼或 Runtime 須要做得事是超過你預期的, 由其是一些堆疊的處理, 當然要平衡好維護與效率不是件簡單的事.

5. 適時的加入每一個環節的效率追蹤點, 然後計算每一個環節所須要的時間, 來作效率的調整, 大部份的程式或多或少都有調校的空間, 但可以把精神花在時間真的花很久的地方, 有時會出現你意想不到的進展.

6. 有些 function 或 library 本身的須要較高的執行單位, 因此有時要知道每個 function call 或 object method 的效能, 選出最快的而不是最好用的, 這包含在資料處理的演算法也是包含其中.

當然我把系統設計丟給 SA 與工程式, 有關資料庫的部份算在 DBA 身上.