【修鍊十】編碼

       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）嚴格執行計畫     此階段的專案計劃的時間點是確定的，除非專案經理有把握控制後續的進度，否則盡量不要調整裡程碑點。