回頭審視一下傳統的“軟件工程”過程。在軟件工程中，十分強調“流程”和紀律，追求軟件過程越是“自動化”越好。希望需求是被穩固下來，事先就做好，可以作為“原料”輸入到一連貫相互獨立“工序”中，通過控制開發人員在每個工序中的作為，使得產品嚴格按照預先期望的模子生產出來；希望開發者都安分守己地努力，所有的溝通和交流最好都文檔化，以分清責任減少爭論，同時以文檔為驅動，規規矩矩按部就班地做上一個流程的文檔給自己規定好的事情。嗚嗚，正在焦油坑里掙扎的猛犸象還少么？
3、要面向代碼
再強調一遍：源代碼就是設計！
即使在軟件工程中，這一點也是不可否認的（雖然不被承認）。很多人認為，軟件設計是指編碼之前的“概要設計”和“詳細設計”，代碼只是“實現”，只是個體力活兒。但是，代碼卻是軟件設計最真實、準確、有價值的表現。在編碼前，再好的構思也只是“預設計”，是沒有被驗證、沒有被認可、沒有被賦予現實意義的空想�！邦A設計”再好也并不是設計，在所謂“概要設計”和“詳細設計”階段通常不乏玲瓏的構思，但是由于輕視了代碼（而去重視那些只是臨時使用一下的設計文檔），往往能“化神奇為腐朽”，況且沒有在代碼中被驗證與整個系統的協調性的神奇構思，又有什么值得稱道的呢？
所以，我們的設計應該面向代碼，而不是輕視它。有什么好的設計構思，最好趕緊在代碼上表達出來，并很快地驗證這個構思是正確的，是與整個系統相容的，而不是把很多構思都堆積在“設計文檔”中，掩蓋了矛盾和錯誤，并在編碼的時候把它們放大。
設計面向代碼，應該從測試用例出發。比較好的方法是采用“測試驅動開發”（TDD）（源自《測試驅動開發》，Kent Beck著）的方法，直接面對需求，把需求用測試用例準確地表達出來，所有的設計都從測試用例出發，這樣我們的設計就能夠更貼近真實的需求，直接將需求和代碼聯系起來，減少了中間所有的不確定的環節。明確的需求都是可以測試的，編寫測試用例的過程其實是一個促使開發者對需求真正認識的過程，這也是尋找好的軟件設計的出發點，實在不應該忽略或輕視。并且有了準確的測試用例做保障，我們在改進過程中隨時都可以驗證所做的修改的正確性。
設計面向代碼，要求在變化中保持代碼“健康”。代碼是在開發的過程中不停地被改變的，但是隨時要保持代碼的“健康”。這種改變不是往舊墻上刷新粉，整個過程也不是“code and fix”，特別是軟件開發的后期，最好不要有顯眼的“補丁”，而應該針對任何變化，最好把所做的修改或加強融入到現有的設計中，使之和諧不留痕跡。至于什么樣的代碼才是“健康”的，我想這是一個值得展開討論的話題。
設計面向代碼，切忌盲目復用。軟件開發為了提高資源利用率和開發效率，希望能夠在新的應用中運用已有的設計成果，最大限度地實現軟件復用，這種愿望可以理解，但復用一定是有條件有限度的。復用別人現成的代碼，天然受到別人設計的制約，要想復用，首先要充分了解別人的設計，特別考察它的“通用性”，由于不是為我們的應用定制的，所以我們的設計要遷就這種“通用性”，這種遷就是相當有風險的，很可能使我們的設計變得僵硬。不記得哪位高人曾經說過“復用只是神話”，我覺得是很有道理的，采用別人的代碼的當時是省心省力，但是后期的維護似乎還有漫長的痛苦等著你。再者，應用是有差異的，哪怕相同的應用，削足適履而不是根據腳的尺寸去做鞋，是不可取的。
4、要重構
不知道有沒有特別厲害的軟件設計高手，可以將好的設計一步到位地呈現出來？不過我想對于大多數人來說，設計并不是一蹴而就，而是循序漸進的。最初的設計可能與最終的設計相差巨大，這是再正常不過的事情。重要的是軟件設計要朝一個好的方向演進，重構的過程就是演進的過程。重構是對現有代碼的設計進行優化和改良，《重構：改善既有代碼的設計》（候捷等譯，中國電力出版社出版）一書指出了存在于代碼中的常見的22種“壞味道”，并針對性地提供了一些很中肯實用的重構手法，很值得借鑒。其實重構應該是軟件開發者的一種自覺習慣，重構手法也是經過長期實踐經驗已經潛移默化了的。
最初的設計總是丑陋的，重構是使“丑小鴨”變“白天鵝”的必要手段。哪怕再巧妙的構思，也會有制肘，哪怕再謹慎的防備，也會有疏漏，所以設計的雛形總會有這樣那樣的不足，或多或少地脫離現實問題。這些不足的地方都是可以改進的，關鍵是有意識地去尋找出這些不足，并糾正它們。因此，我們可以為了更緊密地貼合需求，放心地讓我們最初的設計粗糙一些，我們總可以用重構的方法改造它。
好的設計是不斷地重構才顯露出來的。設計應當是從需求出發，做出一些“粗糙”的解決問題的方案，然后根據經驗對該方案不斷進行改進、完善，使其越來越靈活，越來越趨于穩定，得到的，自然就是好的設計。而不是從經驗出發，先想象出一些“玲瓏”的構思，然后修修補補，使其符合我們的需求。前一種方式是借鑒經驗，后一種方式是強求經驗；前一種方式是慢慢演化水到渠成，后一種方式是急于求成生拉硬拽；前一種方式靈活，有更進一步優化的空間，后一種方式呆板，越修補越走樣。優劣自現。
設計過程中要“兩頂帽子”輪流戴�！皟身斆弊印笔荎ent Beck為了形象地描述重構過程中的兩項任務而引入一種比方。一頂帽子是改善現有設計，另一定帽子是增加新功能。提醒我們，任何時候應該只做一件事（除非你喜歡把兩頂帽子摞起來戴）：改善現有設計的時候，就立足于現有設計，用現有的測試用例可以很方便地驗證改善的正確性；在增加新功能的時候（容納一種新的需求），就充分信任現有代碼的正確性，而立足于該功能，關注在新增功能的測試用例上以保證測試用例的正確，同時修改或增加代碼使得所有測試用例（包括新增的）通過。如果覺得新增了功能設計被污染了，別急，測試用例通過后可以換戴另一頂帽子。
5、要新陳代謝
軟件設計不是一勞永逸的，技術更新很快，軟件設計要為應用服務，就要適應新的技術條件，新陳代謝。軟件設計本身要有開放、靈活的架構，而開發者也要有與時俱進、開拓創新的精神。
軟件設計要吸納需求的變化，不斷適應新的環境。軟件是服務于應用的，應用的背景發生了變化，軟件必然要跟著變化，所以好的軟件設計要有在變化中存活和發展的生命力，這就要求軟件本身的架構是開放、靈活的。軟件架構是在軟件在開發的過程中，不斷納入新的需求，軟件設計自身不斷地進行調整，到最后穩定下來的部分。所以軟件架構是在需求不斷變化的打磨下進化而來的，是軟件設計的骨架。只有來自于實際應用的動態的軟件架構，才方便改變自己以適應應用環境的改變。
開發者要不斷學習，提升自己的眼界。軟件應用的領域范圍廣泛，軟件技術的發展也朝不同的方向在不斷地提升；軟件開發的本質規律還沒有完全大白于世，軟件業界存在著眾多的思想流派，不同流派正對一些技術方法會有一些爭議。而開發者往往只能集中精力于某一特定的方向，而對其他方向的發展比較生疏；或者開發者只信奉一個思想流派，對其他不同的意見不屑一顧——這些都是眼界受局限的表現。開發者應當了解其他領域的一些基本情況，其他流派的一些基本主張，這有益于反思自己開發中的一些困惑，啟發自己的思路。
開發者還要保持開放的心態，要革故鼎新。好的軟件設計，要經受住時代變遷的考驗和用戶的挑剔。所以設計者要有開放的心態，虛心接受用戶的批評和建議，并積極改進軟件的設計以滿足用戶的要求。特別是對于新的有用的技術元素（如新的軟件架構理念、新的網絡技術、新的數據庫技術、新興的編程語言等），要有一定的敏感度，要從中吸取積極的啟發，來加強軟件設計的技術跟進。對于一些不合時宜的設計，要更新換代，始終保持軟件設計與時代同步。
開發者還要有一點完美主義情節。軟件設計是軟件開發者心血的結晶，是開發者思想的表白，所以開發者往往對自己成功的作品愛不釋手。就像母親總覺得自己的孩子最棒一樣，開發者會覺得自己的設計是最好的。應該對那些傾心盡力做出軟件設計的開發者致以崇高的敬意！但是也有必要提醒他們，要理性客觀地對待自己作品的不足，還有不完美的地方。這些話，特別需要善意地對那些對現在的“設計”自我感覺良好的人說。相當多的開發者，長期在設計的荒原，已經習慣了在蕭瑟的秋風和飛砂走石中緝拿隱藏在荊棘中的bug，還從來沒有想象過軟件設計其實可以做得更好，沒奢望過還有鳥語花香的春天。該醒醒了，不要安于在黑暗的屋子里窒息的命運！
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
