何以證明你的設計優秀？

我想很多人都飽受過糟糕軟體設計的痛苦，是以心裡總有一股氣，自己一定要做一個非常優秀的設計。至少我是這樣的人。

近日公司的一個項目進行TR1評審的時候，在技術方案的評估文檔中，我發現其第一項列出的便是上一個版本存在的設計缺陷：

1. 産品之間複用隻是停留在代碼級别
2. 子產品代碼不夠獨立，後期不能複用
3. 子產品代碼不易擴充現在的新功能

由于是公司産權産品，其具體的内容不便詳說。幸好我們隻需要關注一下其中的重點。對，就是複用！

當然了，這份技術方案中，剩下的就是自己如何解決所有問題，如何提取可供複用元件，如何架構一個好的系統。姑且不談對本系統的設計如何，我們跳出來看看我們在做一件什麼樣的事。

否定 --> 肯定 --> 否定

第一個否定，是我們在“否定”上一個版本，“肯定”是我們在肯定自己的版本，最後一個“否定”，是别人來否定我們的版本。不管我們意願如何，這幾乎是很多公司中必然的境況。

再來看看我們所希望的：我們希望我的設計足夠優秀，是以在這個産品的下一個版本的時候（或者維護階段），他們不會抨擊設計的缺陷，并且能發現，

1. 其架構的擴充性非常好，
2. 可重用的子產品也非常多。
3. 原有系統的穩定性值得肯定。

可是，事實總不如我們想象的那樣。為什麼呢？

古人有一句非常有道理的話：己所不欲，勿施于人。什麼意思呢？你希望别人來稱贊你的設計，将來來複用你的子產品。那麼你這麼做了嗎？你願意這麼做嗎？你自己都不做，何以希望别人來做呢？

是的，作為設計師的你來說，設計的根本目的是解決問題。解決業務上的問題，解決原有系統的問題。那麼你的設計才會被認為是有用的。至于設計是否是優秀的，事實上，誰也沒把握。未來的事，誰知道呢？

如果隻是來證明你有足夠能力設計整個系統，我相信你一定早就擁有了。可是說到優秀，卻又一個标準問題。這和編寫代碼不一樣。我能編100000行代碼，你一定會認為我很強。我把整個系統的大部分全都實作了，你一定會将我捧到非常高的地步。

可惜，你要考慮的是，你不再是在編碼，你是在設計。那麼到底設計的衡量标準是什麼呢？設計的标準很多，可是我相信有一個非常重要：

用最少的代碼完成最多的事！

這和程式員的宗旨看上去完全是反其道而行之的。為什麼呢？

1. 代碼越少，複雜度越低，所隐含的BUG也會越少。
2. 代碼越少，編寫成本也越少。生産率提高了，你的待遇也就提高了。
3. 代碼越少，才真正證明了設計的重要性。如果設計就是讓系統複雜話的話，要設計做什麼？
4. 代碼越少，維護越簡單

代碼的大量減少，其實是意味着穩定性的子產品在持續增加。這些穩定性的子產品，才是設計的真正精髓所在。那麼，這些穩定性的子產品如何來呢？

一種選擇是你來完成這樣的子產品，讓别人調用。

另外一個選擇就是你直接用别人的子產品。

當然了，這裡有一個非常有意思的地方。你或許會說，原來那麼差的設計，我怎麼使用？隻能等我來設計了。可是我要說，如果你眼裡隻有第一種選擇，那麼你對别人來說，也不會有第二種選擇。或者幾乎可以肯定的是，你的設計，沒有人會願意複用。他們總可以發現你的設計中有足夠多的缺陷來讓他們放棄！就像你現在一樣。

這個不是簡單的所謂态度決定一切的闡述。這之間幾乎有着必然的聯系：

1. 你發現不了别人系統中可以複用的，那麼你在複用方面的意識就沒有提升到足夠的高度
2. 沒有足夠的高度的複用意思，編寫不出足夠可以複用的子產品
3. 如此循環。抛棄式的設計隻是會證明一點，又有一個存在衆多問題的産品出生了。