實現階段, 詳細設計, 編碼過程中的控制與管理

一、     前言

項目進入實現階段, 主要活動聚焦於：詳細設計、編碼、自測試、監測。此節為軟件項目過程中，歷時最長，工作量最大，細節最多的環節，確保此節之可控，可管理，實為至關重要。

然則公司層面的此節過程控制, 不夠具體, 也沒有與其他維度的管理措施相結合, 市面上之參考實施往往也是論而無策，況每公司有其特殊性, 不能一概而論之。

本細則就實現階段中的各項活動如何與質量保證, 績效考核, 管理工具如何進行有機結合, 使其管理活動不流於形式，便於實施，真正起到效用而進行原則性規定和范例規定。

實施過程中，問題多有變化差異，特殊性等，本文也不能做到全面，全面必造成細節繁縟，限定過緊，未必有利於實施，因此必有其缺失，但萬變不離其中，只要遵循一定的原則去分析和解決，或可迎刃而解。

二、     原則

1       此過程中的每項活動，規定須由開發人員主動發起，非管理者被動去追；

2       開始實施時, 必嚴格要求, 細節形式也須鎖死, 必待開發人員養成習慣后, 才可形式不拘；

3       措施之細節須與管理活動中的質量保證, 績效考核, 管理工具相結合, 一舉多得, 既利本團隊代碼質量, 懲獎有據, 又同時兼顧公司過程管理規范所需。

4       措施需利於實施，最大限度力求不額外增加工作量，可靈活規定哪些功能，代碼免查或抽查，但必須事先規定。

三、     例則

(一)       任務切分

本公司之開發任務切分（WBS）以Redmine作為管理工具，任務切分須遵循以下原則：

1       切分任務以兩個工作日為限，這是公司硬性規定，符合QA要求，須遵循之；

此條規定看似死板，卻與以上第二條原則：“細節形式也須定死”異曲同工。

2       切分任務須保證以下兩點：

2.1       定義任務之可交付件：可以是代碼，文檔，二進制文件，包，可運行程序等；

2.2       可交付件要便於驗證，且須定義驗證之標准，方法，不得模糊；

2.3       是否是關鍵任務；

2.4       根據IFPUG定義功能點數和任務復雜度，以此作為任務分值；

2.5       任務的關鍵特性：功能，性能，穩定性，易操作，可移植，可配置等不限；

(二)       詳細設計

開發人員根據Redmine排定之任務進行開發，遵循以下准則：

1       編碼前，原則上須提交詳細設計，項目經理或架構師或項目經理授權的人批准后，方可編碼。若遇到不能及時確認，可先行編碼，待審批人得空，須第一時間找其確認。

2       開發人員須主動進行詳細設計和及時確認，若直至編碼完成仍未確認，視為忽略確認， KPI-1，終未見其人，電話溝通。

3       多條Redmine上的開發任務可能屬於同一功能，或者代碼邏輯中不可分割的項，開發人員自性評估，合並，而后做到一個詳細設計圖中；

4       詳細設計規定：

4.1       以Rose時序圖或流程圖，說明功能之實現過程，細節程度到函數為准。

4.2       關鍵函數，且對函數處理流程或邏輯進行流程圖示或逐條文字說明；

4.3       代碼實現有差異，須更新詳細設計，且及時通知審批人；

4.4       詳細設計中，須標明：

4.4.1       關鍵函數；

4.4.2       要單元測試的函數，關鍵函數必須單元測試；

4.4.3       提供給其他模塊的接口，必須標明，必須單元測試；

4.4.4       編碼所需時間評估，以小時計;

4.5       詳細設計中, 須提供自測試方案作為設計之部分, 自測試方案須明確：

4.5.1       自測試的方法: 單元測試，與其他模塊整合測試，編寫測試代碼測試，手工測試。

4.5.2       測試方案：

4.5.2.1      構造怎樣的數據，怎樣的操作才能驗證編碼；

4.5.2.2      預期結果該怎樣查看，怎樣驗證；

4.5.3       測試方案必須能夠驗證任務的關鍵特性：
前述之功能，性能，穩定性，易操作，可移植，可配置等；

4.5.4       測試方案若是針對功能的，必須能夠驗證正常流程和異常流程；

5       例外：

5.1       設計須編寫測試代碼進行思路驗證的，首先提交逐條闡明的思路；

5.2       研究性任務，開始任務前，首先須提交逐條闡明的研究思路；

6       詳細設計文件

6.1       詳細設計作為項目的一部分, check in到工程中;

6.2       統一命名規則：產品名_版本號_功能名稱_設計者姓名.mdl

6.3       詳細設計統一放到項目的rootdir/detaildesign目錄下；

