寫程式碼的三重境界

搞IT的就是修電腦的，做軟體的就是寫程式碼的。後一句可能更對一些，因為學校是這麼教的，開發工作中的確也是這麼在做。然而，新手在寫程式碼，牛人也在寫程式碼，他們之間有什麼區別？為何新人老手相互之間不理解？新手如何成長為牛人，老手如何百尺竿頭更進一步？BDD、TDD為何興起，又為何難以推行？軟體研發公司的寫程式碼能力提升為什麼這麼難？寫程式碼的三重境界記錄了關於寫程式碼的一些思考。

1. 寫程式碼的三重境界
1.1 寫程式碼三重境界之第一重境界是見山是山。
對第一重境界的人來看，寫程式碼就是軟體開發的全部，軟體開發人員的工作就是寫程式碼，如果沒有在寫程式碼，軟體開發人員就沒有在工作。
他們會第一時間投入到程式碼編寫工作中，編寫的程式碼可以執行是他們的追求。他們喜歡除錯工具，並將除錯和直接執行作為驗證的主要手段。在他們看來，寫程式碼是簡單的，設計不是必要的。他們對需求不求甚解。
1.2 寫程式碼三重境界之第二重境界是見山不是山。
在第二重境界的人眼中，寫程式碼只是軟體開發的一個階段，這只是軟體開發人員工作中比較低階的一種，軟體開發人員還有需求分析、架構、設計等更重要的工作在做。
他們會很晚才進入編碼階段，因為在這之前，他們還有需求分析、架構、設計等更重要的工作要完成，而編碼只是上述工作的一種結果呈現，編寫的程式碼沒有錯誤是他們的追求。也許他們會承擔一部分測試工作，但這不完全是他們的工作。在他們看來，前期設計好是最重要的，寫程式碼只是一種實現而已。他們對需求吹毛求疵，把細節討論到極致，以避免在後續設計和編碼工作中出現遺漏。
1.3 寫程式碼三重境界之第三重境界是見山還是山。
在第三重境界的人眼中，寫程式碼是軟體開發中非常重要的一部分，寫程式碼並執行的方式不僅用來實現需求，還用來探索需求、嘗試實現和演化設計。
他們會很早就開始寫程式碼，寫程式碼的過程和探索需求、嘗試實現與演化設計等過程有效的聯絡在一起，形成一種持續反饋學習的閉環。程式碼不是最重要的，準確簡潔的達成業務目標並且具有更好內部結構的可執行軟體才是他們要的。有時他們甚至會有意識的捨棄對於探索需求、嘗試實現和演化設計過程中的部分程式碼。測試是他們的首要工作之一，是寫程式碼並執行的關鍵一環，用於形成快速的閉環反饋。在他們看來，有些高層前期設計是必要的，而其他的很多設計則是通過寫程式碼演化出來的。有時，他們用程式碼為需求設立標準，並通過不斷反饋探索需求並糾正理解偏差。有時，他們快速給出原型，和客戶一起挖掘真正的解決方案。

