編碼常見問題(PL/SQL和Java)

幫忙的捉刀之筆，有問題請和我聯絡:)

編碼常見問題(PL/SQL和Java)
1.PL/SQL資料類型不正確,比如aac001是varchar2類型，但是編寫時沒有使用''括起來，雖然程式可以查詢出來，但是為日後的效能問題埋下了隱患。
 SELECT AAC002 FROM AC01 WHERE AAC001=123456;
 SELECT AAC002 FROM AC01 WHERE AAC001='123456';
2.代碼超長
  不論是在java中還是在pl/sql中，超長的代碼都不利於理解和維護。java中一般合適的代碼長度在50-100行之間。
  PL/SQL中目前沒有這方面的規範，就個人理解，最好不要超過150-200行。
3.超長的SQL語句
  超長的SQL語句非常不便於理解，大量的商務邏輯包含在SQL的WHERE中，這樣的SQL既不便於Tuning，也不利於維護。FROM中所包含的對象最好不要超過3個。
  能寫超級複雜的SQL並不是一種驕傲。
4.SQL語句的大小寫混亂，關鍵字一會大寫，一會小寫，非常不利於Oracle解析。
  在PL/SQL中，可以藉助PL/SQL Developer工具來格式化。但在Java中只能靠編碼人員注意。
5.使用代碼值而不是代碼名稱。
  SELECT AAC002 FROM AC01 WHERE AAC008 = '1';
  SELECT AAC002 FROM AC01 WHERE AAC008 = PKG_A_MACRO.DEF_AAC008_EMP;
  可以看到，如果AAC008的代碼值變化，
  第一種方法要把所有的SQL都要尋找一遍，很可能出問題；
  第二種方法只需要改PKG_A_MACRO裡面的宏定義，凡是調用的都不需要修改。
6.大量應用全域變數
  全域變數會破壞程式結構，全域變數值的維護會發生在程式碼中的任何一點，很多錯誤都不容易調試，而且程式無法做到組件化，難於替換。
7.PL/SQL中使用遊標未關閉
  Java端的DB訪問一般都使用成熟的ORM工具，這種問題會比較少。PL/SQL中要注意及時關閉cursor，而且要注意異常發生時的cursor的狀態。
8.關於錯誤資訊
  很多人為了圖方便，會將錯誤資訊直接拷貝到各處，這樣雖然編碼省事了，但會為以後的調試帶來隱患。應該對不同的錯誤提示不同的資訊，而且要盡量能夠通過
  錯誤資訊還原當時的環境，這樣會非常方便測試，帶來的直接好處就是工作效率大大提高。
9.異常處理時的資源處理，對於發生異常時，要做到相應資源的釋放，如資料庫連接和檔案讀寫是否已經放開，還有事務。
10.在程式碼中對資料庫的操作不要隨處亂扔，比如對AC01的修改，在很多地方都出現，一個UPDATE語句，在一個業務的A段代碼中出現，在B段代碼中也出現，
  如果某一天AC01的結構發生了變化，比如要寫入一個通用的業務流水號，那很不幸，你只能一個一個的去修改UPDATE語句，而且還要加倍小心。
  正確的做法應該是，盡量封裝DB訪問到一個方法中。這不只是對PL/SQL，即使採用ORM，也要注意，盡量減少對DB的分散訪問。
11.老生長談，甚用GOTO
  在Java中，使用goto的情況現在已經很少了，而PL/SQL中仍然有使用GOTO的地方，這時要考慮重構代碼流程。
12.迴圈變數
  因為編碼人員圖方便，使用拷貝的方式拷貝迴圈代碼，這樣很有可能將迴圈變數重複。
  for(int i=0;i<10;i++){
      for(int i=2;i<10;i++){
     
      }
  }
  雖然懶了一時，有自己吃虧的時候。
13.ROWNUM=1
  ROWNUM=1,是個很微妙的東西，他能把你的錯誤化為無型。往往代碼中增加了這句話就不報錯了，^_^好高興哦，不報錯了。等等別著急，先看看算的對不對。
  隱藏錯誤不如儘早暴漏錯誤，尤其是在關鍵業務中，比如劃賬戶，如果錯誤已經產生，那就沖好咖啡好好加班吧。
14.對每一個SQL語句要增加執行判斷。
  當在一個過程中執行大量的SQL語句時，而最後只有在一個地方捕捉，出錯的時候就慢慢調吧。
15.你的注釋夠不夠？
  沒有足夠好的注釋，你就等著以後維護你程式的人罵你吧。不寫注釋的人是可恥的...
16.盡量避免在Java代碼中寫SQL語句
  有ORM為什麼不用呢？而且還可以避免欄位的變化。
17.留意那些沒有被初始化的java對象
  看他們是否會報null 指標錯誤。
18.java中應該實現介面的必須要實現介面
  比如applogic
19.拷貝，還是拷貝
  愚蠢的錯誤往往隱藏在不斷的拷貝中，既然有重構，還要那麼多拷貝幹嗎呢？
 
 
先寫這麼多吧，總之要牢記一點，你怎樣對待程式，程式就會怎樣對待你！