3開發(fā)原則與約束

1、開發(fā)原則與約束開發(fā)命名規(guī)范開發(fā)原則與約束版本信息* a代農(nóng)新增，m代衣修改，d代表刪除;版本號發(fā)布日期提交人審閱人a.m.d更新位置更新摘要v1.02014-07-26李健進a擬初稿vi.12014-08-22李健進a2.8增加系統(tǒng)安全性內(nèi)容v1.22014-08-28李健進m精簡部分重復無意義描述v1.32014-09-03李健進a2.6增加異常捕捉內(nèi)容v1.42014-09-15李健進a3増加數(shù)據(jù)庫規(guī)范中部分內(nèi)容v1.52014-10-27李健進a2.1.2 3.1.2增加對mvc各層作用的描述與主鍵生成策略約束開發(fā)原則與約束目錄1. 前言61.1. 目的范圍61.1.1. 目的作用61.

2、1.2. 應用范圍61.2. 閱讀說明62. java編碼原則72.1. 類、接口72.1.1. 設計原則72.1.2. 設計約束72.2. 方法92.2.1. 設計原則92.3. 變量92.3.1. 設計約束92.4. 表達式與語句102.4.1. 設計約束102.5. 序列化102.5.1. 設計約束102.6. 異常捕捉112.6.1. 設計原則112.6.2. 設計約束11 開發(fā)原則與約束2.7日志12設計原則12線程安全性122.1. 設計約束12系統(tǒng)與資源安全性132.4.1. 設計原則132.4.2. 設計約束142.2. 性能14設計原則14設計約束152.2. 單元測試15設

3、計原則15設計約束163. 數(shù)據(jù)庫設計原則163.1. 數(shù)據(jù)庫設計規(guī)范163.1.1. 設計原則163.1.2. 設計約束173.2. 數(shù)據(jù)庫開發(fā)規(guī)范183.2.1. 設計原則183.2.2. 設計約束194. exoa二次開發(fā)原則20 開發(fā)原則與約束4.1. 二次開發(fā)方法204.1.1. 二次開發(fā)規(guī)模評估204.1.2. 修改原有模塊204.1.3. 新增模塊214.1.4. 新增應用系統(tǒng)214.2. 二次開發(fā)規(guī)約細則225. 代碼管理原則235.1. 代碼管理235.1.1. 設計約束235.2. 版本控制管理255.2.1. 設計約束25開發(fā)原則與約束1.1. i的范圍l.l.l目的作用

4、本規(guī)范的主要口的為指導、規(guī)范軟件編程人員進行軟件代碼編寫工作，提高 軟件開發(fā)工程師的軟件編寫能力。代碼規(guī)范相當重要，代碼規(guī)范提高軟件代碼的 可讀性，使得開發(fā)人員快速和徹底的理解新代碼。好的代碼風格不僅會提高可讀 性，而且會使代碼更健壯，更為重要的是在修改時不容易出錯。1.1.2.應用范圍公司所冇涉及程序編寫的人員和部門。本約定適用于可執(zhí)行系統(tǒng)的源代碼文 件。為了執(zhí)行規(guī)范，每個軟件開發(fā)人員必須一致遵守編程規(guī)范。12閱讀說明本規(guī)范主要分為設計原則與設計約束兩大類。設計原則。主要為設計建議，根據(jù)建議可以寫出更優(yōu)質(zhì)的代碼。本文中為【非加粗字體】開發(fā)原則與約束設計約束。指的是所有開發(fā)人員必須要嚴格遵守的

5、規(guī)約，不允許有違規(guī)行為。 本文中規(guī)約以【加粗字體】標識。其中【灰色的加粗？】表示產(chǎn)品組內(nèi)部強 制執(zhí)行，各項目建議執(zhí)行。2. java編碼原則類、接口1.1.1. 設計原則類的劃分粒度要適當，不宜繼承太深；建議一個類只做一件事，根據(jù)每個類的職責進行劃分；多使用設計模式，盡量捉高代碼重用度；若多個類中使用相同方法時，請將其方法提到一個接口中或使用抽象類；在抽象類和接口都可實現(xiàn)的情況下建議選擇使用接口，以更易于擴展及實現(xiàn) 多重繼承。2.2.2. 設計約束 程序結(jié)構(gòu)遵守 mvc 規(guī)則：jsptactiontservicetdaotdb,即:開發(fā)原則與約束 service：放置主要的業(yè)務邏輯代碼，此類型

