代碼編寫和測試的總結
一、 代碼編寫
代碼編寫是每一個程序員都關心的問題。但是每個人的編碼能力隨着時間的推移會存在很大的差距。這個在很大的程度上是因爲個人的編程習慣問題導致的。在這次ECAP後臺代碼的編寫過程中，我有很深的體會，下面就總結編寫的心得。
1、良好的編程習慣。在編程的初期一定要按照統一的規範要求自己。最理想的情況就是項目組所有的人先寫同樣一段代碼看起來像是一個人寫的。但這個需要不斷的積累過程。因此平時就要嚴格的要求自己。
2、代碼實現後應該自己走讀一遍。自己走讀代碼的好處是讓自己在編譯之前發現一些明顯的語法錯誤。如語句中缺少括號、分號等等錯誤。
3、編寫成功後進行單元測試。單元測試的目的是讓自己的代碼實現需求的功能。分別對不同的條件進行測試。測試通過後再提交給業務人員進行集成測試。
4、測試時儘量多寫日誌。測試的時候常常會出現很多自己想不到的問題。多寫日誌會讓自己很快的定位到錯誤的位置。寫日誌的原則是：在每一個分支和條件處必須寫日誌；在關鍵變量的取值和複製處必須打印變量值。
5、集成測試後清理大部分調試使用日誌。集成測試完成後，程序功能沒有問題的情況下。那些用於調試的日誌就沒必要打印出來，以免增加生產磁盤空間的負荷。而一些關鍵的分支的日誌最好保留，用於維護時處理生產問題。
6、代碼編寫的時候注意SQL效率問題。編寫高效的SQL語句應該遵從以下規則:
1)在連接查詢的時候記錄最小的表應該放在最右邊，因爲oracle的解析器從右到左處理FROM中的表。
2）在WHERE子句中的的條件的順序應該讓能過濾掉最多記錄的條件放在最下面，因爲oracle的解析器從下到上解析WHERE子句。
3）儘量一次性的取出所有的記錄，不要反覆的去訪問數據庫。多次訪問數據庫會增加大量的I/O操作，影響效率。
4）連接的時候儘量減少表關聯的數量。沒用的表不要關聯。
5）在複雜的SQL語句中有許多UNION的情況下，儘量把條件過濾放到UNION中的每個字查詢中過濾掉儘量多的記錄，得到一個最小的記錄集。
6）在索引上面不要使用計算。如果在索引上面使用計算，那麼索引就不會用到。
7）使用>=代替>;如num>3,改寫爲num>=4；
8)如果是索引列上面多個值爲條件的時候應該使用UNION代替OR。
二、 測試
測試分爲單元測試和集成測試。單元測試的時候是開發人員自己測試自己編寫的代碼有沒有邏輯錯誤。一旦單元測試完成後，下一步進行集成測試。集成測試需要業務人員配合，必須檢查數據的正確性。
1、單元測試
在進行單元測試之前最好和用戶進行交流和討論。討論自己的程序邏輯是否正確，這樣就可以減小集成測試的工作量。在單元測試的過程中應該注意測試反案例，一般開發人員只測試正案例，所以經常會出現反案例就處理不正確的情況。
2、集成測試
集成測試的核心是業務人員。程序開發人員要配合業務測試人員。聽取他們的意見，和他們進行討論。只有這樣自己的程序就會越來越健壯和完善。