在2023年，jack w.reeves發表了一篇名為：code as design的文章，這篇文章可以在《敏捷軟體開發 原則、模式與實踐》一書的附錄中找到。
這是幾近20年前的文章，但時至今日，類似的爭論仍未休止。
好像是在《軟體架構設計》裡，在討論架構設計時，作者就點了一句：這總不能說是設計就是編碼了吧。
解釋這一問題並不複雜，但需要用到一點辯證法。
我們可以講：設計即是編碼，也不是編碼。
在別的文章裡我們曾經提及，軟體是一種固化的思維。
從這一角度看，軟體構建的核心步驟只有兩個：一是明確固化什麼，二是對思維進行固化。
設計和編碼確實都屬於第二步，因此說設計即是編碼也沒什麼不對，他們本質相同。
但分類的時候，有乙個很有趣的現象就是：
區別個體差異的往往並非該物種最本質的特徵，而是某些微小差別。比如區分不同人的，並非心臟，神經系統，而是膚色，臉型等等。
當軟體出現之後，人們定義設計，編碼這樣的名詞時，所想到的估計並不是他們本質上一樣不一樣，而是他們那裡不同。
設計和編碼的相同點在於他們本質相同，不同點則是他們考慮的問題層次不同。
也就是說考慮架構和考慮某個函式的實現時，本質並無差別，有差別的只是層次。
從這個角度看，講設計不是編碼也沒什麼不對。
如果我們認為思維固化過程中確實需要層層分解，而這種層次是連續的，那確實很難講清楚，從那個層次開始就不是設計，而是編碼了。
所以這種爭議本身，起源於詞彙自身的定義，並不是特別的有意義。
當我們不需要努力區分設計和編碼的邊界時，盡可以認為他們是同一工作的不同層次。
但這樣給設計留下了個難題，那就是究竟應該停在那個層次才最為合適--這並不是能夠簡單回答的問題。
最後說一句：設計處的層次較高，但服務的物件卻是更底層的編碼，畢竟只有最終的**才與軟體等價，只有好的**才代表好的軟體。
只是現實中這種依賴關係往往被倒置，變成了設計指揮編碼。
理想流 + 軟體 = 《完美軟體開發：方法與邏輯》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和邏輯推演本質，追求真理。
關於編碼設計
編碼設計在大型專案裡常常被搞得異常複雜，大多數是人為因素增加了複雜度。小型專案則往往走向另乙個極端，忽視編碼設計，在後續維護時發現資料隨著時間的推移越來越凌亂，無意中增加了維護成本同時介面友好度大幅下降。大多數情況，往往是因為沒有專門負責呈現和分類的字段，所以才費盡心機設計編碼，以便讓其擔負更多的任...
Ogre 編碼 設計原理
編碼 設計原理 coding design philosophy 英文原文 編碼 設計原理 類的繼承 這裡有一張表 顯示了類的繼承關係,也許可以一些概念更清晰些 雖然ogre是乙個場景圖表,但是它的光源,相機和一些東西並不繼承自節點.這些東西並不需要掛接至場景節點 雖然他們可以掛接 自定義物件 當建...
Ogre 編碼 設計原理
編碼 設計原理 coding design philosophy 英文原文 這裡有一張表 顯示了類的繼承關係,也許可以一些概念更清晰些 雖然ogre是乙個場景圖表,但是它的光源,相機和一些東西並不繼承自節點.這些東西並不需要掛接至場景節點 雖然他們可以掛接 當建立重複使用的自定義物件時使用movab...