6、代碼一般為調(diào)用da0提供的方法進行組合與包裝。為action層提供服務。若業(yè)務邏輯非常簡單的情況下,service層可以省略不寫，同時業(yè)務邏輯代碼寫在action層; action：主要放置數(shù)據(jù)轉(zhuǎn)換、校驗、轉(zhuǎn)發(fā)與業(yè)務邏輯調(diào)用的代碼，若對應存在service層，則action層不應包含具體的業(yè)務邏輯代碼; jsp：分為前端代碼與java代碼。其中java代碼應僅負責數(shù)據(jù)的獲取與解 析，不應包含具體的業(yè)務處理邏輯代碼，更不應該存在jsp直接寫sql語句 進行操作的行為。開發(fā)原則與約束2.2方法2.2.1.設計原則 一個方法只完成一項職責，在定義系統(tǒng)的公共接口方法外的方法應盡可能的 縮小其叮見性；

7、避免在一個較長的方法里提供多個岀m；當多個方法中同時使用一套邏輯和近的代碼時，請將此類型的邏輯代碼抽象 成一個獨立的方法； 一個方法代碼行數(shù)建議不超過200行。若超過，請將方法進行拆分。2.3變量2.3.1.設計約束禁止在代碼中出現(xiàn)無意義的數(shù)字（magic numbec ,應該為此類型的數(shù)字定義一個變量名，提高代碼可讀性;禁止將一個非final實例變量聲明為public,實例變量的傳遞與修改應在方法中實現(xiàn)（構(gòu)造函數(shù)、getter、setter）。開發(fā)原則與約束2.4表達式與語句設計約束所有辻、for、where等語句的執(zhí)行代碼段必須使用包括起來，即便是只 有一個語句； 禁止在一行代碼中進行多個

8、變量的賦值，如a二（b二c+1）； 超過3個else分句請轉(zhuǎn)成switch語句或創(chuàng)建子函數(shù)； switch語句的每個case中必須帶有break；循環(huán)語句中必須有終止循環(huán)的條件或語句，否則容易導致死循環(huán)的情況。2.5.序列化2.7.1. 設計約束 創(chuàng)建序列化類時，serialversionuid必須設置一個隨機的哈希字段，不應 籠統(tǒng)設置為-1l；若復制一個serializable的類進行修改時，必須重新設置新類的 serialversionuid； 針對瞬態(tài)的對象（如10流對象thread對象等）與不希望被序列化的對象，必須在對象聲明前加上transient關鍵字。開發(fā)原則與約束26異常捕捉3

9、.1. 設計原則必須盡可能的精確捕捉異常，而不能籠統(tǒng)使用exccptiono3.2. 設計約束當捕捉到異常時，必須在catch代碼區(qū)進行處理，并且在日志中記錄錯誤信 息(system, out、log4j> oa h志等)；異常日志不應籠統(tǒng)提及拋出這個異常的方法的名字，應有使用說明性的文字描述與完整的異常棧輸出(printstacktrace)； 禁止捕捉異常后不進行任何處理的寫法。開發(fā)原則與約束2.7日志2.7.1.設計原則 debug日志記錄盡量通用而全而，且與oa的debug開關配合使用，例子如下: boolean isdebug = "truen.equals(syst

10、em.getproperty(oaconstant.debug) ? true : false;if (debug) system.out.println(hdebug 日志：n);28 線程安全性2.8.1.設計約束在 jsp、servlet 及 struts 的 action 編程中,非final變量應盡量采用局部變量，減少使用實例變量。由于這些情況都是多線程情況，容易產(chǎn)生線性 不安全問題； 使用synchronized關鍵字的代碼段或函數(shù)之間禁止相互引用，以免引起死鎖;開發(fā)原則與約束應限制自定義線程個數(shù)上限，不設線程限制且并發(fā)的情況下（如在action 中start個新線程），可能會由于

