我與軟體工程

標籤：

講授《軟體工程》這門課斷斷續續已經有十個年頭了，現在回過頭總結一下自己的思考曆程，與大家分享。

       1、史前

       我所在的學校是一所職業技術學校（學院），1997年剛調去的時候，我們電腦系才建系不久，連帶系主任總共只有八個人。那時，我剛開始從事電腦教學工作，我能做的無非是把過去在學校學的內容，鸚鵡學舌地搬給學生。教學計劃也是系主任參考其他學校的計劃，刪減而成。但隨著教學經驗的積累，開始從體系的角度考慮教學內容的內在關係。後來在討論02級的教學計劃時，我力主增設《軟體工程》這門課。

       2、開始

       在02級的第五學期（04年下半年），我開始為他們講授《軟體工程》課，選用的教材是清華大學出版社出版的鄭人傑編著的專科版教材，這是一本講授傳統的面向過程為主的教程，有一部分OO的內容（其實，我當時對OO的認識並不是很深，以為學習了OO的語言，就理解了OO）。為了激發學生的積極性，我把這門純理論教學的課程加入了實踐的內容，即我將每個班的學生編為5至8人的項目設計小組，由他們選擇我提供的若干項目或自選一個項目為設計課題，作業分為分析和設計兩個階段的文檔，另外包括一個資料庫設計文檔。我一邊講授理論，他們一邊用我講授的理論作分析、設計文檔，每個文檔都規定了提交時間限制，與成績掛鈎。我用大約整個授課學時的60%左右的時間做講授，等我講授完成後，他們用剩餘的時間分組在課堂上討論他們設計文檔。沒想到這一做法取得了異乎尋常的效果，幾乎每個班的討論都熱烈而積極，也取得了一批很好的學生設計成果。這之後，在06級、08級……直到現在14級，陸續講授很多屆學生的《軟體工程》。

       3、OO

       在以後的專業學習中，我陸續讀了一些網上介紹的各種名著。大約在05年我逐漸領悟到整個軟體領域包含兩個複雜的需要人們花費功夫的價值點。一個是解決問題的演算法問題，另一個是解決軟體本身的複雜性的問題，隨著軟體規模越來越大，軟體的內在結構的合理性已經成為行業的一個價值點。

       與我03年初在書店偶然發現《設計模式》、《重構》等名著不同，05年底我在有了上述想法後，就專門去書店有找相關的書籍，很幸運，我一下就找到了Bob大叔《敏捷式軟體開發 (Agile Software Development)》一書，於是就開始迷戀XP，並一度在教學中讓成績較好的學生，示範其中的保齡球計分程式的演練，效果也不錯。

       這時，由於高職學校強調對外合作辦學，我們系開始與北大青鳥開始軟體工程師的合作項目，我發現他們的技術培訓講師（進階支援人員），和我那時一樣也存在著為模式而模式的過度模式的傾向，儘管我並沒有完全看懂GOF的《設計模式》（後來在網上看了李建忠老師的系列講座，才算真懂了），在內心還是把它們像神一樣敬著。

       在成為我校的第一批青鳥合作教師之後，開始接觸青鳥的教學模式，它最大的特點是將實踐引入到教學中。其實，電腦學科本身就是一門實驗學科，只是由於早期國家窮，實驗條件無法滿足教學需要，才不得不偏向理論。當前，在實驗硬體條件已經大幅改善的狀況下，迴歸以實踐為主的教學已是必然，但由於積重難返，這個過程將持續一段時間。而且，由於沒有認真思考電腦理論實踐的關係，另一種極端的完全拋棄理論知識，為實踐而實踐的做法開始泛濫。

       在青鳥的培訓學習過程中，我開始在青鳥的實踐項目中接觸三層的軟體架構，並以此為開端，陸續學習了胡協剛的培訓教程，馬丁﹒福勒的《公司專屬應用程式架構設計》，《Microsoft﹒NET企業級應用架構設計》等關於軟體架構方面的書，開始認識到OO軟體包括微觀、中觀、和宏觀三個層面。

       所謂OO軟體的微觀層面，就是OOPL的三大文法：封裝、繼承、多態。能將多態的虛函數實現機制掌握了，就基本算到位了。這一點我在早期看侯捷老師的《深入淺出MFC》的時候就弄懂了，這也使我認為學習了OOPL就學會了OO，並固執了許多年，直到接觸設計模式。

       OO軟體的中觀層面，就是建立在對OO原則的深刻認識之上而形成的OO設計模式。主要包括GOF經典的23個以及ＩＯＣ。它是ＯＯ精華的所在，值得學習，也值得欣賞。以它們為基礎，進一步實現了規模更大（宏觀）的架構和架構。

       ＯＯ軟體的宏觀層面就是架構和架構。架構是一個軟體全域性的、唯一的架構，而其它的架構則是局部的複用半成品。

       ４、衝突

       在學習胡協剛的軟體架構資料的時候，談到了“不要陷入極限編程的陷阱”，提出對軟體的複雜性要有全域的設計，提出軟體開發應該從宏觀著手的觀點。而這一觀點與《敏捷式軟體開發 (Agile Software Development)》一書中介紹的ＸＰ方法，從中觀層面著手的輕量級方法不同。

       這使我陷入了一個困局，究竟是從大的方面著手的，還是從小的方面著手，去實現一個教學執行個體系統呢？

       ５、釋然

       直到最近，開始閱讀範鋼老師的《大話重構》才最終找到答案。原來，當前軟體是一個因不斷應對新的需求帶來的複雜性的提升，而其結構在不斷演化的動態過程。

       讓我們先從軟體的來源數學說起，據說，圖靈機是圖靈對人們使用紙筆進行數學運算的過程進行抽象而得來。所以，用電腦解決問題，就是一個複雜的解題過程。但是，我們的解題演算法是如何描述呢？

       “目前幾乎所有的演算法書的講解方式都是歐幾裡德式的、瀑布式的、自上而下的、每一個推導步驟都是精準制導直接面向目標的。由因到果，定義、引理、定理、證明一樣不少，井井有條一絲不亂毫無贅肉。而實際上，這完全把人類大腦創造發明的步驟給反過來了。看起來是陽關大道，實際上車馬不通。”

       “演算法誕生過程中的思路往往包含了比實際演算法更本質得多的知識，實際演算法乃至演算法的某個特定語言的實現包含了太多表面的不相干知識，它們會阻礙對本質的理解。” （見劉未鵬的部落格《知其所以然》）

       對軟體的結構也是一樣，軟體模式如果也是如此的精準制導直接面向目標的。就直接使用它們，為模式而模式，堆砌出一個超出我們需要的複雜度的軟體結構，從而引入不必要的複雜。

       在《大話重構》一書中作者提出的“恰如其分地規劃，演化式地開發”使我找到了問題答案，我覺得我可以開始寫我的教學執行個體軟體了，它應該是一個不斷為需求推動的而演化的軟體系列。

我與軟體工程