外包編碼項目一瞥——幾種編碼風格的比較

1、  大多數編碼采用了嵌套SQL編寫業務。這樣做的好處主要是性能有一定提高——不論多少數據，只要查詢一次數據庫就可以了。我覺得，這種代碼過于追求性能了，使可讀性遭到很大打擊！幾千行的組合SQL，運行Log顯示出來的sql文是沒有注釋的，而且與式樣書也是幾乎不一致。這樣的代碼閱讀過程難以想象，測試難度較高。

2、  有些編碼是依據式樣書編寫業務。式樣書提到一個SQL就寫一個。但對程序流程有一些改動，主要是為了優化代碼。這種代碼往往需要多次查詢數據庫，雖然降低了一些性能，但并不超越軟件的要求。我覺得，可讀性和前一種相比大有提高。但對個人能力的要求較高。對于代碼優化方面，編程的時候往往是不確定因素，不同的人優化重構出來的代碼往往不一樣，編碼差異有時可能很大，難以制定統一的標準，不太適合成為團體軟件開發模式。

3、  個別人完全按照式樣書的流程編寫代碼。其注釋幾乎就是將式樣書copy一遍。代碼與式樣書有著按順序一一對應的特點。給我印象最深的是劉*的一次review。別人的代碼被Review時往往會抱怨雞蛋里挑骨頭，而劉*的代碼則完全挑不出骨頭。其中，找出過幾個被認為是應該調用共通而不應自己編寫的代碼片斷；但，劉*拿出式樣書，代碼與式樣書完全一致；如果調用共通，雖然編碼易修改性、統一性等指標會提高，但是順序就會被打亂，尤其是入力check，如果check順序與式樣書不符合，未必就不是功能缺陷，反而不可取。

我覺得完全按照式樣書的編碼方法雖然在編碼量和編碼性能等等指標上未必是最好的。但它有一個最大的優勢：易于組織團體實施。編碼標準非常明確——唯一的標準就是是否與式樣書一致。如果一個團隊在編碼項目中明確運用這種過程，不同的人做出來的編碼應該是完全一樣的，十分適合團體軟件開發。而后期測試工作，第3類代碼更是體現出其優越性。其它類型的代碼往往需要更多的測試數據代入測試數據流的正確性。而第3類代碼則可以簡化：運用簡單的數據代入測試其可運行，然后對照式樣書Review代碼就完全可以確定代碼的正確性。但是也有缺點，式樣書的正確性往往容易被忽視。如果式樣書是錯誤的，編碼往往也會出錯。

文章來源于領測軟件測試網 http://www.kjueaiud.com/