心得體會（2008/06/30-2008/07/04）-优快云博客

本文链接：https://blog.youkuaiyun.com/nanqing/article/details/2613791

這個禮拜因為底片新的需求還沒有送過來，沒有新的開發任務，就將整個系統的架構重新設計了一下，方便未來新增功能的擴充以及后來人員的維護。整個系統還是以三層架構為基礎，但在軟件設計模式上有了更新，主要是秉承軟件開發“高內聚，低耦合”的思想，以面向接口編程，采用了抽象工廠的設計模式。

由于前段時間遇到技術上的瓶頸，所以決心突破。對我來說這是第二次了。記得第一次突破是以提高代碼編寫質量為目標。Eg:分層架構；盡可能多用存儲過程；每個控件的命名規則；每個開發頁面以及存儲過程多要注釋作者、日期、功能說明諸如此類的開發細節。通過實踐開發，使我在代碼編寫技術上有了很大的突破。對于第二次的瓶頸，也就是前段時間通過底片開發中遇到的。就是對于一個系統它會隨需求的變化而作相應的修改，一個系統的架構如果設計的很糟糕，那么修改任務務必很大，因為糟糕的系統設計會“牽一發而動全身”，也就是通常所說的修改一個地方的功能，務必也要修改其他相關頁面的功能，用專業術語來說，就是系統模塊的耦合性高，各模塊產生強依賴。對我上面所說的，就是我之前開發底片過程中遇到的困擾。從系統的長遠來考慮，很不劃算的，原因有二。一是隨需求的變化，務必會修改外觀層相關的代碼，這樣隨之而來的問題就是系統的穩定性不夠好，用戶會因系統穩定性方面的顧忌會用的小心翼翼，甚至可能在將來會摒棄。二是對于后來維護人員會造成很大的負擔。即使是一個出色的開發人員，了解并熟悉別人的系統也要花費很長的時間。對于上面所面對的實際問題，所以我決心改變很多開發人員所面臨的困擾，并將我的心得分享一下。

每一個系統最大的挑戰不是在哪一功能方面的實現，而是面對需求不斷的變化。變化有時候無窮盡的，對于項目開發就在反復修改更新中無限期地延遲交付的日期，這樣長時間地進行下去有可能會和End User產生矛盾。對于DeadLine的壓迫，上面的主管也會有很多微詞，但最大的傷害是使自己在軟件開發過程中喪失信心，甚至會迷失自己在軟件領域里面的方向。也許很多開發人員遇到過這樣的情況，延遲交付的日期這并不是自己在工作中偷懶。當然經理從管理的角度來考慮，他會對用戶每一次需求進行管控，來降低上面所述的發生幾率。但最根本的解決方案就是靠我們自己，設計出優秀的系統架構模式，雖然優秀的軟件設計模式不能解決上面所有的問題，但從根本上降低了上面所說問題發生的幾率，何樂而不為呢。

在优快云中了解到，PetShop系統被很多專家大佬奉為軟件設計模式的經典，甚至看到一些用人單位在招聘的要求中也提到熟悉PetShop系統設計模式的將優先考慮。PetShop的設計模式，我也正在學習中。對于底片系統中單一的抽象工廠模式的應用，也是我剛剛入門而已。由于能力有限，PetsShop的設計模式講不了，那就以我的底片系統設計模式舉例。

底片系統以面向接口編程，采用了抽象工廠的設計模式。實現原理是將每一個具體實類封裝成獨立的接口，，并繼承該接口。在接口中只定義實類的方法，具體方法不需要實現。具體實類之間的調用通過各自獨立的接口來實現，這樣大大降低了模塊間的耦合度。然后再新建一個工廠接口，定義上面具體實類接口的方法，再新建工廠接口的具體類，并在工廠接口的具體類中實現每個具體實類接口的方法，在方法中調用相關接口的具體實類。這樣一個抽象工廠模式就初步建好。現在要考慮的就是外觀層對接口的調用。如果還是按照我們之前調用具體實類的對象，

eg: Class a = new *.*.Class(); a.m_Username = this.txtUserName.Text.Trim();……. 那么每個相關的頁面都有這樣一段代碼，那之前接口的設計就變得毫無意義。設計接口的意義就是在每個頁面調用統一的接口實例，這樣我們調用的只是接口中的方法，而接口中的方法又沒有實現，這樣就增強了模塊的內聚度。也就是說，開發人員每次要添加新的功能只要在上面具體類中實現，再在接口中定義這個功能的方法就ok了，不需要修改先前和它相關連的功能。這樣每次都需求就相當于在接口中定義這樣的方法就好了，對于外觀層的代碼的修改也就少了又少，在這里就解決了系統的穩定性，如此簡單，比之前考慮到地方要少了。還要注意，不能在外觀層的代碼中出現向上面用New來創建具體實類的對象，這樣會很愚蠢的，我們用同一的接口來調用就行了，但你會提到，接口也要實例化用New定義才能調用相關方法呀，為了避免出現在外觀層代碼中有New，在這里有兩種方法可以解決。一是應用反射技術，將它在Web.config中配置就ok了，在這塊我沒有深入學習，只是了解。二是我應用到的，就是定義一個新類，在這個類中集中定義許多接口的實例，然后讓每個外觀層繼承這個類就ok了.

Eg:

public abstract class UnitManager

{

#region 接口實例化

public static INeagaveFactory factory = new NeagaveFactory();

public static INeagaveDataFactory dataFactory = new NeagaveDataFactory();

#endregion

public UnitManager()

{

// TODO: 在此加入建構函式的程式碼

}

這樣底片的模式設計已經OK了，可以應付將來不斷變化的需求，在這里我也是剛剛入門，知道設計模式博大精深，一個系統的設計要有很多種模式組成，至少被奉為經典的PetShop是這樣的。還需要經過不斷的實踐，才能總結出自己習慣的設計模式。

現在第二個技術瓶頸突破后，感覺軟件開發很美好。覺得一下子提高了不少，在此總結出一個系統的開發每一塊所占的比例，系統架構和模式設計占40%，資料庫的創建以及表結構的設計占30%，而我之前側重的代碼功能也不過只有30%而已。當然軟件開發不是靠一個人去完成，雖然一個人可以開發一個系統，但想想就知道那系統是多么的小。從長遠考慮是不切合實際的，軟件開發需要團隊，一個優秀的系統也需要團隊開發。在优快云中大佬們提倡的“快樂編程”也是從團隊開發中獲取的。所以在今后的開發中我希望我們團隊能夠實現聯機多人開發，實現每個伙伴技術資源的整合，相互吸取各自的長處，從而開發出更優秀剛強大的的系統。