11、線程量暴漲，從而導致native內(nèi)存耗 盡，服務器癱瘓崩潰； 對于static關鍵字修飾的變量>synchronized關鍵字修飾的代碼段或函數(shù),必須考慮這部分代碼能否在集群環(huán)境下正常運行。因為static的變量變化時無法在集群中簡單共享，synchronized的代碼段不能阻塞并發(fā)在集群里其他節(jié)點的代碼。29系統(tǒng)與資源安全性2.9.1.設計原則與上傳文件相關的功能（如上傳附件等），必須針對后綴名進行判斷與過濾： js、jsp、*htm* （女ii html> shtmk htm 等）、css； sql語句捉交時，由客戶端傳遞的變量值必須使用傳參形式傳入，不允許使 用字符吊拼接方式

12、實現(xiàn)，此舉動容易產(chǎn)生sql注入，造成安全隱患；針對插入與修改的功能，應校驗由客戶端提交的數(shù)據(jù)是否存在敏感的字符串style、<script> <!-、<%,防止產(chǎn)生 js 注入。 開發(fā)原則與約束2.9.2.設計約束 涉及到流（10流、ni0流等）、連接（connection連接、httpclient連接 等）的函數(shù)，必須要在f inally塊中進行資源關閉，防止代碼段異常時該執(zhí) 行的釋放的資源代碼沒被執(zhí)行到； 禁止獲取流后不在函數(shù)中持有對象的寫法，如：streamut訂s. getbytes （newf訂elnputstream（new file （path）,此種寫法

13、無法對流對象進行資源關閉； 文件路徑分隔符（windows下的與linux下的力必須使用f訂e. separator來獲取，否則會產(chǎn)生操作系統(tǒng)平臺更變時的文件讀寫錯誤。2.10.性能210丄設計原則避免在循環(huán)屮頻繁構(gòu)建和釋放對象；避免一次客戶端操作中多次操作數(shù)據(jù)庫，大多數(shù)情況應盡量使用單次數(shù)據(jù)庫查詢以完成操作；盡可能早釋放資源（10流、占大內(nèi)存的對象等），不要過分依賴jvm進行gc操作。 開發(fā)原則與約束2.10.2.設計約束在不涉及線性不安全問題的情況下請勿使用synchronized關鍵字與同步類（使用stringbuilder代替stringbuffer >arraylist代替ve

14、ctor>hashmap 代替hashtable等）。使用時應盡量控制范圍，最好是塊級控制；不需要重新賦值的變量（含類變量、實例變量、局部變量）聲明成final,可提高程序響應效率；在編輯string的情況下（如多個字符串的累加）必須使用stringbuffer類， 處理完成后將stringbuffer對象再轉(zhuǎn)換為需要的string對象。2.11.單元測試211丄設計原則單元測試前請盡量使用findbugs等代碼檢查工具進行檢查，可在一定程度 降低代碼中的低級錯謀，插件安裝方法請參考findbugs插件操作手冊 （eclipse 版） docx。開發(fā)原則與約束2.11.2.設計約束在代碼

15、提交前必須對更改的功能手工進行單元測試，提交的代碼不能出現(xiàn)明 顯的錯誤（如點擊后直接報500錯等）。若條件允許，建議使用自動化單 元測試。3.數(shù)據(jù)庫設計原則數(shù)據(jù)庫設計規(guī)范2.9.1. 設計原則表設計時請盡量滿足到3nf （即第三范式）；第一范式：1nf是對屬性的原子性約束，要求屬性具冇原子性，不可再分解; 第二范式：2nf是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟 一性；第三范式：3nf是對字段兀余性的約束，即任何字段不能由英他字段派生出 來，它要求字段沒有冗余。 盡量降低表之間的低級冗余，降低操作時產(chǎn)生臟數(shù)據(jù)與不一致性的可能性,但允許出現(xiàn)高級冗余;開發(fā)原則與約束低級冗余，即重復性的

