【設計 = 編碼】 VS 【設計 ≠ 編碼】

在1992年，Jack W.Reeves發表了一篇名為：Code as Design的文章，這篇文章可以在《敏捷式軟體開發 (Agile Software Development) 原則、模式與實踐》一書的附錄中找到。

 

這篇文章的核心觀點是：編碼也是設計，而軟體開發中與建築行業中的施工所對等的工作，已經被編譯器代理了。

這是幾近20年前的文章，但時至今日，類似的爭論仍未休止。

好像是在《軟體架構設計》裡，在討論架構設計時，作者就點了一句：這總不能說是設計就是編碼了吧。

 

解釋這一問題並不複雜，但需要用到一點辯證法。

 

我們可以講：設計即是編碼，也不是編碼。

 

在別的文章裡我們曾經提及，軟體是一種固化的思維。

 

從這一角度看，軟體構建的核心步驟只有兩個：一是明確固化什麼，二是對思維進行固化。

設計和編碼確實都屬於第二步，因此說設計即是編碼也沒什麼不對，他們本質相同。

 

但分類的時候，有一個很有趣的現象就是：

區別個體差異的往往並非該物種最本質的特徵，而是某些微小差別。比如區分不同人的，並非心臟，神經系統，而是膚色，臉型等等。

 

當軟體出現之後，人們定義設計，編碼這樣的名詞時，所想到的估計並不是他們本質上一樣不一樣，而是他們那裡不同。

 

設計和編碼的相同點在於他們本質相同，不同點則是他們考慮的問題層次不同。

 

也就是說考慮架構和考慮某個函數的實現時，本質並無差別，有差別的只是層次。

從這個角度看，講設計不是編碼也沒什麼不對。

 

如果我們認為思維固化過程中確實需要層層分解，而這種層次是連續的，那確實很難講清楚，從那個層次開始就不是設計，而是編碼了。

所以這種爭議本身，起源於詞彙自身的定義，並不是特別的有意義。

當我們不需要努力區分設計和編碼的邊界時，盡可以認為他們是同一工作的不同層次。

但這樣給設計留下了個難題，那就是究竟應該停在那個層次才最為合適--這並不是能夠簡單回答的問題。

 

最後說一句：設計處的層次較高，但服務的對象卻是更底層的編碼，畢竟只有最終的代碼才與軟體等價，只有好的代碼才代表好的軟體。

只是現實中這種依賴關係往往被倒置，變成了設計指揮編碼。