為什麼我們在考慮代碼管理的時候會擔心影響程式員的積極性?精英化的團隊是不是能完全解決代碼品質的問題? 戰功文化會引入什麼樣的代碼管理問題? 以下是我對這些問題的思考。
代碼之於程式員，就像沙場之於將軍。普遍希望完全控制碼，可以自由馳聘、攻城掠地。但對於一個團隊合作下的代碼，這種行為卻隱藏著極大的風險。特別是在一個崇尚戰功文化的團隊裡，在鼓勵大家承擔更多責任的同時，同時也要注重對代碼上的領域限制和約束。在一個較大Team Dev中，模組層級的代碼許可權管理仍然是不足的，需要引入代碼檔案的許可權管理。但管理上普遍受到某種認識上的限制。
代碼管理上的問題代碼管理並不是技術上的問題，而是一個管理上的問題。
代碼管理看似很簡單。只要搞了組態管理，一切都到位了。但這隻是形，至於代碼管理的細節問題就是千差萬別了。把組態管理當成是保留代碼記錄的想法還是很普遍的。
事實上，代碼管理還有一些管理問題，如代碼的許可權管理、Review機制，周期性審查和相應的稽核機制等。
從技術做到代碼管理不難，難的是配套的管理方法。技術是管理的工具，無法代替管理。但管理的痛點又來源於哪裡?
很多的公司都經曆過創業階段的作坊式開發，從程式員到管理者都有對代碼的絕對控制的情結。當公司規模化後，就有了更多的正常化管理的需求。但對於代碼的管理，總有太多的理由讓管理者無法做到位。一方面強調為了保護程式員的積極性而盡量減少約束，另一方面，當出現問題時，則強調人的態度、意識之類的主觀因素。於是儘可能聘用優秀的人就成瞭解決方案。暫且不論這種人事管理上的問題，至少不能真正解決代碼管理和品質的問題。
人的問題也是管理的問題強調人的態度是咱們的習慣。精神、意願、態度，甚至人品，都是我們在平時工作中被反覆強調的。工作上也講究樹典型，人帶人的工作方式。這一切在那個物質缺乏的時代都曾發揮到極致，精神上的引領發揮著很大的作用。但數十年過去，那一切又充滿著非議。
人的問題不能被忽視，但不應該在整體範圍上去看。就是不能用集體的意志去抹殺個人的意願。人性的優缺點必須正視，正如人人都會犯錯一樣。如果犯了一次錯，就被扣上個標籤，顯然是不明智的。
在現實中，中式管理強調主觀能動性、系統和整體觀，對個體和細節的把握不足。正因為對具體管理方法的無力感，讓我們更易於接受從人的角度思考問題，本來的一個具體問題，轉變成一個精神指導的問題。事實好辦了，定個目標，強調細心、認真、嚴謹之類的做事態度，再宣傳幾個典型發揮一下影響。有沒有讓你想起我們小時候的小紅花。我們就是被這樣哄大的，我們也都知道，典型也有犯錯的時候，一時的典型，絕不代表是永遠的典型。
這樣的管理方式，就是那種不可說的境界。一切都是混沌的，模糊的，只有方向，一切都在某種不可言明的力量作用下發展。好了，成了，一切盡在掌握中。如果沒做好，那隻能說是時候未到。於是我們造出了高精尖的科技，但卻生產不出令人放人的奶粉。我們創造的技術，一到量產就問題百出。這一切都源自抓大放小的思想。
有沒有辦法讓管理正視細節，正視具體問題? 關鍵在於去除不必要的心理負擔，建立流程和方法。用流程來約束，用方法來指導。
積極性的辨證回到代碼管理上來，最大的心理障礙是擔心影響程式員的積極性。 這裡面有兩個問題，一是積極性和代碼管理的約束是否有真正的聯絡。第二個積極性的問題是否真得重要到成為管理的障礙。
對於第一個問題，什麼是積極性？約束是否會影響積極性？這其實取決於大環境下的價值觀，而不是個人的態度。是畫個圈說明利害，還是等到實際遇到問題，再做抉擇? 做事的時候，相對於不能自由發揮，更怕得不到清楚的定義。所謂計劃趕不上變化，變化趕上老闆一句話。自己做得很辛苦最後發現方向錯了，這不是很悲哀了。
當然約束多了不是件好事，特別是進入到微觀管理的狀態，那確實很可怕。那還是在流程定義走入了誤區。
流程定義要達到的效果是最大化地減少人為的犯錯的可能，做前有預期，做時有範圍有方法，做後有檢查。獎懲是輔助手動，不能把它當成流程定義來使用。
再談一下戰功文化所帶來的問題。 積極性顯然在戰功文化裡是非常受到鼓勵的。可如何來保護積極性？保證它能帶來好的結果呢？各個程式員都負責一部分功能，像是一地的諸候，積極經營自己的領地很好，但如果是去管理別人的領土，就有待商榷了。雖說鼓勵內部競爭的機制一直就有，也很有協助。就事論事，在一些複雜的產品研發內部推動就可以引入不必要的危險。判斷的條件就是是否能夠很好地理解別人的思維和設計。一點誤判或者一點資訊遺露都可能帶來新的問題。這樣的積極性需要鼓勵，更需要指導和約束。
第二個問題，積極性很重要，但它真得重要到不允許用管理的方法約束它嗎？ 顯然不是，在這種想法的背後其實還是有了前面提到的心理負擔後，認為沒有找到一個"適度"的方法。只要問問是公司的前途重要，還是積極性重要，答案就是很清楚了。
這裡有些危言聳聽了？我們都知道當代碼有了味道(代碼大全中的提法)，就等於開一個破窗，如果沒有果斷的改正措施，未來一定會消失在溫水煮青蛙的悲劇中。現在那些看起來輕鬆方便的行為正在引入更大的風險!
方便與有序我們都愛自由，可是當自由傷害到別人的時候，就是要受到約束。當我們在享受便利的同時，也要承擔一定的責任來維護這個環境。一次超車就可能導致大家一起堵上半天，倒不如按順序來得快。所以方便要建立在有序的基礎上的。
問題是如果沒有人讓我們排隊，沒有人告訴我們如何排隊(顯然醫院、銀行、學校飯堂這些地方的排隊方法會有不一樣的方法)，失序就成了必然事件。失序意味著問題，而不是風險。帶來的傷害可大可小。
原本代碼管理就有許可權一說，但是常常界定在大的模組間，目的通常在於保密。而在一個部門內部，許可權是通常不明確的。內部的程式員仍然可以去修改自己覺得不合理的地方，這就是問題所在。
流程建設的重要性對於一個研發團隊而言，讓人人享有自由最好的方法就是定義出約束。由標準的流程做為基礎形成良性的動力。公司發展節奏越來越快，越容易忽視基礎建設。當人人都忙於需求和解Bug時，基礎問題會逐漸吸引風險，然後在某個時間引爆。似乎有點做得越多，就會錯得越多的意思。當在開發過程開始遷就某個曆史設計或者行為時，就表示基礎問題已經出現了。
在寫代碼上，大家都有重構的意識。而在管理上呢，何嘗不需要重構！小步慢走進行流程上的重構也是Scrum一個實踐。
流程提供的是一個明確的框框和方法，在不同的階段使用不同的管理方式，也是應對具體問題的策略。如果全以人的問題來視之，多少有些自欺欺人。為什麼國外優秀的實踐到國內總會變味？ 中國太聰明了，總會用自己的理解和自己習慣的方式來看待問題、解決問題。在這個過程中，無法實實在在的面對具體細節問題，所以結果就會有其形，無其實。
(我們總將程式員的時間限定在編碼、做需求、解Bug之類看似直接支撐業務的事情。反而對於基礎的生產力提高是依賴於程式員個人的發現和創造。可是如果程式員都已經在忙著做具體的項目，哪有時間做更精細的最佳化。細想一下，也能在東西方思維的差異上找到答案。想想為什麼西方人在基礎學科上的成就更大？)
錯的事情，做得再多也是錯的! 當然對與錯是相對的，但至少要瞭解我們的問題。
這是我們流程建設方法上的不足！面對實際問題尋找解決方案就是出路所在。
代碼責任制有了高層次的認識，現在只談代碼管理。
一定要先明確代碼是屬於公司的，換個老闆常說的，代碼是屬於集體，總之不是個人的。以此為基礎的代碼管理就是一個必須的管理行為。具體的責任體現在誰對代碼負全責? 包括誰可以修改代碼，由誰來Review同意後才能提交。而其粒度要細到檔案或者目錄。
代碼不是公用資產，即便是開源項目，也常常有Review機制。 這裡的Review並不單單指Peer Review，而是必須經過代碼負責人的審查才能提交代碼，才算是承認了你的修改。
代碼負責人對所負責的代碼，就要熟悉其設計及擴充，以及相關的曆史。這樣可以做到關鍵內容的集中管理，有免疫的效果。文檔可以協助做得更好，可現實情況下文檔通常又是不足的。如果代碼負責人流失怎麼辦？ 為什麼代碼負責人只有一位?
其他程式員仍然可以學習修改這部分代碼，只是在提交時遵循這個流程就可以了。代碼的負責人可以變，但流程不能變。如果隨著程式員的成長，可以負責的代碼變多，也是在負責人上的變化，而不是要跳過流程。
如此簡單的一件事，被我羅嗦一大堆。得出結論不是我的目的，我更想強調的是之前的思考過程，因為一種認識會決定一系列的行為。只有找到根本原因，才能更好地認識我們周圍發生的事情。
轉載請註明出處:http://blog.csdn.net/horkychen
