編碼上的小改進

IF　

最初我的代碼是這樣的if(xxxx){    ...    if(xxxx)    {        ....        if(xxxxxx)        {             //做最后要做的事。        }    }}問題是，最后要做的事，并沒有被執行，而我根本就不知道是哪個if沒進來后來代碼變成if(xxxx){log('xxxx');return ;}...如此n個判斷，這樣以來，看Log基本上可以定位到問題所在了。但僅僅這樣，依舊不夠。接下來的情況是，我知道程序命中該if，那我怎么知道是哪里不對。所以修改后的代碼為if(xxxx){log('xxxx=:'+xxxx);return ;}記錄該if判斷關注或檢查的值，用于進一步分析。

進一步明確職責，避免void類型

方法A內部，需要將某個值交給方法B來執行，邏輯上是毫不關心方法B的返回值。代碼則是這樣void A(string message){    B(message);    ... }方法A的目的，是處理Message，只不過由于某種需求，B也要處理，于是將其掛在A中。此時B方法未完成預期的結果，此時問題不好定位。于是代碼變成void A(string message){    var ret = B(message);    if(ret == 0 )     {        log('方法B的返回值為0 異常');    }    ...}這樣，若B方法除了問題，直接根據Log快速定位到B方法，然后讓寫B方法的人來定位，寫A方法的人，該干嘛干嘛。

其他

　　1.封裝的目的是盡可能隔離變化，如數據庫操作。

　　2.針對接口進行編程。如在數據庫操作上，我們直接使用某個數據庫的訪問類SqlHelper，這樣在切換數據庫時代價太大。若當前僅僅只支持Sql數據庫，也可以使用工廠，返回接口，給應用層使用。

　　3.以做產品為目的，程序員存在目的是奉獻更好的產品，不能疲于趕進度。

　　4.項目盡可能使用增量式發布。需要添加功能時，直接復制某些文件即可，避免重裝站點，或者整體覆蓋，容易引起意想不到的問題，風險過大。

　　5.調試日志使用文件記錄，這樣后期代價小一些，如果有必要清理日志，可單獨做。總比現場出了問題，背個筆記本，單步調試的好。

　　6.使用MVC進行開發時，最好是在分析清楚業務編寫代碼，直接使用測試工具對接口進行測試。后端開發，則是保證后端接口的合理性和穩定性，而前臺頁面假設為變化多端的。