《軟體設計精要與模式》讀書筆記(一)

     最近在學習設計模式方面的內容，買了幾本關於設計方面的書籍，這兩天在看《軟體設計精要與模式》，本書是部落格園開發人員征途系列、由張逸所著。

 

     第一章：設計之道。

     1.1 計劃的設計和演化的設計

     其實以前自己並沒有意識到設計還是分方式的，這裡作者提出兩種方式：計劃的設計和演化的設計。我個人認為對於設計的取捨可以根據軟體的開發模型來決定，比如採用瀑布模型使用計劃的設計比較方便(因為需求變化較小或者說需要擴充的可能性不大等)，採用螺旋形模型/迭代模型可以採用演化模型。這裡有些人可能會有些疑問，到底是先由設計還是先確定模型，個人認為是先確定模型（因為模型是項目開發的整個過程，而設計只是裡面的一個環節）。其實無論設計或者開發模型都是以需求為驅動的。這裡我需要引用作者“拷問自己”的幾句話：

     “我對客戶的需求都理解了嗎？”

     “我能確定客戶的需求不再變化嗎？”

     “我設計的軟體架構真的能滿足需求嗎？”

 

     1.2 架構設計的標準

     本節可以作為架構設計的參考：

     （1）程式組織(Program Organization)

     （2）資料設計（Data Design）

     （3）安全性（Security）

     （4）效能（Performance）

     （5）可擴充性（Scalability）

     （6）可靠性（Reliability）

     （7）可用性（Usability）

 

     1.3 過度設計，還是簡單設計

     本節我引用一句話來概括吧：“然而簡單並非意味著簡易，所謂‘大道至簡’，自簡入繁並不難，化繁為簡才真正需要大智慧。”

 

     1.4 需要設計模式嗎

     廢話啊，不然我還看這本書幹嘛？

     需要提醒的幾點：“重要的不是你熟記了多少個模式的名稱，關鍵在於付諸實踐的運用。”

     “言必談‘模式’，並不能是你成為優秀的架構師。真正出色的設計師，懂得判斷運用模式的時機。”

 

     1.5 重構是必然的

     看看《重構--改善既有代碼的設計》吧，最少偶是買了一本的，但是推薦在項目後期有時間改進時買，感觸頗深啊。

 

     1.6 UML 重要嗎

     作者這裡提到“演化的設計降低了UML 的重要性，按照極限編程的開發原則，我們僅需要對眼前的需求進行編碼、測試，然後重構”，其實如果真正按照演化的設計，那麼UML 的設計是否會處於裡面的一環？我們這裡談的是設計，幹嗎非要把極限編程的開發原則作為演化的設計拉進來說？UML 是設計的一種實現。如何去用UML 才是我們需要著重考慮的問題，而不是是否採用極限編程！

 

     1.7 測試驅動開發

     “‘大膽設計，小心求證。’測試驅動開發的精髓。”      “測試驅動開發的主要精神可以概括為‘測試先行，快速反饋’。”

     測試驅動開發，真正能夠做到的有多少？雖說是個好東西，但是要去做還需要時間。

     

     計劃的設計與演化的設計“它們非但不會在戰場上成為敵我雙方，反而是相輔相成、並行不悖的協作部隊。當我們面對一個大型系統的時候，‘分而治之’是我們唯一能夠選擇的解決之道。如何‘分之’，正是計劃的設計所需要關注的，解構出系統的層次、構成及其之間的關係，將整個系統分為能與外界通訊，同時又獨立為一體的不同模組。如何‘治之’，則可以應用演化的設計，以簡單、適用作為設計前提，從不斷的演化中創造客戶所需。”這裡我有些疑問，兩種設計真的能夠完全並存嗎？或者是過程局部並存？如果將設計作為一個流程，那麼是採用兩個流程交替還是互相制約？那種設計為主？這裡個人疑問太多。