2. 對三重境界的思考
2.1 軟體開發人員成長之路
大多數情況下，新手都處於第一境界。也有一些具有很豐富經驗但知識缺乏的老鳥處於這一階段。他們認為軟體工程都是些紙上談兵的東西，對分析模式、設計模式、架構方法等方法缺乏認識和掌握。他們對自己的程式碼能力相當自信，特別強調實幹對程式碼能力提升的作用，只有在看到對方的程式碼確實比自己好時才會服氣。經過訓練或者在實際工作中屢屢碰壁後，第一重境界的同學能意識到分析設計的重要性，開始學習掌握分析設計能力，向第二重境界轉變。
大多數同學在工作經驗積累後能到達第二重境界。第二重境界的同學對軟體工程有所瞭解，對UML圖等工具相當精通，推崇物件導向、分析模式、設計模式、架構方法等。他們比較傾向於自頂向下的設計，期望嚴格分階段執行需求分析設計實現測試等過程。雖然知道重構、演化設計之類的概念，但對於他們來講，重構還未形成習慣，還是不得已而為之。
只有很少的同學能夠從第二重境界走到第三重境界。這些同學本身不缺乏分析設計技能，UML、物件導向、設計模式等都有掌握。更重要的是，他們對軟體開發的認識發生了變化，軟體不是實現出來的，而是演化而來的，軟體開發的主體是人，可工作的軟體比程式碼更重要。重構、演化設計變成了他們的基礎技能，他們是TDD、BDD、DDD等方法的嚐鮮者與積極推動者。
2.2 境界之爭
軟體開發人員間的相互爭執很多，境界差異導致的相互不認可也是其中重要的一種。一重境界的同學嫌二重境界的同學動作太慢，小題大做，太理論化，動不動就分析模式、架構設計，二重境界的同學則認為一重境界的同學太過莽撞，思考不足，難以解決複雜一些的問題。二重境界的同學很不理解三重境界同學的工作方式，看起來設計能力挺強一個人怎麼那麼急於編碼呢。一重境界同學也受不了三重境界同學，動不動就是工作習慣，又在推行新方法，寫程式碼就寫程式碼好了，還分什麼高低貴賤。
對大多數公司而言，第二重境界是常見的選擇。它的好處是非常明顯的。首先，第二重境界和公司的開發流程極其配合，活脫脫的瀑布；其次，人員成長路徑清晰，從寫程式碼到做設計再到業務架構、技術架構，這是一條可控的成長路徑，符合公司崗位模型；最後，在做事上易於管理，在人員成長上易於管理，容易設計崗位績效，當然就選它。然而，它也帶來了壞處，第二重境界中學習探索變成了一個階段，而不是在整個過程中要做的事情，並且學習探索的比例隨著公司對可預測、可管理性要求的加強會進一步降低，公司在軟體研發中的學習和創新能力會以不那麼顯著的方式持續下降。直到有一天，公司意識到創新能力下降帶來的危機，但為時可能已晚。
在這種環境下，人員要成長到第三重境界變得更加困難。因為你不是和一個人（你自己）在戰鬥，你要面對的是整個環境。最好也最簡單的方式就是去適應環境，成為第二重境界的堅決追隨者。
2.3 BDD、TDD為什麼這麼難？
BDD、TDD（如果你不瞭解這些名詞，建議查一下）是第三重境界工作方式的典型示例。對於那些已經在第三重境界浸淫已久的牛人而言，這就是他們每天工作的方法。他們所做的就是把它描述出來，有時還開發出一些工具來簡化學習掌握這些工作方式的成本。
然而，軟體開發人員認為BDD、TDD很難，大多數人都還未具備探索需求、演化設計的能力。對第一重境界實幹型別的軟體開發人員，他們只有兩種選擇，其中一種是完全接受它，衝上去寫測試程式碼，做到95%甚至100%的測試覆蓋，很快他們會發現寫測試程式碼和維護測試程式碼會變成巨大的痛苦；另一種則是完全忽略它，痛苦就是自己的程式碼還是沒提升，而且天天有聲音在耳邊說BDD、TDD更好。對第二重境界的軟體開發人員，他們感到很不安全，軟體開發工作脫離了控制，開發次序被打亂，設計會在後續工作中不斷變化，一切不再是盡在掌握。而且，轉到BDD、TDD後的前幾次嘗試都不能帶來更高的生產率或者更好的結果，這不是個好東西。
同時，公司也不會接受。採納這些實踐會打亂公司的現有研發流程，讓可預測的管理變得更加困難，崗位分工的邊界被打破並不再清晰，部分員工會抱怨做了原來自己不需要做的事情，管理者在聽到研發人員說設計演化時會變得沒有信心，我只想要結果，你卻告訴我它會變。

尾聲
你還在寫程式碼嗎？你自認為處於哪個境界？最近幾個月你寫程式碼的能力有提升嗎？朝著什麼方向提升的？
據我的觀察，大多數公司的寫程式碼能力處於一種停滯狀態，很難想象在這種狀態下公司還能產出越來越優秀的軟體產品。你公司的寫程式碼能力是否處於停滯狀態？公司對寫程式碼能力的提升做過哪些努力？為什麼最終都收效甚微？

參考
好文推薦：看山還是山的人生三重境界http://hi.baidu.com/djkcn/item/f8a5cfef327a50265a2d643d
圖書推薦：《卓有成效的程式設計師》，對第二章加速的態度能很好的測試出你屬於哪個階段。
圖書推薦：《程式設計師修煉之道——從小工到專家》。
圖書推薦：《浮現式設計：專業軟體開發的演進本質》。