? ? ?2013.6.11 ? ? ?如果說一個男人最有面子的事是身邊常伴漂亮的女伴，引別人側目。那么程序員最有面子的事，一定是寫下的漂亮的代碼，引無數草莽感嘆。有趣的是，我們總是有機會看到這樣的現象：一些老模塊雖然設計不好，但是代碼質量不錯，所以依舊穩定，但是一些設計理念很好的模塊，卻被寫得亂七八糟，漏洞百出。 ? ? ?代碼是設計的最終產物，是一個程序員基本功，偷不得一分巧。如果一個人總是喜歡高談闊論，那么去看他的代碼，通常一眼看下去，就能知道他是“真正的高手”還是“空想家”。 ???????項目管理的代碼管理，通常期望達成以下幾個目的： ? ? ? 1、避免出現殺手：“高手不是培訓出來的，也不是管教出來的“，高手之所以視為高手，是因為其很少見，而成就高手的素質通常不是眾生常具備的。但是項目組內的隱藏的殺手，卻可以通過管理降低其出現的風險及危害。A/B角審核，簽入代碼控制等這些都是關卡。 ? ? ? 2、保證代碼質量：代碼不一定能像高手寫的那么極端漂亮，多一分便肥，少一分便瘦的地步，但是卻可以通過管理保證大家代碼的邏輯清晰度，可讀性，減少邊界錯誤，減少低級錯誤等。例如：工具掃描，單元測試，每日構建等。 ? ? ? 3、培養人員：“近朱者赤，近墨者黑”，影響的力量是巨大的，通過編碼階段的互動交流，可以讓一部分組員能夠快速脫離”山寨“，進入”職業“狀態，尤其對新員工有效。 ? ? ? 按項目管理的五要素分解如下：  **1、干系人期望-目標** ? ?編碼階段干系人的影響已經很小，可以先不討論這節。 ? ?? **2、沙盤-思路** ?? ??1）開始前掛牌講解好的代碼 ? ??同設計一樣，很多時候往往不是大家不愿意寫出好的代碼，而是大家不知道好的代碼是什么樣的，因此在項目組開始編碼前，講解優秀的代碼，會讓組員開工之前，有一個學習的目標，會讓編碼工作變得更有意思。這里更好的做法找出那些和本項目組有關的優秀代碼示例，更是事半功倍，例如：部門類似業務的好的代碼。 ? ??2）公開走讀計劃 ? ??記得在管理上有個研究工作效率的故事，發現把工人召集到一個實驗環境中，在設施完全一樣的情況他們的工作效率和質量比平時都有大幅提高，逐個排除了很多影響因素，最后發現原來是”關注度提高“的原因。人都是有表現欲，當自己手頭的上事被關注時，往往我們希望把自己最好的一面表現出來，人性如此。代碼走讀就是這個作用，大多數時候提前公布的走讀計劃比實際走讀出那幾個問題更重要。 ??? 安排走讀計劃時，需要注意到這幾點; ? ? a、走讀成員要有威懾力和權威性，避免大家扯皮。例如：找專家，架構師，主管等 ? ? b、走讀的結果無論好壞，都要公布，以便項目組形成一股良性氛圍 ? ? c、當項目組模塊很多時，可以抽查一定比例的模塊走讀，這樣在走讀計劃公布時，不要明確模塊，避免沒有在走讀計劃內的模塊作者，暗自慶幸。 ?????3）A/B角審核 ? ??只有走讀計劃是不夠的，因為走讀通常要不少人參加，不可能將時間拉得過長，因此很多細的邏輯審核不到。另外走讀模塊往往是在這個模塊代碼已經或接近完成時，時間點偏晚，有些”木已成舟“的味道。和走讀計劃相配合的是進行A/B角審核，我們可以在設計或更早的階段，明確項目組的A/B角關系。A/B角的好處在于，代碼得到及時審核，測試階段A/B角可以互擔壓力。 ? ??A/B角的常見組成方式如下： ? ? a、項目組分成小組，組長擔當B角 ? ? b、項目組有某些模塊的專家，這些專家擔當對應領域的B角 ? ? c、一個模塊有幾個人共同完成，他們互為A/B角 ? ? d、項目組不大時，由項目經理或質量經理擔任B角 ?????4）代碼checklist及工具掃描 ? ??代碼checklist是將大家常犯的共性錯誤集合成的檢查表，例如：一些潛在的死鎖風險，C++用法等。而工具掃描是為了排除一些低級錯誤，例如：內存泄露。 很多時候低級錯誤的排查bug的難度是不低的。 ?????5）單元測試 ? ??做好的單元測試的核心在于兩點： ? ??a、要有好用，省時的單元測試案例編寫工具，例如：C++ Test等 ? ? b、管理好單元測試案例，不能只做一次，而是每次代碼發生變化，每次代碼重新編譯時，都能自動執行單元測試。如果單元測試只能用第一次，投入產出比，就會小很多。 ? ? c、能夠在目標機上執行單元測試案例，這樣能夠避免大量打樁，導致工作效率下降。 ?????6）代碼簽入控制 ? ??代碼簽入控制往往是強制A/B角的實施方法，即：收回A角的代碼簽入權限，只允許B角簽入，如此能夠保證B角的審核頻率能夠達到每個包一次. ?????7）每日構建 ? ??每日構建是指編碼開始后，每天環境會自動從SVN/VSS上獲取代碼進行編譯，并執行對應的單元測試案例，每天早上通報錯誤。每日構建的好處在于：系統在持續良性集成，避免聯調開始后，大家一窩蜂的把代碼簽入，有大量的編譯錯誤等，消除這些錯誤需要消耗很多時間，并容易犯錯誤。 **3、計劃制定** ??1）?代碼走讀計劃 ? ? ?代碼走讀計劃如上述第二點，需要提前預約專家，架構師等，并在項目組進行公布。 ? ???2）?配置管理計劃 ? ? ?涉及到代碼簽入權限，編譯環境維護權限等。例如：一個大項目組，如果編譯環境沒有控制權限，沒有指定操作規范，很容易被大家搞亂套。 ? ???3）?單元測試計劃 ? ? ?不是所有情況下，用單元都是合適的。例如：對于一個老模塊的改動，此模塊依賴很多外部資源，并且之前沒有任何單元測試案例，這會導致編寫對應改動的單元測試案例，成本很高，此時需要進行權衡投入產出，可能這時找此模塊的專家進行審核是個更好的選擇。 **4、風險管理** ? ??1）編碼進度不透明 ? ?大多數人都習慣先松后緊的工作方式。“猶記得大學時，老師布置了作業，兩周期限，下課是交作業的最后期限，上課時，班上大多數同學們都是拿著借來的作業奮筆疾書”。編碼階段的時間在轉集成前各階段中，算上比較長的。而這個階段的工作進度非常不好衡量。經常看到一個模塊編碼進度迅速從0%到90%，而后花了兩倍的時間才從90%到100%，無法有效得知項目的進度，就是項目的風險。 ? ??這里有個好的做法可以參考，編碼計劃表從估算表中導出，因為估算表中每個估算項粒度通常不會超過2天。這樣在編碼進度表更新時，去除百分比，只能更新兩種狀態，未完成，完成，如此計算出的項目進度是比較準確的，同時也能夠幫助組員理清當前自己的工作進度。 ??2）新員工代碼質量 ? ?新員工的成長是需要團隊付出精力的，針對他們我們往往要有更頻繁的代碼審核、指導 或安排責任心更強的B角。雖然新員工的操心在所難免，但是他們潛力也是無限的，耐心地培養后，總能從中收獲到驚喜。 ? ?3）識別出風險模塊 ?? ?項目組的進度不同于齊步走，總是有前有后，質量同比也是有好有壞，那么在整個過程中通過上述的種種辦法找出這些有風險的模塊，進而采取調整措施是項目管理中不可缺少的部分。 ? ? ? ?4）需求實現有遺漏 ? ?任務分解時往往并不能完全根據需求進行，在代碼實現時，因為大家的思維已經在很細節的層次，所以此時核對系統需求或需求跟蹤矩陣，就很容易發現需求的遺漏項。 **5、團隊管理** ? ??1）每日構建有獎懲 ? ?有獎懲是為了提高大家對這件事的重視程度，當然每日構建通常犯的錯誤不是很嚴重，而且易于發現，針對這種場景，不適合采用過于嚴厲的懲處措施就不合適了。例如可以采用如下措施： ? ?a、累計錯誤數，如果項目組整體達到5次，造成錯誤的同事請項目全體成員吃水果或喝飲料。 ? ?b、每天系統自動通告構建的結果 ??2）走讀計劃有獎懲 ? ?走讀計劃因為動用了外部資源，比較權威，懲處和獎勵要重一些。例如：對于代碼走讀結果不好的組員，本季度取消得A資格，走讀結果好的組員，給予獎品及季度優秀的考核。 ? ?3）進度在項目組定期通告 ? ?每周至少一次項目組在一起回顧上周的進度和下周的計劃是很有必要的，這樣容易讓大家對整個團隊產生歸屬感，并且能夠得知其他人的工作進度，有個橫比，從而能夠自我進行進度調整。 ? ?4）嚴格執行計劃 ? ?此階段的項目計劃的時間點是確定的，除非項目經理有把握控制后續的進度，否則盡量不要調整里程碑點。