軟體設計方案

軟體設計方案

使用者界面設計規範

使用者界面：又稱人機界面，實作使用者與計算機之間的通信，以控制計算機或進行使用者與計算機之間的資料傳送的系統部件。

GUI：即圖形使用者界面，一種可視化的使用者界面，它使用圖形界面代替正文界面。

本系統堅持圖形使用者界面（GUI）設計原則，界面直覺、對使用者透明。使用者接觸軟體後對界面上對應的功能一目了然、不需要多少教育訓練就可以友善地使用本應用系統。

1、界面設計介紹

界面設計是為了滿足軟體專業化标準化的需求而産生的對軟體的使用界面進行美化優化規範化的設計分支。

1）軟體啟動封面設計

應使軟體啟動封面最終為高清晰度的圖像，選用的色彩不宜超過256色，大小多為主流顯示器分辨率的1/6大。啟動封面上應該醒目地标注制作或支援的公司标志、産品商标、軟體名稱、版本号、網址、版權聲明、序列号等資訊，以樹立軟體形象，友善使用者或購買者在軟體啟動的時候得到提示。插圖宜使用具有獨立版權的、象征性強的、識别性高的、視覺傳達效果好的圖形，若使用攝影也應該進行數位處理，以形成該軟體的個性化特征。如果是系列軟體還将考慮整體設計的統一和延續性。

2）軟體架構設計

軟體的架構設計要複雜得多。軟體架構設計應該簡潔明快，盡量少用無謂的裝飾，應該考慮節省螢幕空間，各種分辨率的大小，縮放時的狀态和原則，并且為将來設計的按鈕、菜單、标簽、滾動條及狀态欄預留位置。設計中将整體色彩組合進行合理搭配，将軟體商标放在顯著位置，主菜單應放在左邊或上邊，滾動條放在右邊，狀态欄放在下邊，以符合視覺流程和使用者使用心理。

3）軟體按鈕設計

軟體按鈕設計應該具有互動性，即應該有3到6種狀态效果：點選前滑鼠未放在上面時的狀态；滑鼠放在上面但未點選的狀态；點選時狀态；點選後滑鼠未放在上面時的狀态；不能點選時狀态；獨立自動變化的狀态。按鈕應具備簡潔的圖示效果，名稱易懂，用詞準确，能望文知意最好，讓使用者産生功能關聯反應，群組内按鈕應該風格統一，功能差異大的按鈕應該有所差別。

4）軟體面闆設計

軟體面闆設計應該具有縮放功能，面闆應該對功能區間劃厘清晰，應該和對話框、彈出框等風格比對，盡量節省空間，切換友善。

5）菜單設計

菜單設計一般有選中狀态和未選中狀态，左邊應為名稱，右邊應為快捷鍵。如果有下級菜單應該有下級箭頭符号，不同功能區間應該用線條分割。 對與進行的操作無關的菜單要用屏蔽的方式加以處理，如果采用動态加載方式，即隻有需要的菜單才顯示最好。主菜單的寬度要接近，字數不應多于四個，每個菜單的字數能相同最好。 主菜單數目不應太多，最好為單排布置。

6）标簽設計

标簽設計應該注意轉角部分的變化，狀态可參考按鈕。

7）圖示設計

圖示設計色彩不宜超過64色，大小為16x16、32x32兩種，應該加以着重考慮視覺沖擊力，它需要在很小的範圍表現出軟體的内涵，在設計時使用簡單的顔色，利用眼睛對色彩和網點的空間混合效果，做出精彩圖示。

8）滾動條及狀态欄設計

滾動條主要是為了對區域性空間的固定大小中内容量的變換進行設計，應該有上下箭頭，滾動标等，有些還有翻頁标。狀态欄是為了對軟體目前狀态的顯示和提示。

9）安裝過程設計

安裝過程設計主要是将軟體安裝的過程進行美化，包括對軟體功能進行圖示化。

10）包裝及商品化

最後軟體産品的包裝應該考慮保護好軟體産品，功能的宣傳融合于美觀中，可以印刷部分産品介紹。

2、界面設計原則

1）易用性

（1）完成相同或相近功能的按鈕用Frame框起來，常用按鈕要支援快捷方式；

（2）完成同一功能或任務的元素放在集中位置，減少滑鼠移動的距離；

（3）按功能将界面劃分局域塊，用Frame框括起來，并要有功能說明或标題；

（4）界面要支援鍵盤自動浏覽按鈕功能，即按Tab鍵的自動切換功能；

（5）同一界面上的控件數最好不要超過10個，多于10個時可以考慮使用分頁界面顯示；

（6）分頁界面要支援在頁面間的快捷切換，常用組合快捷鍵Ctrl+Tab；

（7）預設按鈕要支援Enter及選操作，即按Enter後自動執行預設按鈕對應操作；

（8）可寫控件檢測到非法輸入後應給出說明并能自動獲得焦點；

（9）Tab鍵的順序與控件排列順序要一緻，目前流行從上到下、從左到右的方式；