(三)       編碼

1       編碼當遵循公司編碼規范以及下述之代碼走查中規定的代碼規范；

2       若詳細設計中，確定了要單元測試的，當先編寫單元測試代碼；

3       編碼當按照詳細設計編碼實現，若有差異，須及時更新並通知審核人；

4       記錄編碼工時：記錄編碼開始，截止時間，計算工時，並記錄在案；

4.1       編碼工時以編碼開始，直至調試完成，當需要聯合其他模塊的，以整合完成為結束；

4.2       當編碼過程中，發現需要對以往其他任務關聯的代碼進行重構的，記錄在案；對以提交驗證模塊代碼作更改，並特地標明，沒有標明的說明的，KPI-1；

4.3       編寫單元測試代碼的時間，算到自測試工時中；

5       編碼完成時，統計代碼行數，完成代碼行統計的時間，算到工時當中；

6       編碼輸出工件中，要求文檔的，要按照正式文檔編寫格式，提供正式文檔，而不是以后再補；

6.1       輸出文檔工件

6.1.1       為項目之一部分, checkin到項目中；

6.1.2       統一命名規則：產品名_版本號_8字以內短作用名.擴展名；

6.1.3       統一放到項目的rootdir/configdoc目錄下；

7       編碼完成后，創建編碼日志，記錄：

7.1       編碼工時：含預計工時，實際工時；

7.2       更改記錄：設計更改，其他已提交代碼更改；

7.3       自測試工時，在自測試完成后填寫；

7.4       編碼日志文件:

7.4.1       編碼日志，為文本文件， checkin到項目中；

7.4.2       編碼日志統一命名：產品名_版本號_編碼者姓名.txt；

7.4.3       編碼日志統一放到項目的rootdir/codelog目錄下；

(四)       自測試

1       自測試須按照測試方案編寫測試案例；

2       自測試案例為：驗證所開發之功能的：輸入數據，操作步驟，預期結果；

2.1       輸入數據可以是：調試輸入，構造數據，其他模塊來源之數據等不限，但必須要符合實際業務；

2.2       預期結果可以是：界面展現，數據，日志，調試觀察等不限，但必須清楚確定；

2.3       操作步驟可以是：人工操作，調試逐步運行，運行單元測試等；

3       特別說明：

3.1       關鍵特性含功能的：
必須能夠驗證正常流程；
必須能夠驗證意外流程；

3.2       關鍵特性含性能的：
必須包含能夠驗證的測試環境，數據構造方法，性能計算方法；

3.3       關鍵特性含穩定性的：
必須包含針對各種異常狀況的容錯，恢復處理，並模擬異常；

3.4       關鍵特性含可移植性的：
必須包含在各個平台的功能測試案例；

3.5       關鍵特性含可配置性的：
必須包含對配置數據正常和異常的處理；

4       自測試報告已自測試案例為基准，填寫自測試結果，即為自測試報告；

4.1       整合階段的自測試報告，交由打包者整合提供；

4.2       打包者負責眼看各人之測試報告, 確保各人自測試通過;

5       自測試完成后，如實填寫自測試工時；

6       自測試文件

6.1       自測試報告，為文本文件， checkin到項目中；

6.2       統一命名：產品名_版本號_功能名稱_編碼者姓名_xxxx_自測試.xlsx；

6.3       編碼日志統一放到項目的rootdir/selftest目錄下；

6.4       若為整合階段之整合自測試報告, 命名為:
產品名_版本號_BuildNumber_自測試.xlsx

(五)       代碼走查

1       代碼走查由編碼者主動發起，主動講解，而不是由其他參與走查的人發問；

2       代碼走查一旦發現並認定缺陷，無需解釋, 發現缺陷,不一定扣KPI，但若一周內出現2次以上相同的缺陷， KPI-1；

3       走查前准備
必須有准備，准備的文檔為：

3.1       更新后的詳細設計文檔；

3.2       編碼日志；

3.3       自測試報告；

3.4       不准備以上3樣文檔的， KPI-1；

4      走查首要檢測

4.1       查3樣准備文檔是否備齊；

4.2       查交付件是否都有；

5      走查中

5.1     走查業務實現；

5.1.1   按照自測試測試案例運行；

5.1.2   按照詳細設計之流程自我講解；

5.1.2.1      關鍵函數實現邏輯講解；

5.1.2.2      關鍵數據結構，不能有不明確的地方；

5.2     走查代碼規范

5.2.1     代碼格式

5.2.1.1    縮進:　統一以ＴＡＢ縮進；

5.2.1.2    換行，同一方法類，　功能模塊之間以空行分隔；