16、冗余。如在a表定義的字段在b表重復出現(xiàn)。主 鍵與外鍵字段不屈于低級冗余范疇；高級冗余，即派生性的冗余。一般這種兀余的fi的是為了提高處理速度。 如“單價、數(shù)量、金額”三個字段，“金額”就是由“單價”乘以“數(shù)量” 派生出來的，這種冗余冇助捉高性能。新建表時，請合理考慮實際運行時可能會出現(xiàn)的情況，根據(jù)可能會頻繁執(zhí)行 的sql語句建立合理的索引。3.1.2.設計約束禁止在create腳本中設置默認獲取當前數(shù)據(jù)庫服務器中的系統(tǒng)時間。當前 時間應該在程序中獲取，否則容易由于中間件服務器與數(shù)據(jù)庫服務器時間不 一致導致問題；所有數(shù)據(jù)庫表必須包含主鍵或復合主纟使用復合主鍵時，字段個數(shù)不能多于3個，否則可能會導

17、致主鍵索引失效; 主鍵生成策略只允許使用以keygenerator （common包中）生成的int類型主鍵或guid主鍵，禁止使用數(shù)據(jù)庫自增的int主鍵;所有建庫腳本必須按模塊分開，且所有的表結(jié)構(gòu)發(fā)生更改時，建庫腳本必須要有alter語句。 開發(fā)原則與約束3.2.數(shù)據(jù)庫開發(fā)規(guī)范3.2.1.設計原則盡量減少使用數(shù)據(jù)庫的特性，如oracle的深度遞歸、分頁函數(shù)等；若必須要使用這種特性，請獲取exoa-config中的數(shù)據(jù)庫類型，添加針對不同數(shù)據(jù) 庫的特化處理代碼。數(shù)據(jù)庫類型的獲取方法如下(默認為0racle):string databasetype 二confighelper.fastgetco

18、nfig(ncommonn/,databasetypelnoracleh)-tolowercase();使用where時必須考慮語句順序，應該根據(jù)索引順序、范圍大小來確定條件子句的前后順序，盡可能的讓字段順序與索引順序相一致，范圍從大到?。蝗粜枰褂糜|發(fā)器時，必須耍考慮觸發(fā)器的寫法是否會帶來較大的性能損耗；經(jīng)常岀現(xiàn)在where條件中的字段應建立索引，如外鍵字段。having后的條件索引是無效的；查詢時應盡量減少多余數(shù)據(jù)的讀取，通過使用where 了句來減少返冋的記錄數(shù)；對索引列的比較，應盡量避免使用not或!二，可拆分為幾個條件。因為“not”和“！二”不會使用索引； 在where子句中，如果

19、有多個過濾條件，應將索引列或過濾記錄數(shù)最多的條件放在前面;開發(fā)原則與約束 盡量使用exists代替select count (1)來判斷是否存在記錄，count函數(shù)只 有在統(tǒng)計表中所有行數(shù)時使用。3.2.2.設計約束禁止在where子句中的“二”左邊進行函數(shù)、算術運算或其他表達式運算， 此舉動會導致系統(tǒng)將可能無法正確使用索引，如price*10=sum；做關聯(lián)查詢時，若兩個表關聯(lián)的字段為重復性極低的字段(如id),則兩 個表關聯(lián)的字段必須加上索引；禁止可以枚舉出來的數(shù)據(jù)的列建立索引。如布爾型只有t和f,由于這種索 引的區(qū)分度太低，數(shù)據(jù)庫選擇索引時幾乎不會選用這類型索引執(zhí)行，同時也 存在索引維護