（10）複選框和選項框要有預設選項，按選擇機率的高低而先後排列，并支援Tab選擇；

（11）界面空間較小時使用下拉框而不用選項框；

（12）選項數較少時使用選項框，相反使用下拉清單框；

（13）适當使用相關的專業術語，提倡使用通用性字眼。

2）規範性

通常界面設計都按Windows界面的規範來設計，即包含“菜單條、工具欄、工具廂、狀态欄、滾動條、右鍵快捷菜單”的标準格式。小型軟體一般不提供工具廂。

（1）菜單前的圖示能直覺地代表要完成的操作，常用菜單要有指令快捷方式 ；

（2）完成相同或相近功能的菜單用橫線隔開放在同一位置，菜單深度一般要求最多控制在三層以内；

（3）相同或相近功能的工具欄放在一起，工具欄中的每一個按鈕要有及時提示資訊；

（4）系統常用的工具欄設定預設放置位置，工具欄的圖示能直覺地代表要完成的操作，一條工具欄的長度不能超出螢幕寬度；

（5）工具欄太多時可以考慮使用工具廂； 工具廂要具有可增減性，由使用者自己根據需求定制，預設總寬度不要超過螢幕寬度的1/5；

（6）狀态條要能顯示使用者切實需要的資訊，常用的有：目前的操作、系統狀态、使用者位置、使用者資訊、提示資訊、錯誤資訊等，高度以放置五好字為宜；

（7）滾動條的長度要根據顯示資訊的長度或寬度能及時變換，以利于使用者了解顯示資訊的位置和百分比，并且寬度應比狀态條的略窄；

（8）菜單和工具條要有清楚的界限，菜單要求凸出顯示，這樣在移走工具條時仍有立體感；

（9）菜單和狀态條中通常使用五号字型。工具條一般比菜單要寬，但不要寬得太多，否則看起來很不協調；

（10）右鍵快捷菜單采用與菜單相同的準則。

3）合理性

螢幕對角線相交的位置是使用者直視的地方，正上方四分之一處為易吸引使用者注意力的位置，在放置窗體時要注意利用這兩個位置。

（1）父窗體或主窗體的中心位置應該在對角線焦點附近；

（2）子窗體位置應該在主窗體的左上角或正中，多個子窗體彈出時應該依次向右下方偏移，以顯示出窗體标題為宜；

（3）重要的指令按鈕與使用較頻繁的按鈕要放在界面上注目的位置；

（4）與正在進行的操作無關的按鈕應該加以屏蔽(Windows中用灰色顯示，沒法使用該按鈕) ；

（5）對可能造成資料無法恢複的操作必須提供确認資訊，給使用者放棄選擇的機會。

4）美觀與協調性

（1）按鈕大小基本相近，且與界面的大小、空間要協調，忌用太長的名稱；

（2）避免空曠的界面上放置很大的按鈕，放置完控件後界面不應有很大的空缺位置；

（3）前景與背景色搭配合理協調，反差不宜太大，最好少用深色，常用色考慮使用Windows界面色調；

（4）界面風格要保持一緻，字的大小、顔色、字型要相同，除非是需要藝術處理或有特殊要求的地方；

（5）如果窗體支援最小化、最大化或放大時，窗體上的控件也要随着窗體而縮放；

（6）對于含有按鈕的界面一般不應該支援縮放，即右上角隻有關閉功能；

（7）通常父窗體支援縮放時，子窗體沒有必要縮放。

5）界面一緻性

在界面設計中應該保持界面的一緻性。一緻性既包括使用标準的控件,也指使用相同的資訊表現方法，如在字型、标簽風格、顔色、術語、顯示錯誤資訊等方面確定一緻。

（1）顯示資訊一緻性

①标簽提示：字型為不加粗、宋體、黑色、灰底或透明、無邊框、右對齊、不帶冒号、一般情況為五号；

②日期：正常字型、宋體、白底黑字；

③對齊方法

左對齊：一般文字、單個數字、日期等

右對齊：數字、時間、日期加時間

④分辨率800*600，增強色16色；

⑤字型預設為宋體、五号、黑色；

⑥底色預設為灰色。

這些資訊的排列顯示風格供參考, 在同一軟體中應當注意表現形式的一緻性。

（2）布局合理化

應注意在一個視窗内部所有控件的布局和資訊組織的藝術性，使得使用者界面美觀。布局不宜過于密集，也不能過于空曠，合理的利用空間。

在一個視窗中按tab鍵，移動順序不能雜亂無章，先從上至下，再從左至右。一屏中首先應輸入的和重要資訊的控件在tab順序中應當靠前,并放在視窗上較醒目的位置。布局力求簡潔、有序、易于操作。

（3）滑鼠與鍵盤對應