5.2.2     注釋規范

5.2.2.1    源文件注釋、類注釋、方法注釋、實現必要說明注釋。

5.2.2.2    采用統一格式，格式老潘定，每個人的ＩＤＥ添加

5.2.2.3    只要出現的注釋字段，都必須填，不能空；

5.2.2.4    特別是參數的作用、取值范圍及參數間的關系;

5.2.2.5    修改注釋：誰, 什么時間, 為什么修改, 對應到代碼段

5.2.3     函數規范

5.2.3.1    異常必須說明什么情況下回拋出異常;

5.2.3.2    多線程的設計, 必須做詳細的設計說明;

5.2.3.3    有Close方法的類, 要注意調用Close

5.2.4     拷貝重復

5.2.4.1    出現兩次以上的相似度強的代碼, 封裝;

5.2.5     異常規范：

5.2.5.1    異常處理、異常捕獲、異常日志、異常提示（准確、有意義）。

5.2.5.2    異常捕獲不應該改變異常本身的作用, 除非是特殊需求;

5.2.5.3    代碼中不能使用System.out.println()，e.printStackTrace()，必須使用logger打印信息。

5.2.5.4    異常應該用說明文字來描述異常出現的可能原因或者代表的具體業務內容, 不能直接log異常本身完事;

5.2.6     命名規范

5.2.6.1    類、方法、變量、配置文件名稱等等命名規范、易懂、有意義。

5.2.6.2    java命名法則

5.2.6.3    方法名, 變量名, 易懂、有意義, 不縮寫

5.2.6.4    帶特征(該list就list, 該map就map)

5.2.7     單元測試。

5.2.7.1    已經指出要做單元測試的地方, 必須做單元測試;

5.2.8     函數過程

5.2.8.1    函數的規模盡量限制在200行以內, 超過則說明

5.2.8.2    一個函數最好僅完成一件功能, 違反則說明

5.2.8.3    盡量不要編寫依賴於其他固定函數或對象內部實現的函數。

5.2.9     日志記錄

5.2.9.1    系統中涉及到以下功能的代碼塊，必須作日志記錄

5.2.9.1.1      用戶登錄

5.2.9.1.2      對數據庫進行插入、更新、刪除SQL操作的

5.2.9.1.3      會造成系統數據發生變化 (如調用執行數據庫的函數、存儲過程等)的

5.2.9.1.4      會造成系統配置文件發生變化的

5.2.9.1.5      涉及對服務器上的文件進行操作的(如文件上傳、刪除等功能)

5.2.9.2    記錄內容：用戶身份標識、操作時間、操作IP、操作內容(可記錄操作SQL語句，也可以做詳細文字描述，或兩者兼有)

5.2.9.3    業務流程的關鍵節點, 關鍵數據必須在日志中有體現, Level為Info級別;

5.2.9.4    日志文件記錄到一個文件, 除非運維有特殊要求的情況;

5.2.10  性能

5.2.10.1 SQL要審查

5.2.10.2 內存, 線程, 連接特別頻繁使用時, 要用池;

5.2.11  公共代碼

5.2.11.1 不要輕易編寫公共代碼, 二是首先問其他同事有無此類公共代碼, 有則盡量用;

5.2.11.2 沒有公共代碼, 申請編寫公共代碼;

5.2.11.3 公共代碼提交並測試通過, 在產品中驗證, 對多個公共代碼組織培訓推廣,推廣3個使用者以上者, KPA+1;

5.3     優秀分享

5.3.1 亮點: 算法精煉, 高性能, 規范優美, 快而好;

5.3.2 只要有說服力的亮點都可以;

6      日/周走查

6.1      項目經理或架構師在周會上宣布，某周為xxxx規范周，該周檢查代碼規范時，以檢查代碼規范中的xxxx為重點；

6.2     日走查

6.2.1     以走查業務實現為主；

6.2.2     以走查代碼規范為輔；

6.2.3     重點看周檢查主題；

6.3     周走查

6.3.1     周走查當日的代碼走查;

6.3.2     周走查以優秀分享為主;

6.3.3     項目經理或架構師分享當周發現的典型問題及解決方法;

6.3.4     周走查評選優秀代碼, 當選第一者, KPA + 1;

6.4       被走查的編碼者自己記錄走查過程中發現的問題或缺陷；

6.4.1       走查報告

6.4.1.1      日走查以文本文件的方式記錄.

6.4.1.2      記錄到編碼日志中, 填寫Redmine時, 作為附件上傳;

6.4.2     周走查報告

6.4.2.1    周走查報告為匯總之日走查報告;

6.4.2.2    形成公司要求的正式的走查報告,提交到SVN;