20、成本，因此不宜建此類型的索引；當復合索引為多列時應將變化顯著的列放到復合索引的首位，且復合索引不 宜超過16列； 禁止使用insert into table_name values (?, ?,)語法，必須使用insert into table_name (coll, col2,) values (?,?,)】, 一旦數(shù)據(jù)列發(fā)生順序變動(如人為變動、數(shù)據(jù)庫遷移)時，此語句無法使用;如無必要情況，禁止使用數(shù)據(jù)庫特性化語句(如oracle的深度遞歸等)，可降低數(shù)據(jù)庫遷移時的成本。 開發(fā)原則與約束4. exoa二次開發(fā)原則4.1.z1次開發(fā)方法4.l1.二次開發(fā)規(guī)模評估修改原有模塊：原有模塊功能不滿

21、足需求的情況。新増模塊：需求與系統(tǒng)現(xiàn)有模塊差異較大，口新増功能要依賴0a壞境運行的情況。新增應用系統(tǒng)：需求規(guī)模較大，與0a系統(tǒng)現(xiàn)有功能基木無交集，且新增功 能可不依賴0a環(huán)境運行的情況。4丄2修改原有模塊評佔原模塊功能與需求的差異，差異過大要比較擴展與做新模塊之間的長短。理解原模塊的工作機制和設計原意，檢查原模塊是否己提供配置手段實現(xiàn)需 求，是否提供了擴展方法，若以上皆無，或仍不滿足需求，才對原模塊代碼 進行修改。分析修改內(nèi)容是否通用，是否會引入新的依賴，是否對數(shù)據(jù)庫結(jié)構(gòu)作變更， 后續(xù)能否進行產(chǎn)品升級。分析修改對實施的影響。開發(fā)原則與約束4.1.3.新增模塊反復確認系統(tǒng)中無相近功能的模塊。分析

22、新模塊與系統(tǒng)其它模塊的關系，明確交互的場景和接口，注意模塊間的 依賴不要出現(xiàn)循環(huán)。新模塊采用的技術方案不能與0a發(fā)生沖突。原則上不允許引入新的第三方 軟件依賴。通過對業(yè)務的分析，預先考慮擴展方案。明確模塊的實施方法，盡量做到配置可自維護，簡化實施過程。4.1.4.新增應用系統(tǒng)反復確認系統(tǒng)屮無相近功能的模塊。分析新系統(tǒng)與其它系統(tǒng)（包描0a）間的關系，與其它系統(tǒng)的交互盡量采用代 理模式進行隔離，代理通過調(diào)用其它系統(tǒng)的分布式接口完成交互。新系統(tǒng)盡量采用與0a相同的技術方案，以方便功能遷移。通過對業(yè)務的分析，預先考慮擴展方案。明確系統(tǒng)的實施方法，盡量做到配置可自維護，簡化實施過程。開發(fā)原則與約束4.2

23、二次開發(fā)規(guī)約細則數(shù)據(jù)庫編碼、頁面編碼統(tǒng)一使用gbk,禁止使用gb2312o由于gb2312字符集不全，會導致部分生僻字變成問號;原則上不允許引入第三方包。若必須要引入，在不造成與現(xiàn)有第三方包版本 沖突的情況下，通過項目組討論通過后方可引入；相同工作區(qū)下，各個核心包的版本號必須一致；禁止直接使用jdbc訪問數(shù)據(jù)庫。在不使用第三方orm框架的情況下，必須使用sqlutil進行數(shù)據(jù)庫交互；除使用事務，其余的所有sql操作禁止獲取sqlutil的connection方法進行操作；項目若需要有使用saas模式，整個工作區(qū)代碼必須遵守saas規(guī)范，具體規(guī) 范詳見于4saas模式編碼規(guī)范與約束docx；禁止直接對核心表（mv_開頭、uni_開頭的表）進行增刪改操作，這種操作必 須要調(diào)用核心包的對外公布接口，否則會導致核心公文緩存（如公文表單模 板緩存等）中產(chǎn)生臟數(shù)據(jù)。開發(fā)原則與約束5代碼管理原則51代碼管理5.1.1.設計約束 所有的代碼提交必須寫readme,且提交時寫上commit的注釋(comments)； readme文件需放置在ear工程的根目錄下,一個的產(chǎn)品只允許有一個readme； readme撰寫方式如下:開發(fā)原則與約