應用中的功能隻用鍵盤也應當可以完成，即設計的應用中還應加入一些必要的按鈕和菜單項。但是，許多滑鼠的操作，如輕按兩下、拖動對象等，并不能簡單地用鍵盤來模拟即可實作。例如在一個清單框中用滑鼠單擊其中一項表示選中該項内容，為了用鍵盤也能實作這一功能，必須在視窗中定義一個表示選中的按鈕，以作為實作單擊功能的替。又如在一個視窗中有兩個資料視窗，可以用滑鼠從一個資料視窗中将一項拖出然後放到另一個中，如果隻用鍵盤，就應當在菜單中設定拷貝或移動的菜單項。

（4）快捷鍵

在菜單項中使用快捷鍵可以讓使用鍵盤的使用者操作得更快一些，在Windows及其應用軟體中快捷鍵的使用大多是一緻的。本系統中應用的快捷鍵在各個配置項上語義必須保持一緻。

Ctrl-O 打開 Ctrl-Tab 下一視窗

Ctrl-S 儲存 Ctrl-Esc 任務清單

Ctrl-C 拷貝 Ctrl-F4 關閉視窗

Ctrl-V 粘貼 Alt-F4 結束應用

Ctrl-D 删除 Alt-Tab 下一應用

Ctrl-X 剪切 Enter 預設按鈕/确認操作

Ctrl-I 插入 Esc 取消按鈕/取消操作

Ctrl-H 幫助 Shift-F1 上下文相關幫助

Ctrl-P 列印

Ctrl-W 關閉

其它快捷鍵

其它快捷鍵使用漢語拼音的開頭字母，不常用的可以沒有快捷鍵。

6）向導

對于應用中某些部分的處理流程是固定的，使用者必須按照指定的順序輸入操作資訊，為了使使用者操作得到必要的引示應該使用向導，使使用者使用功能時比較輕松明了，但是向導必須用在固定處理流程中，并且處理流程應該不少于3個處理步驟。

7）使用者幫助

系統應該提供詳盡而可靠的幫助文檔，在使用者使用産生迷惑時可以自己尋求解決方法。

常用的幫助設施有兩種：內建的和附加的。內建的幫助設施一開始就是設計在軟體中的，它與語境有關，使用者可以直接選擇與所要執行操作相關的主題。通過內建幫助設施可以縮短使用者獲得幫助的時間，增加界面的友好性，附加的幫助設施在系統建好以後再加進去，通常是一種查詢能力比較弱的聯機幫助。

（1）幫助文檔中的性能介紹與說明要和系統性能配套一緻；

（2）操作時要提供及時調用系統幫助的功能，常用F1；

（3）最好提供目前流行的聯機幫助格式或HTML幫助格式；

（4）使用者可以用關鍵詞在幫助索引中搜尋所要的幫助，當然也應該提供幫助主題詞；

（5）在幫助中應該提供我們的技術支援方式，一旦使用者難以自己解決可以友善地尋求新的幫助方式。

8）出錯資訊和警告

出錯資訊和警告是指出現問題時系統給出的壞消息，資訊以使用者可以了解的術語描述。

（1）資訊應提供如何從錯誤中恢複的建設性意見；

（2）資訊應指出錯誤可能導緻哪些不良後果，以便使用者檢查是否出現了這些情況并幫助使用者進行改正；

（3）資訊應伴随着視覺上的提示，如特殊的圖像、顔色或者資訊閃爍；

（4）資訊不能帶有判斷色彩，即在任何情況下不能指責使用者。

9）一般互動

（1）一緻性：菜單選擇、資料顯示以及其它功能都應使用一緻的格式；

（2）提供有意義的回報；

（3）在資料錄入上允許取消大多數操作；

（4）減少在動作間必須記憶的資訊數量；

（5）允許使用者非惡意錯誤，系統應保護自己不受緻命錯誤的破壞。

10）資料輸入

（1）盡量減少使用者輸入動作的數量；

（2）維護資訊顯示和資料輸入的一緻性；

（3）互動應該是靈活的，對鍵盤和滑鼠輸入的靈活性提供支援；

（4）在目前動作的語境中使不合适的指令不起作用。

11）獨特性

如果一味地遵循業界的界面标準，則會喪失自己的個性。在架構符合規範的情況下，設計具有自己獨特風格的界面尤為重要，在商業軟體流通中會有很好的潛移默化的廣告效用。安裝界面上應有機關介紹或産品介紹，并有自己的圖示。

程式設計規範總則

1、排版

1）程式塊要采用縮進風格編寫，縮進的空格數為4個，對于由開發工具自動生成的代碼可以不一緻；

2）相對獨立的程式塊之間、變量說明之後必須加空行；

3）較長的語句要分成多行書寫，長表達式要在低優先級操作符處劃分新行，操作符放在新行之首，劃分出的新行要進行适當的縮進，使排版整齊，語句可讀；

4）循環、判斷等語句中若有較長的表達式或語句，則要進行适應的劃分，同3）；

5）若函數或過程中的參數較長，也要進行适當的劃分；

6）不允許把多個短語句寫在一行中，即一行隻寫一條語句；

