關鍵字: 軟體 模式
夜深了，也靜了。這是近些天來唯一一次晚上沒什麼事且過了零點還能抬起眼皮的乙個夜晚。最近在忙著設計新專案的一些關鍵點的架構，還忙著做乙個效能優先的記憶體快取的原型。自己給自己攬了一堆活，而且還有pl和外派同事（被pl任命為這個專案的負責人）給我的若干任務。時間很緊，不少的純體力工作，同時也感覺到了一些壓力。不過，好在那個記憶體快取還是讓我比較興奮，畢竟多少可以做點兒高階點的東西了。來這裡已經三個半月了，基本上已經適應了，包括工作節奏和職位職務。近期也不想再理會別的工作機會了，還是集中精力把手頭的專案做好。這裡的pl和manager還是不錯的，使我工作得比較愉快。
好了，介入正題，又說了很多題外話，但願螢幕前的那位還沒關掉頁面。
其實，軟體模式這個概念很廣。從純技術方面來講，有實現模式、設計模式和架構模式等等；從管理角度來說，有開發模式、過程模式以及交付模式等等。這裡主要還是**技術層面上的模式，管理模式也會稍微帶一點，畢竟我在團隊管理方面的經驗還不是很多。
先說說實現模式。所謂實現模式，就是我們在程式設計過程中的一些習慣和較好的實現方式。這種模式或多或少的會體現在團隊的一些編碼規範中。實現模式比較注重細節，它的核心思想是符合良好的編碼習慣和較佳的實現規範。目的是，使得團隊中的**風格開起來整齊劃一。這有五點好處：一、使得團隊成員能夠很容易的閱讀另一位成員的**，成員之間很容易進行交叉測試，leader很容易review**；二、在後期維護時會領會原有**的意圖，並可以很容易的繼續遵循一貫的**風格加以修改和重構，使得**甚至軟體的風格不受影響；三、可以讓新進入的開發者了解團隊編碼風格並快速融入；四、可以使團隊開上去更專業，而不是一群無組織無紀律的散兵。最後，有了這麼一套帶有良好實現模式的編碼規範，就可以是團隊在最基本的技術層面上達成一致，可以大大地提高工作效率，避免了無謂的爭論。良好的或者趨向良好的團隊都應該有自己的編碼規範，在書寫編碼規範時應注意因地制宜的吸收一些參考資料中的公認條款，而且可以根據具體情況加入一些團隊內部需要都知曉的原則。比如，我這次在撰寫編碼規範的時候就加入了很多關於oo的原則和實踐方法，以供開發人員參考。
下面來說說設計模式。希望提高自身技能的軟體開發人員都會主動地去接觸設計模式，因為那是n多前輩們總結出的軟體設計的最佳實踐參考。我相信真正的高階開發人員都至少讀過一本關於設計模式的書。當然軟體是善變的，設計模式也是如此。在真正理解和熟練運用設計模式之後，就可以根據自己的需要將原有模式進行演變，甚至創造出更好或更適合當時業務的模式來。設計是靈活的，設計模式只能最佳實踐參考。所以，我在這裡不想過多地說怎樣去用模式去設計軟體。因為設計是業務的跟隨者，是特定業務的技術級支援。沒有了業務依託的**，最多也只能算是個demo程式而已。現在越多越多的軟體和框架的目標都在向更好地實現特定業務轉移。這是乙個趨勢，也是人們對軟體設計的觀念的進步。計算機是服務於人的，軟體理所當然也是。所以在學習設計模式的時候大家不要恪守陳規，要學會為了目的而設計，而不是為了設計而設計。軟體是有生命的，至少我堅信這一點。既然有生命就需要成長，從呱呱落地到成熟穩健是需要有乙個過程的。所以，不要在一開始就試圖去想象軟體以後會怎麼變。因為在軟體行當裡，盲目的想象往往都不會成為現實。因而，與其費勁腦汁去過度設計，還不如集中精力優化現有的**。然後再根據需求的變化而動，只作足夠的，不做多餘的。
架構模式是更高階的話題。我主要說說我從事web系統的架構。現有流行框架，比如：struts2、spring和hibernate，都建議開發人員們把web系統的架構很為三層？我是這樣理解的：一、使軟體的職責分明，比如，展示層主要負責資料的頁面展示和使用者輸入的收集；持久層服務與資料儲存介質打交道，負責資料的儲存於重用；而控制層負責業務流程的控制、為展示層提供細粒度服務功能、對持久層進行合理排程等等，起到了承上啟下的作用；二、各層介面使軟體能夠以松耦合狀態呈現，能夠最小化改動帶來的影響；三、分層結構使得業務流程清晰，有助於非建立者對軟體的理解，有助於其快速了解軟體的執行機理。至於其他形式的軟體系統，比如：應用程式和c/s軟體，最終的架構目的都是為了「高內聚、松耦合」，從而使軟體各部件分工明確並能靈活應對變化。架構模式問題很高階，也很繁雜，暫且就說到這裡。
再說管理方面的模式，主要說說團隊管理。乙個的團隊的總體水平，往往不是體現在團隊成員的技術水平上，而是體現在團隊的整體運作上。乙個差的團隊，往往會計畫混亂、做事顛倒，經常加班但還是會拖延交付；而乙個運作良好的團隊，往往會計畫先於執行、措施先於變化，時不常的開會但是照樣能漂亮的按時交付。這取決於什麼呢？一、高效的開發方法；二、細緻的過程控制和管理；三、有效的溝通。當今的開發方法公認優秀的有幾種，包括：rup、scrum等等，其實都是在上述那三點上做文章，都是要高速迭代、持續整合，並與客戶保持高質量的溝通。但是，rup更注重規避各種潛在風險，而scrum更明確了去除雜念、按需而動。管理是一門太深的學問，團隊管理亦是如此，人的因素佔很大的比重。因此，軟體管理模式比技術模式要善變得多，也更容易失控。因而需要花費更多精力去把持。
好了，現在是將近凌晨三點，說的也不少了，眼皮也開始打架了。真誠希望能與各位同仁多多交流，互相取長補短，共同進步。希望大家能夠積極回帖，咱們一起討論「軟體中的模式」的機理和實踐。謝謝大家能夠看到最後。
軟體設計中MV模式的應用
軟體設計中mv模式的應用 平時在基於j2ee的軟體開發中，時不時的會用到struts框架，這個框架是mvc模式的經典之作。mvc模式介紹 model 作用是根據前台請求資料呼叫後台業務處理並返回處理結果 view 就是前台顯示介面 controller 控制就是聯絡model和view的作用，根據某...
建築和軟體中模式之異同
csdn的透明特別推崇 建築的永恆之道 認為從中探尋到軟體的永恆之道,並就 設計模式 寫了專門文章 探 尋軟體的永恆之道 其中很多觀點我看了很受啟發,以前我也將 設計模式 看成乙個簡單的解決方案,沒有從一種高度來看待 設計模式 在軟體中地位,下面是我自己的一些想法 建築和軟體某些地方是可以來比喻的 ...
建築和軟體中模式之異同
csdn的透明特別推崇 建築的永恆之道 認為從中探尋到軟體的永恆之道,並就 設計模式 寫了專門文章 探尋軟體的永恆之道 其中很多觀點我看了很受啟發,以前我也將 設計模式 看成乙個簡單的解決方案,沒有從一種高度來看待 設計模式 在軟體中地位,下面是我自己的一些想法 建築和軟體某些地方是可以來比喻的 特...