關於程式碼即設計的隨想

記得大三的一堂軟體工程課上，留洋歸來的老師說，編碼在國外已經是藍領了，想當白領，一定要做設計。根據這種分法，很不幸，我一直都是藍領。一直以來，有個問題困擾著我。設計是什麼？或者設計包括什麼？如果把編碼看作是工廠車間裡的製造環節，為什麼工廠加裝置加人就能顯著的縮短生產週期，而在軟體開發過程中，多加幾個碼農有時候甚至會適得其反？而且如果生產線上經常出錯的工人很快就下崗了，但是經常導致編譯失敗的碼農卻並不太擔心被抄魷魚。就像Fred Brooks所說，生孩子要懷胎十月，找來十個孕婦能一個月生出一個孩子？

我們先回顧一下軟體工程的兩個重要的模式，瀑布模式和敏捷模式。瀑布模式的慣用流程是由SE/DE分析設計並形成文件，然後把文件交給碼農編碼，最後碼農把最終的軟體交給測試人員進行測試（一般是黑盒測試）。這樣的機械分割的問題至少有兩個。首先，冷冰冰的文件言未盡意，再加上人的變化，導致資訊的丟失甚至誤解。其次，設計由於缺少驗證，而且需求的不斷變化，編碼時甚至測試時才發現設計必須要修改。編碼這種對設計的反作用直接的後果是設計文件往往跟程式碼風馬牛不相及。

於是各大門派的大牛們痛定思痛，放下門戶之見，集思苦修，終於練成敏捷，江湖為之一振，蝦米們競相轉投敏捷門下。敏捷一掃瀑布的文件化和流程化的僵硬死板，展現出擁抱變化的靈活快速。敏捷模糊了設計、開發和測試的界限。從敏捷背後的機制來看，程式碼即設計雖然“猶抱琵琶半遮面“，但好歹”千呼萬喚始出來“。

不同於傳統工業的設計和生產之間的關係，軟體設計和編碼之間的關係非常緊密。現在已經有越來越多的工具，雖然還不夠完美，但是可以實現UML圖和程式碼正向和逆向的轉換。從某種程度上看，設計文件和程式碼也許是等價的。從程式碼即設計的角度，設計和編碼是同一頭大象兩條不同的腿，而構造和測試則是另外兩條腿。也就是說，設計包含傳統的設計、編碼、構造和測試。傳統的設計在其中更多是頂層設計，程式碼則是完備的設計清單，構造和測試是為了驗證和優化設計。整個設計過程是一個螺旋上升的環，測試的結果會促使設計和程式碼的修改和優化。程式碼即設計，可以很好的解釋開頭提出的問題。編碼並不是工廠裡的製造環節，而是設計環節。設計中出現問題是很常見的情況，只要及時改正就不會出大簍子。

在剛接觸程式碼即設計的時候，經常出現一知半截就滿腔熱血開始踐行。很容易把程式碼絕對化。很瀟灑的拋開文件和設計，直接編碼，眼前是長髮飄飄的Richard Stallman坐在電腦旁不斷敲鍵盤的情景。走了各種彎路而疲憊煩躁時，回過頭來斷言，程式碼即設計不對。程式碼即設計不併是說不需要畫UML圖，而是說程式碼也是設計的一部分，好吧，是最重要的一部分。設計拼圖中還有另外三個部分。

程式碼限設計要求人員的融合，而人員的融合又促使組織結構的調整。就像程式碼架構的調整無異於涅槃一樣，組織結構的調整也是舉步維艱。除非嚴重的危機發生，調整很難執行。