7）if、for、do、while、case、switch、default等語句自占一行，且if、for、do、while等語句的執行語句部分無論多少都要加括号{}；

8）對齊隻使用空格鍵，不使用TAB鍵；

9）函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要采用縮進風格，case語句下的處理語句也要遵從語句縮進要求；

10）程式塊的分界符（如大括号‘{’和‘}’）應各獨占一行并且位于同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程式都要采用如上的縮進方式；

11）在兩個以上的關鍵字、變量、常量進行對等操作時，它們之間的操作符之前、之後或者前後要加空格，但不要連續留兩個以上空格。進行非對等操作時，如果是關系密切的操作符（如－>）後不應加空格。

采用這種松散方式編寫代碼的目的是使代碼更加清晰，在已經非常清晰的語句中沒有必要再留白格。如果語句已足夠清晰，則括号内側(即左括号後面和右括号前面)不需要加空格，多重括号間也不必加空格。 在長語句中，如果需要加的空格非常多，那麼應該保持整體清晰，而在局部不加空格。

（1）逗号、分号隻在後面加空格。

int a, b, c;

（2）比較操作符、指派操作符、算術操作符、邏輯操作符、位操作符等雙目操作符的前後加空格。

a = b + c;

a *= 2;

a = b ^ 2;

（3）"!"、"~"、"++"、"--"、"&"（位址運算符）等單目操作符前後不加空格。

flag = !isFull;

p = &com;

i++;

（4）"->"、"."前後不加空格。

（5）if、for、while、switch等與後面的括号間應加空格，使if等關鍵字更為突出、明顯。

if (a >= b && c > d)

12）一行程式以小于80字元為宜，不要寫得過長。

2、注釋

注釋應該說明代碼的目的，要講清為什麼要那麼做，而不是怎麼去做。 1）一般情況下，源程式有效注釋量必須在20％以上。注釋的原則是有助于對程式的閱讀了解，在該加的地方都加，注釋不宜太多也不能太少，注釋語言必須準确、易懂、簡潔；

2）注釋格式盡量統一，建議使用“/* …… */”；

3）說明性檔案（如頭檔案.h檔案、.inc檔案等）頭部應進行注釋，注釋必須列出：版權說明、版本号、生成日期、作者、内容、功能、與其它檔案的關系等，頭檔案的注釋中還應有函數功能簡要說明；

4）源檔案頭部應進行注釋，列出：版權說明、版本号、生成日期、作者、子產品功能、主要函數及其功能等；

5）函數頭部應進行注釋，列出：函數功能、輸入參數、輸出參數、傳回值等；

6）邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一緻性；

7）避免在注釋中使用縮寫，特别是非常用的縮寫。如無法避免，應對縮寫進行必要的說明；

8）注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，如放于上方則需與其上面的代碼用空行隔開；

9）變量、常量、宏的注釋有時也是必須的，應放在其上方相鄰位置或右方；

10）資料結構聲明(包括數組、結構、類、枚舉等)，如果其命名不是充分自注釋的，必須加以注釋。對資料結構的注釋應放在其上方相鄰位置，對結構中的每個域的注釋放在此域的右方；

11）全局變量要有較詳細的注釋，包括對其功能、取值範圍、哪些函數或過程存取它以及存取時注意事項等的說明；

12）将注釋與其上面的代碼用空行隔開，注釋與所描述内容進行同樣的縮排；

13）對變量的定義和分支語句（條件分支、循環語句等）必須編寫注釋。這些語句往往是程式實作某一特定功能的關鍵，對于維護人員來說，良好的注釋幫助更好地了解程式，有時甚至優于看設計文檔；

14）通過對函數或過程、變量、結構等正确的命名以及合理地組織代碼的結構，使代碼成為自注釋的，減少不必要的注釋；

15）當代碼段較長，特别是多重嵌套時，在程式塊的結束行右方加注釋标記，以表明某程式塊的結束；

16）建議注釋多使用中文，除非能用非常流利準确的英文表達。

3、辨別符命名

1）辨別符的命名要清晰明了，有明确含義，同時使用完整的單詞或大家基本可以了解的縮寫，避免使人産生誤解。較長的單詞可取單詞的頭幾個字母形成縮寫，一些單詞有大家公認的縮寫；

2）命名中若使用特殊約定或縮寫，應該在源檔案的開始之處，進行必要的注釋說明；

3）命名風格要自始至終保持一緻；

4）對于變量命名，禁止取單個字元（如i、j、k...）。單個字元容易敲錯，且編譯時又不易檢查出來。建議除了要有具體含義外，還能表明其變量類型、資料類型等，但i、j、k作局部循環變量是可以的；

5）命名規範必須與所使用的系統風格保持一緻，并在同一項目中統一。除非必要，不要用數字或較奇怪的字元來定義辨別符；

6）在同一軟體産品内，應規劃好接口部分辨別符（變量、結構、函數及常量）的命名，防止編譯、連結時産生沖突；

