本文節選自雲風的博客上近日的兩篇文章：《好的設計》和《C 語言對模塊化支持的欠缺》。
由於最近幾年用的主要開發語言是 C 和 lua 。那麼也打算以此為基礎寫。假定讀者至少有不錯的 C 語言基礎了。我真正想談的是，如何把一個軟件很好的構建起來。到底需要做些什麼。從實現層面看）怎樣才是好的軟件。
那麼有一個重點問題，也是老問題，怎樣才是好的設計。
好的設計，必然是容易實現的。它可以很精巧，但不能難以理解。
太陽底下無新鮮事。軟件行業已經發展了這麼多年，你想到的東西，肯定有人都想到過了。
每個軟件也都有它的生命期，我們只要在它的生命期內完成它的使命就行了。軟件往往需要盡快的投入使用，然後在使用中演化。這個演化最大可能並不依靠你一個人的力量去推動。隨著參與的人增加，人和人指開發人員）的共性就會減少。每個人都看得懂可以充分接受，軟件才不容易向壞的方面演化。
我們常常談模塊化，談高內聚，低耦合。
本質上，就是如何管理復雜度。如何把一件很難的事情開發一個軟件），分解成小問題，分而治之。
這些小問題之間的千絲萬縷的聯系，是設計人員面臨的最大難題。
有些原則聽起來不錯，但是堅持起來很難。
比如，讓模塊的輸入輸出沒有副作用。你能讓你的模塊每個輸入對對應著唯一輸出嗎？
又比如，讓模塊層次化。如果 A 模塊依賴 B 模塊，B 模塊依賴 C 模塊。一旦出現這個狀態，你能保證 A 模塊絕對和 C 模塊隔絕嗎？更有甚者，讓三個模塊循環依賴這種更糟糕的事情也並不鮮見。
抽象是個好東西。但借助不斷的抽象，問題不斷的包起來，演化成新的巨無霸，顯然會讓事情更糟。雖然最終可能真的能像搭積木一樣去組裝軟件了。或是雇傭更多的程序員填表單一樣的工作，相互不需要對方在做什麼。但是，軟件性能卻下降到了不可以忍受的地步。bug 也隱藏的更久，更不可收拾。
好的設計，必須對問題有足夠清晰的理解。有如庖丁解牛一般，把整個問題劃開，在最薄弱的地方分離。其實，做到這點，也就夠了。
解決這些問題，其實跟語言無關。語言之爭是沒有多大意義的。如開頭所說，把設計做好，模塊之間的關系，用足夠簡單的方式就能描述清楚了，大部分流行的開發語言都能做到。
用 C 來實作，而沒有用它的近親 C++ ，也是為了避免狹隘的爭議：我們該用這個特性嗎？該用那個特性嗎？這個形式做是不是好點？那樣會不會有更好的性能？
所謂開發效率，對於個人來說，語言之不同，是會有很大差異。但是那是實現層面的差異。對於完成設計，這個過程，效率和所用語言無關。
實現的階段，程序員可不可以開心的放心的去完成那些接口，這就是衡量設計好不好的指標了。這個時候，一個高開發效率的語言有優勢更少的代碼量），一個容易掌握的語言也有優勢可以讓更多的人參於而少犯錯誤）。
我相信，軟件做到後面，設計人員不需要親自寫太多代碼。雖然我現在每天還是大量的寫，也並不覺得枯燥。
事必恭親是不好，但並不是說，你給實現人員足夠信任就可以放手的。真正讓你放手的只能是，你做出了好的設計，無論是誰，他也寫不壞它。這時，是你樂意自己寫，還是多找幾個同學幫忙寫，已經不重要了。
