為你身後的同事寫代碼

為你身後的同事寫代。傳說這句話是從惠普出來的，曾經很有名。當敏捷開發出來之後，被指太重量級，和敏捷的思想相違背，被很多人批評了一頓。敏捷提倡需要時，再去實現。而為你身後的同事寫代碼，要求你再寫代碼時要為你的同事著想，就是為使用代碼的人著想，怎麼能讓他使用方便。雖然我是一個敏捷擁護者和實踐者，但我還是認為為身後的同事寫代碼很有用，甚至這句話的思想和敏捷開發並不矛盾。

最好的軟體代碼是什麼樣的代碼？

易擴充。當使用者提出新的功能時，能夠很快的在保證系統品質的情況下，把新的功能添加到系統中。

易修改。容易修改，就要要求減少重複代碼，代碼易讀，整個系統的代碼風格一致，架構一致，命名一致，注釋得當等等。

還有系統架構分明，各個層次各負其職、沒有使用不必要過於複雜的技術，沒有使用不穩定的第三方庫等等。

怎麼能讓系統代碼達到以上標準，那就是好代碼，不管寫這些代碼時的指導思想是什麼。

在軟體開發時，常常遇到的問題就是使用者需求不明確，需求在不斷的變化，商務邏輯複雜。這些問題基本上每個軟體項目都會碰到。既要讓軟體能夠快速穩定的運行，又要保持系統的高擴充和可修改性，確實為系統設計和代碼編寫提出了很大的挑戰。

我們在軟體開發中最常見的開發模式都是每個人負責一個模組，從頭到尾，從最上層，到最下層。很少有橫向分開的。當然這種模式也有很大的好處，而且這種也是在當前很多情況下比較適合的。但這中模式代碼的一個問題就是和別人寫的代碼交集很少。一般自己寫的上層代碼去調用自己寫的下層代碼，這時，每個人都會陷入自己為自己寫代碼的境地。現在就是上層需要什麼要的代碼，下面就要去實現。這種情況很常見，而且很多時候，我們都是採用這個方式。但這有個缺點，我們有時候比較懶，上層調用下層代碼比較麻煩，反正自己調自己的，這些代碼放什麼地方都可以。這樣就導致了代碼混亂，層次不清，調用複雜，甚至連物件導向最基本的封裝性都保證不了。

如果我們為身後同事寫代碼呢？那我們會注意到，我們需要該封裝的地方自己一定要封好，你不可能讓上層的開發人員為你的懶去寫代碼，這樣會遭人鄙視的。不該自己寫代碼，自己肯定不會寫，那時損人也不利己的事。還有一點，就想讓自己寫的代碼，在別人用時特別好用，簡單，一目瞭然，自己也有成就感。對了，現在我們已經談到了物件導向的本質了，封裝。你不用瞭解裡面怎麼實現的，你只需要知道它怎麼用的就可以了。

所以，敏捷開發和這句話有矛盾嗎？我覺得好像一點矛盾也沒有。