7）用正确的反義詞組命名具有互斥意義的變量或相反動作的函數等；

下面是一些在軟體中常用的反義詞組：

add / remove begin / end create / destroy

insert / delete add / delete get / release

increment / decrement put / get

lock / unlock open / close first / last

min / max old / new start / stop

next / previous send / receive show / hide

source / target source / destination

cut / paste up / down

8）除了特殊應用，應避免使用以下劃線開始和結尾的定義。

4、可讀性

1）注意運算符的優先級，并用括号明确表達式的操作順序，避免使用預設優先級；

2）避免使用不易了解的數字，用有意義的辨別來替代；

3）源程式中關系較為緊密的代碼應盡可能相鄰，便于程式閱讀和查找；

4）不要使用難懂的技巧性很高的語句，除非很有必要時。程式的高效率并不等同于語句的高技巧，而在于算法。

5、變量與結構

1）去掉沒必要的公共變量，以降低子產品間的耦合度；

2）仔細定義并明确公共變量的含義、作用、取值範圍及公共變量間的關系；

3）明确公共變量與操作此公共變量的函數或過程的關系，如通路、修改及建立等。這種關系的說明可在注釋或文檔中描述；

4）當向公共變量傳遞資料時，要十分小心，防止賦與不合理的值或越界等現象發生。若有必要應進行合法性檢查，以提高代碼的可靠性、穩定性；

5）構造僅有一個子產品或函數可以修改、建立，而其餘有關子產品或函數隻通路的公共變量，防止多個不同子產品或函數都可以修改、建立同一公共變量的現象；

6）使用嚴格形式定義的、可移植的标準資料類型，盡量不要使用與具體硬體或軟體環境關系密切的變量；

7）結構的功能要單一，是針對一種事務的抽象。結構中的各元素應代表同一事務的不同側面，而不應把描述沒有關系或關系很弱的不同僚務的元素放到同一結構中；

8）不同結構間的關系不要過于複雜，否則應合為一個結構；

9）仔細設計結構中元素的布局與排列順序，使結構容易了解、節省占用空間，并減少引起誤用的現象；

10）結構的設計要盡量考慮向前相容和以後的版本更新，并為某些未來可能的應用保留餘地；

11）留心具體語言及編譯器處理不同資料類型的原則及有關細節；

12）程式設計時，要注意資料類型的強制轉換。對編譯系統預設的資料類型轉換要有充分的認識，盡量減少沒有必要的資料類型預設轉換與強制轉換，合理地設計資料并使用自定義資料類型，避免資料間進行不必要的類型轉換；

13）對自定義資料類型進行恰當命名，使它成為自描述性的，以提高代碼可讀性，但要注意其命名方式在同一産品中的統一。

6、函數與過程

1）設計高扇入、合理扇出（小于7）的函數。較良好的軟體結構通常是頂層函數的扇出較高，中層函數的扇出較少，而底層函數則扇入到公共子產品中；

2）函數的規模盡量限制在200行以内，不包括注釋和空格行；

3）對所調用函數的錯誤傳回碼要仔細、全面地處理；

4）在同一項目組應明确規定對接口函數參數的合法性檢查應由函數的調用者負責還是由接口函數本身負責，預設是由函數調用者負責；

5）防止将函數的參數作為工作變量。對必須改變的參數，最好先用局部變量代之，再将該局部變量的内容賦給該參數；

6）一個函數僅完成一件功能，不要設計多用途的函數。函數名應準确描述函數的功能；

7）函數的功能應該是可以預測的，也就是說隻要輸入資料相同就應産生同樣的輸出；

8）避免設計多參數函數，不使用的參數從接口中去掉，減少函數間接口的複雜度；

9）非排程函數應減少或防止控制參數，盡量隻使用資料參數，防止函數間的控制耦合；

10）檢查函數所有參數輸入與非參數輸入的有效性；

11）在程式設計時，經常遇到在不同函數中使用相同的代碼，許多開發人員都願把這些代碼提出來，并構成一個新函數。若這些代碼關聯較大并且是完成一個功能的，那麼這種構造是合理的，否則這種構造将産生随機内聚的函數；

12）功能不明确且較小的函數，特别是僅有一個上級函數調用它時，應考慮把它合并到上級函數中，而不必單獨存在；

13）減少函數本身或函數間的遞歸調用。除非為某些算法或功能的實作友善，應減少沒必要的遞歸調用；

14）仔細分析子產品的功能及性能需求，并進一步細分，若有必要畫出有關資料流圖，據此來進行子產品的函數劃分與組織；

15）對于提供了傳回值的函數，在引用時最好使用其傳回值；

16）當一個過程（函數）中對較長變量（一般是結構的成員）有較多引用時，可以用一個意義相當的宏代替。

7、可測性

1）在同一項目組或産品組内，要有一套統一的為內建測試與系統聯調準備的調測開關及相應列印函數，并且要有詳細的說明；

