熟悉的陌生人——軟體工程
去年暑假到現在是一個蛻變的過程！從軟體工程到UML到設計模式再到三層架構(其實這些都屬於軟工的範疇)，這是一條充滿艱辛，充滿曲折的道路，一路走來，感觸頗多。
再次接觸軟體工程，讓我覺得既熟悉又陌生。造成這種讓人糾結的狀態只能怪自己當時太無知。沒有好好聽大學老師講課。不過也不必太自責，大家也都知道現在中國的教育現狀。我想如果我當時好好跟著任課老師學，對軟工認識的程度肯定也無法跟現在相比。很慶幸自己選擇一直走下去。這個決定可以說是我長這麼大最正確的一次！
軟體工程
軟體工程，可以說是一門博大精深的學科。如果要用一種武功來比喻軟體工程，那麼我感覺也只有少林寺的《易筋經》能夠體現出它在軟體界的重要地位了。軟體工程貫穿整個軟體開發的始終，從設計到編碼到之後的測試發布以及後期的維護，都離不開軟體工程的思想。軟體工程其實就是一種工具，將軟體開發工程化，用科學的方法分析設計軟體，為軟體開發指制定合理的計劃，最大限度的保證軟體可以按時保量的完成。軟體工程是一門需要終身學習的課程。隨著以後不斷的積累對於軟工的認識會慢慢的加深，繼續努力吧！
UML
UML是軟體開發過程中一個非常重要的環節，可以說UML是軟體工程的靈魂。它是對軟體的整體設計與把控。UMLj將軟工的思想繪成各種圖，然後通過這些圖加上設計模式，轉化成系統的代碼架構。有了架構，有了輪廓，剩下的具體實現的代碼就可以一蹴而就。一氣呵成了！UML的四種關係——關聯（組合、彙總）、依賴、泛化/繼承、實現。還有九圖都是學習UML的重點。九種圖裡面類圖是重中之重。另外我感覺畫時序圖也很讓人糾結，在做機房收費系統的時候，畫的圖就不太好，結果在寫代碼的時候就編寫邊改。著實讓人頭疼，吸取經驗下次一定好好研究UML圖。
設計模式
第一次用.NET做機房收費系統的時候用了一抽象工廠，稍微感受到了一下設計模式的好處。使用合適的設計模式可以讓代碼之間更加的獨立，專業術語叫做低耦合。使代碼更易複用。可謂好處多多啊。但值得注意的是，不要單純的為了用設計模式而用設計模式。一定要結合實際情況，看看到底這裡適不適合用設計模式，適合用哪種設計模式。這樣才能發揮設計模式的作用，否則只會適得其反。總之設計模式是前人總結的精華，我們要用，更要會用，以便讓它發揮最大的作用。想瞭解更多我關於設計模式的感受，請移步《大話設計模式讀後感》
三層架構
三層的學習也頗費周折，這次我們沒有像之前那樣有現成的資料，而是讓我們自己去搜尋——為的是鍛煉我們自己捕獲事物，汲取營養的能力，從而讓我們更適應大自然的生存環境。想要獲得知識，世界上最大的知識庫莫過於或連網，於是乎我就整天遊盪於各大程式員社區——CSDN。部落格園。51CTO等 都少不了我的身影。從那些大牛的部落格裡學習三層，逐漸的明白了三層到底是怎麼一回事。其實三層說白了就是將代碼按照不同的功能分為不同的幾個層，每一層都有自己的職責。例如負責跟資料庫打交道的代碼就放在DAL層(Data Access Layers)，而一些邏輯判斷就放在BLL層(Business Logic Layer)等等。說白了分層跟用設計模式用著異曲同工之妙，都是為了降低代碼的耦合度，從而使得所開發的軟體更易擴充、易維護。
分層也是一種思想，不同的階段對於分層有著不同的理解。隨著不斷的學習，不斷積累經驗，對於分層的理解會慢慢的加深。
C#跟VB.NET
學習C#一是為了學習設計模式，因為《大話》中的代碼是用C#實現的；而是為了讓我們初步認識一下物件導向的編程思想。而學習VB.NET是為了從之前學的VB6無縫過渡到以後的物件導向。這一點很好的體現了“吃飯理論”——通過自己熟悉的知識去獲得自己不熟悉的知識。
重構機房收費系統
又說到我們的經典項目了——機房收費系統。這次重新做機房收費系統，首先是分層，然後又用了抽象工廠+反射+設定檔。而第一次做機房收費系統，用的是VB6，那個時候簡直就是一個小白，什麼UML、設計模式、分層都一呼不呼。所有代碼都直接寫到表單下面，現在看之前做的東西，說難聽點就跟屎一樣！但是正是因為有當初的屎，才有了現在茁壯成長的莊稼！路是一步步走的，知識是一點點學的，所以不要在乎你現在有多差、水平有多低，只要肯努力，肯付出，再加上一個正確的方法，某天回頭望去，發現自己已然到達了一個新的高度！所謂不積跬步無以至千裡，不積小流無以成江海。說的就是這個道理，學習其實就是一個積累的過程。
合作開發機房收費系統
很無奈，又是它。這次你明白它為啥是經典了吧！合作開發主要是為了培養我們合作的能力，學習一下SVN的使用，同事也加深一下對三層和設計模式的理解。合作開發要比一個人開發快多了，這也是為啥要分層的一個原因，分層之後代碼的耦合度降低，每個人負責一部分，只要按照一定標準跟規範就可以同時並行開發了，然後各自寫完之後再合并，最後調試、打包就OK啦！這次合作沒有什麼太多的新東西，只是在原來的基礎上加了一個面板模式。這次合作讓我感受到注釋說明很重要，如果注釋說明寫的清楚明白，那麼幾乎組員之間不用多餘的交流就可以把項目做完，相反，如果寫的不好，那麼做起來就費勁了，寫兩句就要溝通一下，這樣就沒法進行下去了，而且還會帶來理解上的偏差，這都會造成很多不必要的麻煩，所以合作很重要的一點就是制定好標準和規範。
結束語
寫這篇部落格真是不容易啊，因為之前的年度總結《我的IT之路2011（二）》裡面已經對這一階段進行了比較詳細的總結，現在又重新再寫一次，說白了就是用不同的話把一件事說了兩遍，這對於我這個寫作水平非常有限的人來說真是個挑戰啊！還好寫完了，好與不好各位多擔待吧！不早了兩點多了該睡覺啦！晚安各位！
