近期看到一篇博客。大致的意思就是網管將原本混亂不堪的交換機整理整齊了，起初交換機是圖2那樣的，由于越來用的人越多，操作的人越來越多。終于成為了圖1那個樣子。這不禁讓我想到了項目中的代碼。原先在剛上線的時候談不上是完美的，但它總歸是整齊的。可是由于中間人員流動，bug改動等等原因吧，終于的結果就是代碼一團糟。為什么會出現這種情況呢？
? ? ? ? ??
圖1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖2
權限（權利）
拿交換機來說，當自己的網絡不通暢的時候自己能夠隨便進出機房對交換機進行操作，插拔自己的網線的時候僅僅要能讓自己的網絡通常，那么網線亂一些那又有什么關系呢？第一個人是這樣想的同一時候也是這樣做的，緊接著第二個、第三個……久而久之就成了圖1的樣子，混亂不堪。
同理代碼也是一個道理。自己須要實現一個功能，在原來代碼的基礎上進行改動，僅僅要自己的功能好使代碼之間的耦合大一些又有什么關系呢？剛入職的第一個新人是這么想的也是這么做的緊接著第二個、第三個……久而久之倉庫中的代碼就變成了如今的這個樣子。慘不忍睹。
沒有權限的人能夠操作本不該操作的東西，終于一定會一團糟。由于的人們在自己焦頭爛額的時候才顧不上會不會影響他人，盡快將自己手頭的棘手的問題解決掉才是重中之重。
對于權限管理最經典的一句話就是：權限越低犯錯的機會就越少。
所以新人直接提交代碼到代碼庫是欠妥的。
責任
出現這種情況是由于大家僅僅關心自己的一畝三分地。“各掃自家門前雪。休管他人瓦上霜”是每一個人的不變信念，問題是“他人”并非別人，是自己人。他人“瓦上霜”事實上就是以后自己的“門前雪”。
事實上責任這個詞就是自私的放大版。胸懷有多寬廣責任就有多重大。
記得讀過一篇關于代碼質量的文章，當中說到一個理論叫破窗理論：一個房子假設窗戶破了，沒有人去修補，隔不久。其他的窗戶也會莫名其妙地被人打破。一面墻。假設出現一些涂鴉沒有被清洗掉。非常快的，墻上就布滿了亂七八糟、不堪入目的東西；一個非常干凈的地方，人們不好意思丟垃圾。可是一旦地上有垃圾出現之后。人就會毫不猶豫地拋，絲毫不覺慚愧。
非常多情況下代碼晦澀難懂并非一下子就變成這個樣子的。冰凍三尺非一日之寒。
從第一個不負責任的人開始代碼變得越來越難以維護。假設在提交代碼之前有人（幾個人）去review要提交的代碼，相信出現故障的可能性就大大減小。試想自己的代碼是要被全世界程序猿讀的，相信你會提高自己的代碼質量。
行動
發生了這種事情，終于是要解決的，假設希望永遠不發生這種事情。這是一種理想狀態，僅僅有說前面的工作我們盡可能的做好來減少這種事情出現的概率。
可是。一旦發現了問題還是須要解決的。并且是立馬解決。否則錯誤會隨著時間的推移解決成本也就越來越大。不要借口說如今沒時間，等有時間了怎樣怎樣吧。如今沒時間以后更沒時間，由于以后僅僅會比方今更忙。
(什么？項目緊沒時間，那么請跳槽，對于一個沒有規劃急功近利的公司是須要被社會淘汰的，所以你的不離職就是在姑息整個軟件行業的不良風氣)
Review初期是能夠避免非常多低級錯誤的，可是到了后期就流于形式了，由于一直負責review的負責人已經疲憊了。
況且非常多嚴重的bug并非review就能發現的，Review僅僅能找出顯而易見的錯誤。
所以，
第一、負責review代碼的人決不能固定，并且一份代碼能夠多人review
第二、不放過不論什么一個Bug，尤其是由于改動或者新用例帶來的bug。這些bug后面就藏著不整潔的代碼，須要整個團隊耐心的將其挖掘出來解決掉。
?
都說高質量的代碼須要高水平的開發人成員，事實上高質量的代碼，需要的是關懷開發商
版權聲明：本文博客原創文章，博客，未經同意，不得轉載。
)