2）在同一項目組或産品組内，調測列印出的資訊串的格式要有統一的形式。資訊串中至少要有所在子產品名（或源檔案名）及行号；

3）程式設計的同時要為單元測試選擇恰當的測試點，并仔細構造測試代碼、測試用例，同時給出明确的注釋說明。測試代碼部分應作為（子產品中的）一個子子產品，以友善測試代碼在子產品中的安裝與拆卸（通過調測開關）；

4）使用斷言來發現軟體問題，提高代碼可測性。用斷言來檢查程式正常運作時不應發生但在調測時有可能發生的非法情況，但不能用斷言來檢查最終産品肯定會出現且必須處理的錯誤情況；

5）對較複雜的斷言加上明确的注釋，用斷言确認函數的參數，保證沒有定義的特性或功能不被使用，對程式開發環境的假設進行檢查；

6）正式軟體産品中應把斷言及其它調測代碼去掉（即把有關的調測開關關掉），以加快軟體運作速度；

7）在軟體系統中設定與取消有關測試手段，不能對軟體實作的功能等産生影響；

8）用調測開關來切換軟體的DEBUG版和正式版，而不要同時存在正式版本和DEBUG版本的不同源檔案，以減少維護的難度；

9）軟體的DEBUG版本和發行版本應該統一維護，不允許分家，并且要時刻注意保證兩個版本在實作功能上的一緻性；

10）在編寫代碼之前，應預先設計好程式調試與測試的方法和手段，并設計好各種調測開關及相應測試代碼如列印函數等；

11）調測開關應分為不同級别和類型。針對子產品或系統某部分代碼的調測，針對子產品或系統某功能的調測，對性能、容量等的測試；

12）編寫防錯程式，然後在處理錯誤之後可用斷言宣布發生錯誤。

8、程式效率

1）在保證軟體系統的正确性、穩定性、可讀性及可測性的前提下提高代碼效率，包括全局效率、局部效率、時間效率及空間效率；

2）局部效率應為全局效率服務，不能因為提高局部效率而對全局效率造成影響；

3）通過對系統資料結構的劃分與組織的改進，以及對程式算法的優化來提高空間效率；

4）仔細考慮循環體内的語句是否可以放在循環體之外，使循環體内工作量最小，進而提高程式的時間效率；

5）仔細考查、分析系統及子產品處理輸入（如事務、消息等）的方式，并加以改進；

6）對子產品中函數的劃分及組織方式進行分析、優化，改進子產品中函數的組織結構，提高程式效率；

7）不應花過多的時間拼命地提高調用不很頻繁的函數代碼的效率；

8）仔細地構造或直接用彙編編寫調用頻繁或性能要求極高的函數。嵌入彙編可提高時間及空間效率，但也存在一定風險；

9）在保證程式品質的前提下，通過壓縮代碼量、去掉不必要代碼以及減少不必要的局部和全局變量，來提高空間效率；

10）盡量減少循環嵌套層次。在多重循環中，應将最忙的循環放在最内層，以減少CPU切入循環層的次數；

11）避免循環體内含判斷語句，應将循環語句置于判斷語句的代碼塊之中；

12）盡量用乘法或其它方法代替除法，特别是浮點運算中的除法；

13）不要一味地追求緊湊的代碼，因為緊湊的代碼并不代表高效的機器碼。

9、品質保證

1）在軟體設計過程中構築軟體品質；

2）代碼品質保證優先原則

（1）正确性，指程式要實作設計要求的功能；

（2）穩定性/安全性，指程式穩定、可靠、安全；

（3）可測試性，指程式要具有良好的可測試性；

（4）規範/可讀性，指程式書寫風格、命名規則等要符合規範；

（5）全局效率，指軟體系統的整體效率；

（6）局部效率，指某個子產品、子子產品、函數的本身效率；

（7）個人表達方式，指個人程式設計習慣。

3）隻引用屬于自己的存貯空間；

4）防止引用已經釋放的記憶體空間；

5）過程/函數中配置設定的記憶體，在過程/函數退出之前要釋放；

6）過程/函數中申請的（為打開檔案而使用的）檔案句柄，在過程/函數退出之前要關閉；

7）防止記憶體操作越界；

8）認真處理程式所能遇到的各種出錯情況；

9）系統運作之初，要初始化有關變量及運作環境，防止未經初始化的變量被引用，并對加載到系統中的資料進行一緻性檢查；

10）嚴禁随意更改其它子產品或系統（不屬于自己）的有關設定和配置，不能随意改變與其它子產品的接口；

11）注意易混淆的操作符。當編完程式後，應從頭至尾檢查一遍這些操作符，以防止拼寫錯誤；

12）有可能的話，if語句盡量加上else分支，對沒有else分支的語句要小心對待。switch語句必須有default分支；

13）不使用與硬體或作業系統關系很大的語句，而使用建議的标準語句，以提高軟體的可移植性和可重用性；

14）精心構造算法，并對其性能、效率進行測試，對較關鍵的算法最好使用其它算法來确認；

15）注意表達式是否會上溢、下溢，使用變量時要注意其邊界值；

16）系統應具有一定的容錯能力，對一些錯誤事件（如使用者誤操作等）能進行自動補救；

17）對一些具有危險性的操作代碼要仔細考慮，防止對資料、硬體等的安全構成危害，以提高系統的安全性。

10、代碼編輯、編譯與審查

1）同産品軟體（項目組）内，最好使用相同的編輯器，并使用相同的設定選項；

2）打開編譯器的所有告警開關對程式進行編譯；

3）通過代碼走讀及審查方式對代碼進行檢查；

4）編寫代碼時要注意随時儲存，并定期備份，防止由于斷電、硬碟損壞等原因造成代碼丢失；

5）某些語句經編譯後産生告警，如果你認為它是正确的，那麼應通過某種手段去掉告警資訊；

6）使用代碼檢查工具對源程式檢查，使用軟體工具進行代碼審查。

11、代碼測試與維護

1）單元測試要求至少達到語句覆寫；

2）整理或優化後的代碼要經過審查及測試；

3）代碼版本更新要經過嚴格測試；

4）使用工具軟體對代碼版本進行維護；

5）正式版本上軟體的任何修改都應有詳細的文檔記錄；

6）發現錯誤立即修改，并且要記錄下來；

7）關鍵的代碼在彙編級跟蹤；

8）仔細設計并分析測試用例，使測試用例覆寫盡可能多的情況，以提高測試用例的效率；

9）盡可能模拟出程式的各種出錯情況，對出錯處理代碼進行充分的測試；

10）仔細測試代碼處理資料、變量的邊界情況；

11）保留測試資訊，以便分析、總結經驗及進行更充分的測試；

12）不應通過“試”來解決問題，應尋找問題的根本原因；

13）對自動消失的錯誤進行分析，搞清楚錯誤是如何消失的；

14）測試時應設法使很少發生的事件經常發生；

15）明确子產品或函數處理哪些事件，并使它們經常發生；

16）堅持在編碼階段就對代碼進行徹底的單元測試，不要等以後的測試工作來發現問題；

17）去除代碼運作的随機性，讓函數運作的結果可預測，并使出現的錯誤可再現。

資料庫設計原則

資料庫技術是資訊資源管理最有效的手段。資料庫設計是建立資料庫及其應用系統的核心和基礎，它要求對于指定的應用環境，構造出較優的資料庫模式，建立起資料庫應用系統，并使系統能有效地存儲資料，滿足使用者的各種應用需求。

1、設計資料庫之前

1）了解客戶需求，詢問使用者如何看待未來需求變化。讓客戶解釋其需求，而且随着開發的繼續，還要經常詢問客戶以保證其需求仍然在開發的目的之中；

2）了解企業業務，在以後的開發階段節約大量時間；

3）重視輸入輸出。在定義資料庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出），以決定為了支援這些輸出哪些是必要的表和字段；

4）建立資料字典和E-R 圖，對SQL 表達式的文檔化來說這是完全必要的；

5）定義标準的對象命名規範。

2、表與字段的設計

　　

1）表設計原則

（1）标準化和規範化；

資料的标準化有助于消除資料庫中的資料備援。标準化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴充性和資料完整性方面達到了最好平衡。事實上，為了效率的緣故，對表不進行标準化有時也是必要的。

（2）采用資料驅動，增強系統的靈活性與擴充性；

（3）在設計資料庫的時候考慮到哪些資料字段将來可能會發生變更。

2）字段設計原則

（1）每個表中都應該添加的3 個有用的字段；

①dRecordCreationDate，在SQL Server 下預設為GETDATE()；

②sRecordCreator，在SQL Server 下預設為NOT NULL

DEFAULT USER；

③nRecordVersion，記錄的版本标記，有助于準确說明記錄中出現null 資料或者丢失資料的原因。

（2）對位址和電話采用多個字段，電話号碼和郵件位址最好擁有自己的資料表，其間具有自身的類型和标記類别；

（3）使用角色實體定義屬于某類别的列，建立特定的時間關聯關系，進而可以實作自我文檔化；

（4）選擇數字類型和文本類型要盡量充足，否則無法進行計算操作；

（5）增加删除标記字段。在關系資料庫裡不要單獨删除某一行，而在表中包含一個“删除标記”字段，這樣就可以把行标記為删除。

3、鍵和索引

1）鍵選擇原則

（1）鍵設計4 原則

①所有的鍵都必須唯一；

②為關聯字段建立外鍵；

③避免使用複合鍵；

④外鍵總是關聯唯一的鍵字段。

（2）使用系統生成的主鍵，控制資料庫的索引完整性，并且當擁有一緻的鍵結構時，找到邏輯缺陷很容易；

（3）不要用使用者的鍵，通常情況下不要選擇使用者可編輯的字段作為鍵；

（4）可選鍵有時可作主鍵，能擁有建立強大索引的能力。

2）索引使用原則

索引是從資料庫中擷取資料的最高效方式之一，絕大多數的資料庫性能問題都可以采用索引技術得到解決。

（1）邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列采用非成組索引。考慮資料庫的空間有多大，表如何進行通路，還有這些通路是否主要用于讀寫；

（2）大多數資料庫都索引自動建立的主鍵字段，但是不能忘了索引外鍵，它們也是經常使用的鍵；

（3）不要索引memo/note 字段，不要索引大型字段，這樣會讓索引占用太多的存儲空間；

（4）不要索引常用的小型表，不要為小型資料表設定任何鍵，尤其當它們經常有插入和删除操作時。

4、資料完整性設計　　

1）完整性實作機制

（1）實體完整性：主鍵

（2）參照完整性

①父表中删除資料：級聯删除，受限删除，置空值；

　 ②父表中插入資料：受限插入，遞歸插入；

　 ③父表中更新資料：級聯更新，受限更新，置空值。

DBMS對參照完整性可以有兩種方法實作：外鍵實作機制（限制規則）和觸發器實作機制。

（3）使用者定義完整性：NOT NULL，CHECK，觸發器。

2）用限制而非商務規則強制資料完整性；

3）強制訓示完整性。在有害資料進入資料庫之前将其剔除，激活資料庫系統的訓示完整性特性；　　

4）使用查找控制資料完整性，控制資料完整性的最佳方式就是限制使用者的選擇；　　

5）采用視圖。可以為應用程式建立專門的視圖而不必非要應用程式直接通路資料表，這樣做還等于在處理資料庫變更時給你提供了更多的自由。

5、其他設計

1）避免使用觸發器，确實需要的話最好集中對它文檔化；

2）使用常用英語（或者其他任何語言）而不要使用編碼，确實需要的話可以在編碼旁附上使用者知道的英語；

3）儲存常用資訊。讓一個表專門存放一般資料庫資訊，可以實作一種簡單機制跟蹤資料庫，這樣做對非客戶機/伺服器環境特别有用；

4）包含版本機制，在修改資料庫結構時更為友善；　　

5）編制文檔，對所有的快捷方式、命名規範、限制和函數都要編制文檔；

6）反複測試，保證選擇的資料類型滿足商業要求；　　

7）檢查設計，在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。

6、資料庫命名規範

1）實體（表）的命名

（1）表以名詞或名詞短語命名，給表的别名定義簡單規則；　　

（2）如果表或者是字段的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞；

（3）所有的存儲值清單的表前面加上字首Z，目的是将這些值清單類排序在資料庫最後；

（4）所有的備援類的命名(主要是累計表)前面加上字首X。備援類是為了提高資料庫效率，非規範化資料庫的時候加入的字段或者表；

（5）關聯類通過用下劃線連接配接兩個基本類之後，再加字首R的方式命名，後面按照字母順序羅列兩個表名或者表名的縮寫。關聯表用于儲存多對多關系。

2）屬性（列）的命名

（1）采用有意義的列名，表内的列要針對鍵采用一整套設計規則；

每一個表都将有一個自動ID作為主健，邏輯上的主健作為第一組候選主健來定義。如果是自定義的邏輯上的編碼則用縮寫加“ID”的方法命名。如果鍵是數字類型，你可以用_NO 作為字尾。如果是字元類型則可以采用_CODE 字尾。對列名應該采用标準的字首和字尾。

（2）所有的屬性加上有關類型的字尾，如果還需要其它的字尾，都放在類型字尾之前。資料類型是文本的字段，類型字尾TX可以不寫，有些類型比較明顯的字段也可以不寫類型字尾；

（3）采用字首命名。給每個表的列名都采用統一的字首，那麼在編寫SQL表達式的時候會得到大大的簡化，但這樣做也有缺點，比如會破壞自動表連接配接工具的作用。

3）視圖的命名

（1）視圖以V作為字首，其他命名規則和表的命名類似；

（2）命名應盡量展現各視圖的功能。

4）觸發器的命名

觸發器以TR作為字首，觸發器名為相應的表名加上字尾，Insert觸發器加 _I ，Delete觸發器加 _D ，Update觸發器加 _U 。如：TR_User_I，TR_User_D，TR_User_U。

5）存儲過程名

存儲過程應以 UP_ 開頭，和系統的存儲過程區分，後續部分主要以動賓形式構成，并用下劃線分割各個組成部分。　　

6）變量名

變量名采用小寫，若屬于詞組形式，用下劃線分隔每個單詞。

7）命名中其他注意事項

（1）以上命名都不得超過30個字元的系統限制，變量名的長度限制為29（不包括辨別字元@）；

（2）資料對象、變量的命名都采用英文字元，禁止使用中文命名，絕對不要在對象名的字元之間留白格；

（3）小心保留詞，要保證你的字段名沒有和保留詞、資料庫系統或者常用通路方法沖突；

（4）保持字段名和類型的一緻性，在命名字段并為其指定資料類型的時候一定要保證一緻性。